单机双网卡通信实践：处理思路与 Linux 路由、ARP 及 rp_filter 核心机制解析

大家好，我是后端王。

早年在做高可用支付网关架构时，为了实现「双专线互备 + 流量实时拨测」，我们在单台物理机上插了两块网卡（假设为 eth0 和 eth1），一根插主线路交换机，一根插备用线路交换机。当时写了一个 Golang 的网络探测服务，想用 eth0 作为 Client 发包，eth1 作为 Server 抓包，测试链路抖动。

结果服务一跑，压测吞吐量直接飙到几百 Gbps，延迟几乎为 0。排查了一圈才发现：数据包根本没有走物理网线出去，全在 Linux 内核里“左手倒右手”短路了。

今天我们就来系统地拆解一下：如果要让单机的两块网卡真正实现互相通信，底层的因果链是什么？涉及哪些网络知识？以及工程上该如何处理。

一、 核心阻碍：为什么单机双网卡默认无法通过“网线”通信？

要想解决问题，必须先理清楚 Linux 内核的默认行为：

[应用层发包: 绑定 eth0, 目标 IP 指向 eth1] 
  ↓
[内核路由子系统查询路由] 
  ↓ (命中 table local)
[内核判定: 目标 IP 属于本机任意网卡] 
  ↓
[直接路由给 loopback (lo) 虚拟设备] 
  ↓
[物理网卡 eth0 和 eth1 根本没有任何电信号通过]

这里涉及三个核心的网络与系统机制：

1. Linux 的“弱主机模型”（Weak Host Model）

在网络协议栈模型中，系统可以分为两类：

• 强主机模型（Strong Host Model）：网卡不仅是硬件接口，更是 IP 的严格边界。从 eth0 发出的包，源 IP 必须是 eth0；到达 eth0 的包，目标 IP 必须是 eth0，否则丢弃。
• 弱主机模型（Weak Host Model）：Linux 默认采用此模型。Linux 认为 IP 地址是属于整台主机的，而不是属于某块特定网卡。只要目标 IP 存在于本机的任意一个接口上，内核就认为这是发给自己的。

2. Local 路由表（table local）

Linux 内核在分配 IP 地址时，会自动在 local 路由表中生成条目：

$ ip route show table local
local 192.168.1.10 dev eth0 proto kernel scope host src 192.168.1.10
local 192.168.2.10 dev eth1 proto kernel scope host src 192.168.2.10

当你在 eth0（192.168.1.10）向 eth1（192.168.2.10）发包时，路由查找最先匹配 local 表，内核发现目标是本机 IP，直接将其转发至 lo 接口处理，绕过了物理发包流程。

3. ARP Flux 与反向路径过滤（rp_filter）

即使你用跳线（Patch Cable）把 eth0 和 eth1 直连，或者连在同一个交换机上，还会遇到两个经典坑：

• ARP Flux：eth0 发出 ARP Request 寻找 192.168.2.10，由于弱主机模型，eth0 和 eth1 甚至可能会同时响应这个 ARP 请求，导致 ARP 缓存混乱。
• 反向路径过滤（Reverse Path Filtering, rp_filter）：内核安全机制会校验“收到包的接口”是否是“如果我回包该走的接口”。如果校验失败，内核判定为 IP 欺骗（Martian Packet），直接静默丢包。

二、 解决方案一：网络命名空间（Network Namespace，最标准做法）

在做分布式系统本地仿真或网关连通性测试时，最干净利落的方案是利用 Linux 的 Network Namespace（netns） 进行隔离。

处理思路：

将 eth0 留在默认命名空间，将 eth1 移入独立的命名空间。此时，它们在逻辑上完全等同于两台独立的物理机。

因果链：

Namespace A 无法识别 Namespace B 的 IP 为 Local -> 强制走 eth0 物理发包 -> 交换机/直连网线转发 -> eth1 接收 -> Namespace B 处理。

实操代码：

# 1. 创建独立的 Network Namespace
sudo ip netns add ns_backend

# 2. 将 eth1 移入该 namespace
sudo ip link set eth1 netns ns_backend

# 3. 配置默认 namespace 下的 eth0
sudo ip addr add 192.168.10.1/24 dev eth0
sudo ip link set eth0 up

