我们正在运行一台配备 NetXtreme BCM5720 2 端口千兆以太网 PCIe 卡的服务器。它有两个端口，每个端口都映射到不同的物理 ID 和逻辑名称；
sudo lshw -class network
*-network:0
description: Ethernet interface
product: NetXtreme BCM5720 2-port Gigabit Ethernet PCIe
vendor: Broadcom Inc. and subsidiaries
physical id: 0
bus info: pci@0000:04:00.0
logical name: eno1
version: 00
serial: b8:cb:29:97:26:61
size: 1Gbit/s
capacity: 1Gbit/s
width: 64 bits
clock: 33MHz
capabilities: pm vpd msi msix pciexpress bus_master cap_list rom ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=tg3 driverversion=3.137 duplex=full firmware=FFV21.81.3 bc 5720-v1.39 ip=192.168.1.211 latency=0 link=yes multicast=yes port=twisted pair speed=1Gbit/s
resources: irq:17 memory:91930000-9193ffff memory:91940000-9194ffff memory:91950000-9195ffff memory:91d00000-91d3ffff
*-network:1
description: Ethernet interface
product: NetXtreme BCM5720 2-port Gigabit Ethernet PCIe
vendor: Broadcom Inc. and subsidiaries
physical id: 0.1
bus info: pci@0000:04:00.1
logical name: eno2
version: 00
serial: b8:cb:29:97:26:62
size: 1Gbit/s
capacity: 1Gbit/s
width: 64 bits
clock: 33MHz
capabilities: pm vpd msi msix pciexpress bus_master cap_list rom ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=tg3 driverversion=3.137 duplex=full firmware=FFV21.81.3 bc 5720-v1.39 ip=192.168.3.201 latency=0 link=yes multicast=yes port=twisted pair speed=1Gbit/s
resources: irq:18 memory:91900000-9190ffff memory:91910000-9191ffff memory:91920000-9192ffff memory:91d40000-91d7ffff
如输出所示，它们被赋予了不同子网上的 IP。
192.168.3 子网面向外部，而 192.168.1 仅供内部使用。我们在路由器中配置了端口转发，以便端口 80 和 443 的入站流量转到 192.168.3.201。目的是在该服务器上运行 Web 应用程序，同时在内部网络上保持 ssh 处于打开状态以进行维护。
这在一定程度上有效
为了测试，我们运行默认的 nginx docker 镜像
docker run -d -p 192.168.3.201:80:80 -p 192.168.3.201:443:443 --restart=unless-stopped nginx:latest
最初，我们无法从外部访问 Web 界面。但是，如果我们将以太网电缆拉到 eno0，它就会突然工作。真正让我困惑的是，当重新插入 eno0 时，它实际上会继续工作。
这是高度可重复的。系统重启后它不起作用，但拔下/重新插入 eno0 后它突然又起作用了。
我们遗漏了什么？
按照 JFL 的建议在 rebbot 上添加 ip 路由的输出；
default via 192.168.1.1 dev eno1 proto dhcp src 192.168.1.211 metric 100
default via 192.168.3.1 dev eno2 proto dhcp src 192.168.3.201 metric 100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
192.168.1.0/24 dev eno1 proto kernel scope link src 192.168.1.211
192.168.1.1 dev eno1 proto dhcp scope link src 192.168.1.211 metric 100
192.168.3.0/24 dev eno2 proto kernel scope link src 192.168.3.201
192.168.3.1 dev eno2 proto dhcp scope link src 192.168.3.201 metric 100
拔掉eno0时；
default via 192.168.3.1 dev eno2 proto dhcp src 192.168.3.201 metric 100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
192.168.3.0/24 dev eno2 proto kernel scope link src 192.168.3.201
192.168.3.1 dev eno2 proto dhcp scope link src 192.168.3.201 metric 100
重新插入 eno0 后
default via 192.168.3.1 dev eno2 proto dhcp src 192.168.3.201 metric 100
default via 192.168.1.1 dev eno1 proto dhcp src 192.168.1.211 metric 100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
192.168.1.0/24 dev eno1 proto kernel scope link src 192.168.1.211
192.168.1.1 dev eno1 proto dhcp scope link src 192.168.1.211 metric 100
192.168.3.0/24 dev eno2 proto kernel scope link src 192.168.3.201
192.168.3.1 dev eno2 proto dhcp scope link src 192.168.3.201 metric 100
答案1
您的问题是您在两个接口上都配置了网关，如下所示：
default via 192.168.1.1 dev eno1 proto dhcp src 192.168.1.211 metric 100
default via 192.168.3.1 dev eno2 proto dhcp src 192.168.3.201 metric 100
两者的度量标准相同，因此系统必须选择其中一个。如何做出选择取决于所使用的操作系统。
无论您的操作系统使用什么标准，它都会在启动时选择从 eno1 接口出去的路由，因此流量不会发送到 Internet。
当您拔下 NIC 时，只剩下一个网关（正确的网关），因此它可以工作。
事实是，在您重新插入 eno1 之后它仍然可以工作，这表明您的操作系统可能使用了“最旧”的路由（您可以看到，重新插入后这两条路由的顺序被颠倒了）。
要解决此问题，您需要删除内部 NIC 上的默认网关，并在必要时用内部网络的路由替换它。如果您没有除 192.168.1.X/X 之外的任何其他内部网络，则您不需要这些路由。
由于您使用的是 DHCP，因此您需要从 192.168.3.X/X 范围中删除“路由器”设置，或者改用静态 IP 地址（如果您需要为其他主机保留路由器选项）。