☰

更新

tag-icon • tag-icon debian routing debian-jessie networkmanager
更新

我在使用 Debian Jessie 服务器时遇到一种情况，我正在手动创建 IP 路由，但第一次使用后它就停止工作了。

在我的网络上，我有 192.168.2.0/24 和 192.168.1.0/24 子网，它们大部分是隔离的。但是，在我的 Cisco RV325 路由器中，我允许 192.168.2.* 流量到 192.168.1.* 主机的例外（但反之亦然）。这对于我的 192.168.2.* 子网上的所有其他客户端（MacOS、Win10）都适用，无需额外配置。

但是，在我的 192.168.2.* Debian 服务器上，我无法访问 192.168.1.* 主机。因此，我尝试通过以下方式手动添加路由（在 Debian 机器上）：

root@debian$ route -v 
Kernel IP routing table 
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface 
default         router          0.0.0.0         UG    1024   0        0 eth1
192.168.2.0     *               255.255.255.0   U     0      0        0 eth1

root@debian$ route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.2.1 metric 1

root@debian$ route -v
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         router          0.0.0.0         UG    1024   0        0 eth1
192.168.1.0     router          255.255.255.0   UG    1      0        0 eth1
192.168.2.0     *               255.255.255.0   U     0      0        0 eth1

此时，我可以成功连接到另一个虚拟 LAN 上的 HTTP 主机：

root@debian$ telnet 192.168.1.24 80
Trying 192.168.1.24...
Connected to 192.168.1.24.
Escape character is '^]'.

例如，我可以手动请求一个网页，然后返回内容。然后关闭连接，任何随后的尝试失败：

Trying 192.168.1.24...
telnet: Unable to connect to remote host: No route to host

仍然route -v显示我添加的路由，但基本上无法使用。这里出了什么问题？是否有其他软件可能主动关闭它认为不合法的路由？

我见过这个相关问题，并尝试了所有三个当前的答案，但对我来说都不起作用。

我尝试完全禁用网络管理器，但这破坏了我的默认路由，这是一个更严重的问题。因此，我提出这个问题是“如何使用网络管理器在系统上添加到另一个子网的路由“？手动或启动时自动都可以。

更新

根据以下问题，iptables 显示：

root@debian$ iptables -vnL
Chain INPUT (policy ACCEPT 5376 packets, 1052K bytes)
 pkts bytes target     prot opt in     out     source               destination         
 2490  184K fail2ban-ssh  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport dports 22

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 3041 packets, 1187K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain fail2ban-ssh (1 references)
 pkts bytes target     prot opt in     out     source               destination         
   13  1016 REJECT     all  --  *      *       154.8.139.43         0.0.0.0/0            reject-with icmp-port-unreachable
    0     0 REJECT     all  --  *      *       192.99.122.172       0.0.0.0/0            reject-with icmp-port-unreachable
 2477  183K RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

这些 IP 似乎都不相关。在提出问题之前，我确实尝试禁用 fail2ban 服务，但没有效果。

ip addr在 debian 主机上显示：

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 00:26:55:db:36:fa brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:26:55:db:36:fb brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.34/24 brd 192.168.2.255 scope global eth1
       valid_lft forever preferred_lft forever

注意：我的机器上确实有第二个 NIC（eth2），但它被拔掉了并且处于关闭状态。路由表中不存在。

答案1

这几乎可能不是您的客户端上的路由问题 - 而可能是防火墙问题或服务器上的问题。

我猜是因为服务器上的网络掩码不正确（可能是 255.255.0.0，这很常见），再加上客户端上的反向路径过滤，导致服务器上的路由不正确。例如，您可以通过使用 echo "1" > /proc/sys/net/ipv4/conf/default/rp_filter 之类的命令禁用客户端上的反向路径过滤来检查这一点 - 但解决方案是修复服务器上的网络，因为数据包不会被发送回路由器。（这可能还涉及允许“相关”流量返回路由器）。

如果失败，请查看 iptables 规则，看看它是否被阻止 - 您可以通过输入 iptables -vnL 来查看这些规则。（您可能希望发布这些规则供我们查看）。这也可能与路由器有关，甚至可能是与 NAT 相关的问题。

通常，如果可能的话，下一步是进行一些数据包嗅探，以查看哪些数据正在离开计算机以及哪些数据正在被 Web 服务器和 vv 接收。您可以使用 tcpdump（在单独的窗口中，然后发出请求）和以下命令

tcpdump -n -i eth1 tcp src or dst 192.168.1.24

（我注意到你添加的路由命令是多余的 - 我怀疑你误解了它的用途。但这不是导致问题的原因。如果问题与反向路径过滤有关，您可能能够使用如下命令完全绕过路由器路由添加-net 192.168.1.0 网络掩码 255.255.255.0 eth1）

相关内容