# 4. 配置 ns_backend 内部的 eth1
sudo ip netns exec ns_backend ip addr add 192.168.10.2/24 dev eth1
sudo ip netns exec ns_backend ip link set eth1 up
sudo ip netns exec ns_backend ip link set lo up

# 5. 测试物理连通性（使用直连网线或交换机互联）
# 从默认空间 ping ns_backend 里的 eth1
ping 192.168.10.2 -I eth0

# 6. 抓包验证流量确实走网线
sudo tcpdump -i eth0 -n

如果你在写 Go 或 Java 程序，Go 可以在启动 Goroutine 时通过 runtime.LockOSThread() 配合 unix.Setns() 进入特定命名空间进行 Socket 监听与发包。

三、 解决方案二：策略路由 + 内核参数调整（单命名空间硬核方案）

如果业务场景限制不能拆分 Namespace，必须在同一个主机环境中强行让流量出物理网卡，则需要通过修改内核参数和配置策略路由（Policy Routing）来实现。

核心处理思路：

1. 关闭内核的 rp_filter（反向路径校验）。
2. 限制 ARP 行为，解决 ARP Flux。
3. 自定义路由表，打破 table local 的全局优先权。

实操步骤：

1. 修改系统内核参数（/etc/sysctl.conf）

# 禁用反向路径过滤
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.eth0.rp_filter = 0
net.ipv4.conf.eth1.rp_filter = 0

# 修复 ARP 行为：只响应目标 IP 精确配置在当前接收网卡上的 ARP 请求
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.eth0.arp_ignore = 1
net.ipv4.conf.eth1.arp_ignore = 1

# ARP 声明时，始终使用该网卡自身的 IP 作为源 IP
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.eth0.arp_announce = 2
net.ipv4.conf.eth1.arp_announce = 2

执行 sysctl -p 生效。

2. 配置策略路由（Policy Routing）

我们需要创建两个自定义路由表（例如 rt_eth0 和 rt_eth1）：

# 假设 eth0: 192.168.1.10/24, eth1: 192.168.2.10/24
# 1. 在 /etc/iproute2/rt_tables 中声明两个表
echo "200 rt_eth0" >> /etc/iproute2/rt_tables
echo "201 rt_eth1" >> /etc/iproute2/rt_tables

# 2. 为 rt_eth0 表配置路由：指定所有从 eth0 出去的包走 eth0 接口
ip route add 192.168.1.0/24 dev eth0 src 192.168.1.10 table rt_eth0
ip route add default dev eth0 table rt_eth0

# 3. 为 rt_eth1 表配置路由
ip route add 192.168.2.0/24 dev eth1 src 192.168.2.10 table rt_eth1
ip route add default dev eth1 table rt_eth1

# 4. 配置策略规则（Rules）
# 来自 192.168.1.10 的流量强制查询 rt_eth0
ip rule add from 192.168.1.10 table rt_eth0
# 来自 192.168.2.10 的流量强制查询 rt_eth1
ip rule add from 192.168.2.10 table rt_eth1

注意：如果两个网卡在同一个子网，还必须使用 iptables / nftables 对数据包打标记（fwmark），并基于 ip rule fwmark 强制将特定的 TCP/UDP 连接引导到指定网卡输出，否则依然容易命中系统全局规则。

四、 架构师视角：核心网络知识全景复盘

把这套方案跑通之后，我们会串联起以下核心底层机制：

总结

在分布式和高可用架构的建设中，**“单机模拟多机”或“单机双上行链路”**是验证故障转移（Failover）非常常见的场景。

如果想要实现两块网卡真正的物理连通：

1. 测试/仿真场景：首选 Network Namespace，隔离彻底，协议栈行为与真实物理两台机器完全一致。
2. 多宿主生产主机（Multi-homed Server）：必须依赖 Policy Routing + 调整 arp_ignore / rp_filter 来保证进出流量的对称性，避免连接被内核阻断。

做底层排查，千万不要只相信 ping 192.168.x.x 返回的 ttl=64，打开 tcpdump -i eth0 看看物理网卡上到底有没有电信号，才是唯一的真理。