多网卡服务器为什么经常“能进不能出”?Linux 到底怎么选出口

今天我想分享一个案例：请求明明已经到达服务器，为什么响应没有沿原路返回？如何判断问题出在入站校验、Linux 选路，还是外围网络策略？

在排障时，最容易让人走偏的现象不是“完全不通”，而是抓包已经看见请求进入服务器，客户端却一直等不到响应。

网卡是 UP 的，IP 没配错，服务也在监听。于是排查很快转向防火墙、应用日志，甚至怀疑客户端。可如果这是一台多网卡服务器，真正应该先问的是：Linux 准备从哪里把回包送出去？

一个公开问题：第二张网卡有 IP，远端却访问不到

有一类很典型的现象：服务器配置多个 IP 后，远端网络只能访问其中一个；当入站接口与系统判断的反向最佳路径不一致时，报文可能被忽略。

为了便于分析，下面使用示意地址还原它背后的网络关系。

业务网 ens16010.10.10.10/24默认网关 10.10.10.1管理网 ens192192.168.20.10/24管理网关 192.168.20.1远端运维终端172.16.50.20

服务器的主路由表里只有一条默认路由：

default via 10.10.10.1 dev ens160

远端运维终端通过管理网络访问 192.168.20.10。请求由 ens192 进入，但服务器查询如何返回 172.16.50.20 时，主路由表只认识业务默认网关，于是把 ens160 选为出口。

路径变成了这样：

请求：172.16.50.20 → 管理网络 → ens192回包：192.168.20.10 → ens160 → 业务网络

客户端看到的是超时，服务器看到的却可能是“请求已经收到”。中间如果有状态防火墙、ACL、NAT 或只允许对称会话的安全设备，回包很容易被丢弃。

还有一种更隐蔽的结果：回包甚至没有机会发出去。严格模式的反向路径校验发现“到源 IP 的最佳反向路径不是入接口”，可能直接在入站阶段丢掉请求。

这两个问题现象相似，故障点却完全不同。

先纠正一个直觉：Linux 不会默认“从哪进就从哪出”

交换机转发帧时会学习 MAC 地址，状态防火墙会跟踪连接，很多人因此下意识认为服务器也记得“请求从 ens192 进来，响应就该从 ens192 回去”。

普通 Linux 主机的主路由决策没有这条默认规则。

对一个本机生成的回包，内核会拿目标地址查询路由；如果配置了策略路由，还会结合源地址、fwmark、入接口等条件选择路由表。它不会仅凭“上一包从哪张网卡进来”就自动保证对称返回。

可以把选路过程压缩成三个问题：

哪条 rule 被命中？        ↓去哪个路由表查询？        ↓该表中最具体的路由指向哪个出口？

默认规则通常会依次涉及 local、main 和 default 表。大多数日常静态路由和默认路由都在 main 表中。同一张表里，目标前缀越具体，优先级越高；没有更具体路由时，才轮到 0.0.0.0/0。

所以同一台双网卡服务器经常出现这种反差：

• 管理网同网段访问正常，因为命中了 192.168.20.0/24 直连路由；
• 跨网段访问失败，因为远端地址只能匹配业务默认路由；
• 业务网访问正常，不代表管理网的跨网段回程也正确。

能访问同网段，只证明直连路由可用，不能证明默认出口设计正确。

“能进不能出”通常断在三个位置

排查前先判断报文停在哪里，比上来修改配置更重要。

请求进入了网卡，但被反向路径校验丢弃

rp_filter 会根据报文源地址做反向路径校验。Linux 内核文档给出的三种取值是：

严格模式能帮助抵御部分源地址伪造，但它与天然不对称的路径并不友好。多出口、专线、VPN、策略路由和复杂转发场景，都可能触发这类冲突。

需要留意一个细节：接口实际使用的值与 conf/all/rp_filter、conf/<interface>/rp_filter 都有关，内核按两者的最大值生效。只看一个接口的配置，可能得到错误判断。内核默认值是 0，但部分发行版会在启动流程中调整它，因此不能凭发行版印象下结论。

请求进入协议栈，回包却走错出口

这是典型的非对称回程。应用已经处理请求，甚至已经生成响应，但主路由表把远端客户端判定为“从业务默认网关可达”。

这里最有价值的不是 ping，而是直接询问内核：

ip route get 172.16.50.20 from 192.168.20.10

ip route get 返回的是内核对这次路径查询的解析结果，不只是把现有路由表打印出来。重点看输出中的 via、dev 和 src。

如果结果类似：

172.16.50.20 via 10.10.10.1 dev ens160 src 192.168.20.10

问题已经很清楚：源地址是管理 IP，出口却落在业务网卡。此时继续盯着应用日志，价值不大。

服务监听地址也容易造成误判。监听 0.0.0.0 表示服务接受发往本机多个 IPv4 地址的连接，不表示响应会自动沿入接口返回；绑定到 192.168.20.10 可以约束本地地址，却仍不能代替正确的路由规则。监听解决“谁能接收”，路由解决“往哪里发送”。

主机选路正确，外围策略仍不认可

如果查询结果显示回包确实走 ens192，还不能立即宣布 Linux 没问题。主机防火墙、上游路由、防火墙会话表、云安全组和网络 ACL 仍可能丢包。

这时需要用双向抓包把责任边界切开：

