代码之家 › 专栏 › 技术社区 › bitifet

无法通过第二个NIC建立连接(两个跃点)

iproute ubuntu-server ip routing networking

-2

bitifet · 技术社区 · 7 年前

我们在Ubuntu Xenial中的网络路由配置方面遇到了问题。

我们有许多服务器同时使用Debian 8.4(Jessie)和Ubuntu 16.04.2(xenial) 和 一模一样 网络设置(或至少在我们看来)。

它们都有两个NIC连接到两个VLAN(如“A”和“B”),都可以访问尽管其他VLAN表示,例如,来自VLAN“C”。

二者都 /etc/network/interfaces 文件的格式如下:

注: 为了更好的可读性,我伪造了名字和IP。

# VLAN A
auto eth0
iface eth0 inet static
address 192.168.111.xxx
netmask 255.255.255.0
broadcast 192.168.111.255
network 192.168.111.0
gateway 192.168.111.254
dns-nameservers 192.168.111.25 192.168.111.26

# VLAN B
auto eth1
iface eth1 inet static
address 192.168.222.xxx
netmask 255.255.255.0
broadcast 192.168.222.255
network 192.168.222.0
gateway 192.168.222.254 # <-- (Commented out in Ubuntu machine)
dns-nameservers 192.168.111.25 192.168.111.26

...说 xxx Debian机器是100,Ubuntu机器是200,我正在尝试从VLAN“C”中的192.168.1.10 ping到以下地址:

192.168.111.100:工作正常。
192.168.222.100:很好用。
192.168.111.200:工作正常。
192.168.222.200: 没有回答!!

“B”vlan主要用于备份和其他“后台”通信避免vlan“A”中的饱和问题。

我知道,使用两条网络路径访问同一台机器并不常见设置,我必须说,只能连接其中一个如今,其他网络不是什么大问题。但我最讨厌的是 为什么? 我可以访问Debian机器,而不能访问Ubuntu机器?

另一方面,如果它在两个平台上都运行良好,我们也可以考虑从NIC关闭一些服务(如ssh和后端接口) “A”以提高安全性(我们的防火墙只允许从 IT人员vlan)。

当然如前所述接口一小条网关行在Ubuntu机器中被注释掉了,但那是因为,网络否则,初始化将在该计算机中失败。事实上,这就是我们正在尝试解决。

但是 两台机器的路由表几乎相同 . 唯一的区别我可以看到联机 Ubuntu计算机中的标志:

myUser@debianMachine:~$ sudo ip route
default via 192.168.111.254 dev eth0
192.168.111.0/24 dev eth0  proto kernel  scope link  src 192.168.111.100
192.168.222.0/24 dev eth1  proto kernel  scope link  src 192.168.222.100


myUser@ubuntuMachine:~$ sudo ip route
default via 192.168.111.254 dev eth0 onlink
192.168.111.0/24 dev eth0  proto kernel  scope link  src 192.168.111.200
192.168.222.0/24 dev eth1  proto kernel  scope link  src 192.168.222.200

...但我可以通过以下命令将其删除:

myUser@ubuntuMachine:~$ sudo ip route replace default via 192.168.111.254 dev eth0
myUser@ubuntuMachine:~$ sudo ip route
default via 192.168.111.254 dev eth0
192.168.111.0/24 dev eth0  proto kernel  scope link  src 192.168.111.200
192.168.222.0/24 dev eth1  proto kernel  scope link  src 192.168.222.200

而且它没有解决问题。

之后,我还尝试取消注释网关 “VLAN B”行说,在 /etc/网络/接口 文件并尝试重新启动网络,但实际情况如下:

myUser@ubuntuMachine:~$ sudo /etc/init.d/networking restart
[....] Restarting networking (via systemctl): networking.serviceJob for networking.service failed because the control process exited with error code. See "systemctl status networking.service" and "journalctl -xe" for details.
failed!

...以及联机旗帜又回来了。

请注意,再次注释该行并发布新的 /etc/init.d/networking restart 命令,直到计算机已重新启动(即使是联网,尽管有VLAN B默认网关问题,继续正常工作)。

以下是建议命令的输出:

myUser@ubuntuMachine:~$ sudo systemctl status networking.service
â networking.service - Raise network interfaces
   Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: enabled)
  Drop-In: /run/systemd/generator/networking.service.d
           ââ50-insserv.conf-$network.conf
   Active: failed (Result: exit-code) since jue 2017-12-21 14:55:29 CET; 42s ago
     Docs: man:interfaces(5)
  Process: 8552 ExecStop=/sbin/ifdown -a --read-environment --exclude=lo (code=exited, status=0/SUCCESS)
  Process: 8940 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=1/FAILURE)
  Process: 8934 ExecStartPre=/bin/sh -c [ "$CONFIGURE_INTERFACES" != "no" ] && [ -n "$(ifquery --read-envi
 Main PID: 8940 (code=exited, status=1/FAILURE)

dic 21 14:55:29 ubuntuMachine systemd[1]: Stopped Raise network interfaces.
dic 21 14:55:29 ubuntuMachine systemd[1]: Starting Raise network interfaces...
dic 21 14:55:29 ubuntuMachine ifup[8940]: RTNETLINK answers: File exists
dic 21 14:55:29 ubuntuMachine ifup[8940]: Failed to bring up eth1.
dic 21 14:55:29 ubuntuMachine systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILUR
dic 21 14:55:29 ubuntuMachine systemd[1]: Failed to start Raise network interfaces.
dic 21 14:55:29 ubuntuMachine systemd[1]: networking.service: Unit entered failed state.
dic 21 14:55:29 ubuntuMachine systemd[1]: networking.service: Failed with result 'exit-code'.

...以及 sudo journalctl -xe :

dic 21 14:55:29 ubuntuMachine sudo[8922]:   myUser : TTY=pts/0 ; PWD=/home/myUser ; USER=root ; COMMAND=/etc/init.d/networking restart
dic 21 14:55:29 ubuntuMachine sudo[8922]: pam_unix(sudo:session): session opened for user root by myUser(uid=0)
dic 21 14:55:29 ubuntuMachine systemd[1]: Stopped Raise network interfaces.
-- Subject: Unit networking.service has finished shutting down
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit networking.service has finished shutting down.
dic 21 14:55:29 ubuntuMachine systemd[1]: Starting Raise network interfaces...
-- Subject: Unit networking.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit networking.service has begun starting up.
dic 21 14:55:29 ubuntuMachine ifup[8940]: RTNETLINK answers: File exists
dic 21 14:55:29 ubuntuMachine ifup[8940]: Failed to bring up eth1.
dic 21 14:55:29 ubuntuMachine systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
dic 21 14:55:29 ubuntuMachine systemd[1]: Failed to start Raise network interfaces.
-- Subject: Unit networking.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit networking.service has failed.
--
-- The result is failed.
dic 21 14:55:29 ubuntuMachine systemd[1]: networking.service: Unit entered failed state.
dic 21 14:55:29 ubuntuMachine systemd[1]: networking.service: Failed with result 'exit-code'.
dic 21 14:55:29 ubuntuMachine sudo[8922]: pam_unix(sudo:session): session closed for user root

我在google上搜索了很多相关信息,但都没有找到完全回答我的问题:

一 explanation of "onlink" flag 在我看来,它似乎指向排除了“onlink”标志负责 “反向布线错误”,意思是 «告诉内核不必检查网关是否可以通过当前计算机 所以(我发现)内核可能认为它可以(或者应)将接入连接的答案从VLAN C路由到默认网关而非思想 相同的NIC 连接已启动 .
- 但是 正如我所说 ,删除“onlink”标志似乎没有改变任何东西
这 unix StackExchange answer 似乎解决了问题(我没有通过使用多个路由表和规则(告诉使用哪个表)。但是 这不能解释 为什么选择Debian 机器运转良好(我检查过 /etc/iproute2/rt\U表格 文件,共机器和 它们是相同的 也是:

myUser@bothMachines:~$ sudo cat /etc/iproute2/rt_tables
#
# reserved values
#
255     local
254     main
253     default
0       unspec
#
# local
#
#1      inr.ruhep

所以我的最后一个假设是,这可能只是实现上的差异在内核版本和ubuntu版本之间可以是 正确的行为 所以,在现代内核中,我需要使用两个不同的路由表(但我不确定,也不知道为什么…)。

myUser@debianMachine:~$ sudo uname -a
Linux debianMachine 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) x86_64 GNU/Linux

myUser@ubuntuMachine:~$ sudo uname -a
Linux ubuntuMachine 4.4.0-87-generic #110-Ubuntu SMP Tue Jul 18 12:55:35 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

因此,问题是:

我们是不是在Ubuntu机器上做错了什么(或者有一些bug)?或者,相反,这是正确的行为,我们被迫设置更复杂的路由模式(通过每个vlan路由或通过使用两个路由表使两个默认网关重新工作)?

编辑:

现在,我尝试添加静态路由来解决问题:

myUser@ubuntuMachine:~$ sudo ip route add 192.168.1.0/24 via 192.168.222.254 dev eth1

...但这冻结了我的ssh连接(以为NIC A),甚至我可以连接以为NIC B(192.168.111.200)

这两条规则似乎不可能同时执行:

myUser@ubuntuMachine:~$ sudo ip route add 192.168.1/24 via 102.168.111.254 dev eth0
myUser@ubuntuMachine:~$ sudo ip route add 192.168.1/24 via 192.168.222.254 dev eth1
RTNETLINK answers: File exists

编辑2:

我终于找到了 Linux Advanced Routing & Traffic Control HOWTO 这似乎比我在其 Chapter 4. Rules - routing policy database 我看到以下文字:

如果要使用此功能,请确保您的内核使用“IP:高级路由器”和“IP:策略路由”编译特征

...因此,我认为所有这些都指向我之前关于内核实现差异的假设是正确的,而这种差异具体地说就是正在编译的这两个特性。

1 回复 | 直到 7 年前

1

bitifet 7 年前

这不是一个权威性的答案,而是我的第一次工作尝试(应用我设法理解的内容):

sudo ip route add 192.168.1.0/24 via 192.168.222.254 from 192.168.222.200 dev eth1 table 253 
sudo ip rule add from 192.168.222.200 table 253

更新: from 和 dev 中的参数 ip route 不需要命令(如果没有命令,它可以很好地工作)。

...在执行第一个命令后,我还无法连接,但在发出第二个命令后,是的。

这背后的逻辑来自我在 this document :

Linux-2。x可以将路由打包到多个路由表中,这些路由表由1到255之间的数字或文件/etc/iproute2/rt\u表中的名称标识。默认情况下,所有正常路由都插入到主表(ID 254)中,内核在计算路由时仅使用此表。

实际上,另一个表总是存在的,这是不可见的,但更重要。它是本地表(ID 255)。此表包括本地和广播地址的路由。内核自动维护这个表,管理员通常不需要修改它,甚至不需要查看它。

事实上,我最终使用了另一个路由表,由它的id(253)标识,而不是我现在理解的它只是一个别名(在中定义 /etc/iproute2/rt\U表格 文件)。

...再次检查该文件,我现在看到已经为该路由表定义了一个别名(“default”)(在“main”旁边,正如我之前粘贴的文本片段所说,实际上是254。

我还不知道这个命名背后的逻辑是什么(我指的是253路由表的“默认值”),以及出于任何原因,是否最好使用较低的路由表(1、2、3…)喜欢 this solution (问题中已经提到)是的。

但是,为了简单起见,如果我们不打算构建复杂的路由策略,只想解决这个问题 连接问题 ,我想这可能是一个很好的解决方案( 尚未测试 ):

gateway 192.168.222.254 table 253
post-up ip rule add from 192.168.222.200 table 253

我还需要测试和检查是否需要额外的 via 192.168.222.254 在网关行或如果它根本不起作用,需要将其与另一行一起添加张贴而不是命令。

我将用结果更新此答案。

编辑1: 同样适用于违约路线:

sudo ip route add default from 192.168.222.200 via 192.168.222.254 table 253
sudo ip rule add from 192.168.222.200 table 253

编辑2: 第一种(现在完全)工作方法

在使用测试机玩了一段时间后,我认为最好的解决方案是在中的第二个NIC配置中添加以下行 /etc/network/interfaces 文件:

gateway 192.168.222.254 table 1
post-up ip rule add from 192.169.222.200 table 1
pre-down ip rule del from 192.168.222.200 table 1
post-up ip route add 192.188.222.0/24 dev eth1 src 192.168.222.200 table 1

评论:

正在添加 table 1 到 gateway 关键字工作得很好,所以额外(可读性较差) 张贴无需使用命令添加该默认路由。
- ...事实上,使用特定的表(而不是 主要的 )对于第一个NIC,使用与我们用于第二个NIC的规则类似的规则是个坏主意,因为该规则仅在192.168.111.200时适用 将用作源地址 因此,将不会有任何“默认网关”。保留中的第一个NIC配置 主要的 路由表,将使所有(“本地生成的”)到远程LAN的传出连接通过我们的第一个 默认网关 默认情况下。
第一 post-up 命令添加了一条规则,即具有该NIC源地址的数据包应使用表1进行路由(否则将不使用新的默认网关)。
pre-down 命令删除该规则。它不是强制性的,但如果没有它,多次重新启动网络服务将每次重复此规则。
我也试着使用 dev eth1 而不是 from 192.169.222.200 (以避免重复网络地址),但它不起作用。我猜“响应”数据包使用哪个NIC“尚未决定”。
我用过 表1 对于 eth1 (我们的第二个NIC)我可以 table 2 最终的第三个,等等。不需要为第一个NIC指定任何表/规则,因为它涉及 主要的 表(非“默认”:见以下注释)。
最后()第二个 张贴 命令使所有事情都能很好地工作,因为(正如我现在意识到的)只使用(第一次匹配)一个路由表,所以默认网络路由(在打开接口时自动创建)不适用,因为它是在表中创建的 主要的 .
- 我还是不知道有没有办法把它直接装进板条箱表1 .

注: 按命令 sudo ip rule list 我们可以看到当前的路由规则如下:
0:      from all lookup local 
32765:  from 192.168.222.200 lookup 1 
32766:  from all lookup main 
32767:  from all lookup default
正如我所理解的,它们从32767递减添加到0,并尝试越来越多,直到一个匹配。最后两个1和“0”已经默认情况下定义。前者是因为我之前引用的逻辑从…起本文件但文件上说规则是从“1”开始的所以我想“0”也应该是一些预定义的“默认起点”。

编辑3:

正如我在 编辑2 (关于这个问题),我发现了这个 Linux Advanced Routing & Traffic Control HOWTO 这对我澄清问题有很大帮助。

具体而言 Routing for multiple uplinks/providers 在理解具有“网络环路”的设置时,第章对我非常有用(即使在我们的情况下,我们并不是互联网的路由器)。