无法通过第二个NIC（两个跃点）建立连接

Posted

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了无法通过第二个NIC（两个跃点）建立连接相关的知识，希望对你有一定的参考价值。

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

我们有许多服务器，包括Debian 8.4（Jessie）和Ubuntu 16.04.2（xenial）以及完全相同的网络设置（或者至少我们可以看到）。

它们都有两个连接到两个VLAN（称为“A”和“B”）的NIC，这两个VLAN都可通过其他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 Machine为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 Machines而不是Ubuntu呢？

另一方面，即使它在两个平台上运行良好，我们也可以考虑从NIC“A”关闭一些服务（例如ssh和后端接口）以提高安全性（我们的防火墙只允许访问vlan“B”）来自我们的IT员工vlan）。

当然，正如之前的接口片段中所评论的那样，网关行在Ubuntu机器中被注释掉了，但那是因为网络初始化在那些机器中失败了。事实上，这就是我们想要解决的问题。

但两台机器的路由表几乎相同。我能看到的唯一区别是Ubuntu机器上的onlink标志：

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 / network / interfaces文件中被注释掉并尝试重新启动网络，但这就是发生的事情：

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!

......并且onlink标志又回来了。

作为注释，再次注释掉该行并发布新的/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

我搜索了很多关于能够找到一些相关信息但没有完全回答我的问题：

  • 在我看来，explanation of "onlink" flag指出了“onlink”标志负责“错误的反向路由”的可能性，其意思是«告诉内核它不必检查网关是否可以直接通过当前的机器»所以（我想通了）内核可能认为它可以（或应该）将来自VLAN C的连接的答案路由到默认网关，而不是认为连接开始的同一个NIC。 但是，正如我所说，删除“onlink”标志似乎没有改变任何东西。
  • 这个unix StackExchange answer似乎通过使用多个路由表和规则来解决问题（我还没有测试过）（告诉内核使用哪个表）。但它并没有解释为什么Debian机器运行良好（我检查了两台机器的/ etc / iproute2 / rt_tables文件，它们也是相同的：

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机器上做错了什么（或者它们中有一些错误）？或者，相反，这是正确的行为，我们被迫设置更复杂的路由模式（通过per-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：策略路由”功能编译内核

...所以我认为我之前关于内核实现差异的假设是正确的，并且差异具体地说是编译的两个特性。

答案

不是权威的答案，而是我的第一次尝试（应用我设法理解的）：

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 routearguments不是必需的（如果没有它们，它可以很好地工作）。

...在isuinng第一个命令之后我还无法连接，但在发出第二个命令之后是。

这背后的逻辑来自于我在this document发现的这篇文章：

Linux-2.x可以将路由打包到多个路由表中，这些路由表由1到255之间的数字标识，或者来自文件/ etc / iproute2 / rt_tables中的名称默认情况下，所有正常路由都插入到主表中（ID 254）并且内核仅在计算路径时使用此表。

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

实际上，我最终使用另一个路由表，由其id（253）标识，而不是我现在理解的它只是一个别名（在/ etc / iproute2 / rt_tables文件中定义）。

...并再次检查该文件，我现在看到已经为该路由表定义了一个别名（“默认”）（“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，或者它是否根本无法工作，而是需要使用另一个post-up命令添加它。

我将用结果更新这个答案。

编辑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：第一个（现在完全¹）工作方法

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

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关键字效果很好，因此添加该默认路由的附加（不太可读）的post-up命令不是必需的。 ...实际上，对于第一个NIC使用特定表（除了main之外）以及与我们用于第二个NIC的规则类似的规则将是一个坏主意，因为该规则仅适用于192.168.111.200用作源地址，因此不会有任何“默认默认网关”。在主路由表中保留第一个NIC配置，将使所有（“本地生成的”）到远程LAN的传出连接默认通过我们的第一个默认网关。
  • 首先，post-up命令添加一条规则，即应使用表1路由具有该NIC源地址的数据包（否则将不使用我们的新默认网关）。
  • pre-down命令删除该规则。它不是强制性的，但如果没有它，多次网络服务重启将每次都复制此规则。
  • 我也尝试使用dev eth1而不是from 192.169.222.200（以避免重复网络地址），但它没有用。我想用于“响应”数据包的哪个NIC“还没有决定”。
  • 我使用table 1作为eth1（我们的第二个NIC），我可以使用table 2作为最终的第三个，依此类推。不需要为第一个NIC指定任何表/规则，因为它来到主表（不是“默认”：见下面的注释）。
  • 最后（¹）第二个post-up命令使一切正常，因为（我现在意识到）只有（第一次匹配）使用一个路由表，因此默认网络路由（当接口启动时自动创建）不适用，因为它是在主表创建的。 我仍然不知道是否有办法强迫它直接进入表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，并且越来越多地尝试直到匹配。默认情况下已经定义了最后两个和“0”。前者是因为我之前从this document引用的逻辑，但文档说规则从“1”开始，所以我猜“0”也应该是一些预定义的“默认起点”。

编辑3：

正如我在编辑2（问题）中所说，我发现这个Linux Advanced Routing & Traffic Control HOWTO帮助我澄清了很多东西。

具体来说，Routing for multiple uplinks/providers章对于理解具有“网络循环”的设置的任务非常有用（即使在我们的情况下，我们也不是作为Internet的路由器）。

以上是关于无法通过第二个NIC（两个跃点）建立连接的主要内容，如果未能解决你的问题，请参考以下文章

oracle 第二个数据库实例,用plsql不能连接

两个片段之间的 onItemClickListener

套接字建立连接过程

想要使用 SharePreferences 更新第二个片段中的数据，但第二个片段没有更新

无法更新 View Pager 中的中间片段。

通过另一个适配器访问一个适配器的数据