tcpdump -ni ens192 host 172.16.50.20tcpdump -ni ens160 host 172.16.50.20

观察点不是“有没有包”这么简单，而是：请求出现在哪个接口，响应是否产生，又出现在哪个接口。tcpdump 通常需要 root 或相应网络能力；抓包也可能捕获业务信息，生产环境应限制主机、端口和持续时间。

我更推荐的排查顺序：先证明路径，再讨论修复

多网卡故障最常见的坑，是看到一条可疑配置就立刻修改。关闭防火墙、关闭 rp_filter、再加一条默认路由，现场很快被改成一个无法复盘的新环境。

下面这套顺序的目的，是让每一步都回答一个问题。

1. 地址是否真的属于预期接口

ip -br addr

确认接口状态、IP 和掩码。掩码配错时，内核可能把远端地址误判成直连邻居；IP 绑错接口时，后续所有路由判断都会被带偏。

2. 主路由表如何理解两个网络

ip route show table main

检查两张网卡的直连路由、默认路由、metric 和历史静态路由。不要只数默认网关有几条。普通配置通常仍按 metric 选出更优默认路由；只有显式配置多路径时，才按多路径规则处理。两种情况都不会自动形成“哪个地址收到请求，就由哪个地址对应的网卡返回”。

3. 是否已有策略路由

ip rule showip route show table all

这一步是为了发现被忽略的自定义路由表。旧变更留下的 from 规则、容器或 VPN 写入的路由、基于标记的规则，都可能改变最终出口。

4. 内核会怎样处理这一个客户端

ip route get 172.16.50.20 from 192.168.20.10

把示例地址换成真实客户端 IP 和服务器被访问的本地 IP。只执行不带 from 的查询，可能漏掉源地址策略的影响。

5. 请求究竟停在入站还是回程

sysctl net.ipv4.conf.all.rp_filtersysctl net.ipv4.conf.ens192.rp_filterss -lntp

rp_filter 用来判断入站校验，ss 用来确认服务是否监听在预期地址；普通用户执行 ss -p 时可能看不到全部进程信息。随后结合接口抓包，才能区分“内核没接收”“应用没响应”和“响应走错口”。

到这里再修改配置，通常已经不需要猜。

真正需要双出口时，策略路由比“双默认网关”更明确

如果设计目标是：

源地址 10.10.10.10      → 业务网关 10.10.10.1源地址 192.168.20.10   → 管理网关 192.168.20.1

那么系统需要的不是两条含义模糊的默认路由，而是按源地址选择路由表。下面只是运行时示意，执行前必须核对接口、地址和远程维护通道：

ip route add 192.168.20.0/24 dev ens192 \  src 192.168.20.10 table 100ip route add default via 192.168.20.1 \  dev ens192 table 100ip rule add priority 100 \  from 192.168.20.10/32 lookup 100

验证时仍然使用同一条命令：

ip route get 172.16.50.20 from 192.168.20.10

预期结果应指向 192.168.20.1 dev ens192。

这组命令需要管理权限，只修改运行时状态，重启后通常不会保留。生产环境应通过 NetworkManager、Netplan、systemd-networkd 或发行版支持的配置方式持久化。远程修改默认路由和策略路由可能直接中断当前 SSH 会话，至少要准备控制台或带外管理通道。

策略路由也不是所有问题的答案。如果服务器承担转发、透明代理、NAT 或基于连接标记选路，还要考虑 fwmark、连接跟踪以及回程方向是否使用同一套路由标记。单纯复制三条命令，很可能只修好测试流量。

三个容易踩的坑

第一个坑是直接关闭 rp_filter。它可能让报文恢复，但也可能只是绕过了安全检查，真正的回程设计仍然错误。应该先证明报文确实被反向校验影响，再在严格模式、宽松模式和路由调整之间做选择。

第二个坑是给两张网卡都配置相同优先级的默认网关。默认路由解决的是“未知目标走哪里”，不是“连接如何对称返回”。如果业务要求按源地址分流，应该把意图写进规则和独立路由表。

第三个坑是只查 Linux。云上多网卡还叠加了安全组、子网路由表和平台转发限制。部分云平台，多 ENI 可以用于管理网络和网络设备；但源/目的检查主要约束实例代替其他主机转发流量的场景。普通应用主机的本机请求响应异常，不应一上来就把它关闭。

多网卡真正考验的是路径所有权

一张网卡时，默认配置替你做了大部分决定。多张网卡出现后，业务网、管理网、备份网和专线都在争夺同一个问题：谁负责把哪类流量送回去？

我更愿意用下面这组关系检查多网卡服务器：

IP 配置正确≠ 入站校验通过≠ 应用收到请求≠ 回程出口正确≠ 中间设备允许

下次再遇到“能进不能出”，不要先补路由，也不要先关安全策略。先用客户端源 IP 和服务器本地源 IP 做一次 ip route get，再用接口抓包确认报文停在哪里。只要入站和回程被分开验证，问题通常就会从“网络玄学”变成一个可以归属、可以复现的路径错误。

作为运维架构工程师，排障的价值不只是恢复一次连接。更重要的是把业务网、管理网和转发边界写成明确规则，让下一次变更不再依赖默认行为。

你遇到过的多网卡故障，最后停在了 rp_filter、回程路由，还是上游防火墙？欢迎把现象和排查顺序留在评论区。