无法通过第二个NIC（两个跃点） Build 连接-Java 学习之路

-2

我们在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机器是100，对于Ubuntu机器是200，我正在尝试从VLAN "C"中的192.168.1.10到以下地址：

192.168.111.100：工作正常 .
192.168.222.100：工作正常 .
192.168.111.200：工作正常 .
192.168.222.200： NO Answer!!

“B”vlan主要用于备份和其他“后台”流量，以避免vlan“A”中的饱和问题 .

我知道有两个网络路径访问同一台机器不是一个常见的设置，我必须说，只有能够连接思想其中一个来自其他网络现在不是一个大问题 . 但是什么对我来说是 why 我可以访问Debian Machines而不是Ubuntu吗？

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

Of course, ，因为它在之前的接口片段中被注释，网关行在Ubuntu机器中被注释掉了，但那是因为网络初始化在那些机器中失败了 . 事实上，这就是我们想要解决的问题 .

但 both machines routing tables are almost identical . 我能看到的唯一区别是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

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

在我看来，它正在指出"onlink"标志负责"wrong back routing"的意思是«告诉内核它不必检查网关是否可以直接通过当前机器到达»所以explanation of "onlink" flag （我发现）内核可能认为它可以（或应该）将从VLAN C到连接的连接的答案路由到默认网关而不是思想 the same NIC from where the connection was started .
但是， as I said ，删除"onlink"标志似乎没有改变任何东西 .
这unix StackExchange answer似乎通过使用多个路由表和规则来解决问题（我还没有测试过）（告诉内核使用哪个表） . 但 it doesn't explain 为什么Debian机器运行良好（我检查了两台机器的/ etc / iproute2 / rt_tables文件和 they are identical ：

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

所以我最后的假设是，它可能只是内核版本之间的实现差异，并且，如果ubuntu更新，那可能是 the correct behaviour 所以，在现代内核中，我需要使用两个不同的路由表（但是我是'm not sure and don' t知道为什么...） .

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路由或使用两个路由表使两个默认网关再次工作）？

EDIT:

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

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

EDIT 2:

我终于找到了Linux Advanced Routing & Traffic Control HOWTO，它似乎比我找到的所有其他文档更准确特别是在Chapter 4. Rules - routing policy database中我看到以下文字：

如果要使用此功能，请确保使用“IP：高级路由器”和“IP：策略路由”功能编译内核

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

1 回答

1
不是权威的答案，而是我的第一次尝试（应用我设法理解的）：
```
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
```
更新：来自ip route命令的from和devarguments不是必需的（如果没有它们，它可以很好地工作） .

...在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路由表的"default"），如果出于任何原因，最好使用较低的路由表（1,2,3 ......） this solution（问题中已经提到过） .

但是，为了简单起见，如果我们不打算构建复杂的路由策略并且只是想解决这个连接问题，我想这可能是一个很好的解决方案来使用像（ not yet tested ）这样的东西：
```
gateway 192.168.222.254 table 253
post-up ip rule add from 192.168.222.200 table 253
```
我仍然需要测试并检查我是否需要在网关行中添加192.168.222.254，或者它根本不能工作，而是需要用另一个post-up命令添加它 . 我将用结果更新这个答案 .

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

Edit 3:

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

具体而言，Routing for multiple uplinks/providers章对于理解具有"network loops"的设置非常有用（即使在我们的情况下，我们也不是作为Internet的路由器） .
回复于 2024-04-29T07:25:54+08:00

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

1 回答

相关问题