我有一个 Centos 路由器,它在类似这样的设置下做了出色的工作:
- eth0——>无IP
- eth0.200-->192.168.200.1
- eth0.201-->192.168.201.1
- ... 依此类推
- eth0.213-->192.168.213.1
我已启用 ipv4 转发以允许 intervlan 路由,然后:
- eth1——>无IP
- eth1.201-->10.1.29.40
- eth0.202-->10.1.29.48
- ... 依此类推
- eth0.213-->10.1.29.136
当任何 eth0 网络从 Internet 寻找某些东西时,iptables 都会执行 SNAT,使用从 10.198.29.138 到 10.198.29.142 的 IP 范围作为公共 IP。一切正常。问题是我需要 VLAN 接口 192.168.200.1 驻留在 eth1 中。当我将其移动到 ifcfg-eth1.200 时,我可以在数据包捕获中看到许多客户端尝试通过询问哪个 MAC 地址属于 192.168.200.1 来填充其 ARP 表,但 eth1.200 从不回复!我看到其他 eth0.XXX 响应 ARP 广播,但没有响应 200。这可能是 iptables 的问题,还是其他问题?
我的 iptables 如下所示:
编辑/解决方案摘要 非常感谢 DAVID HOUDE 的评论
在解决另一个问题时,我能够自己进行实验,看看 sysctl -w net.ipv4.conf.eth0/202.rp_filter=0 命令的作用是什么:
SERVER
<==eth0||eth1==>
MAC FF:11 || MAC FF:22
IP 1.1.1.1 || IP 3.3.3.1
如果 eth0 收到 3.3.3.1 的 ARP 请求,默认情况下服务器不会回复该请求。禁用反向路径过滤器后,服务器会回复 eth0 上的 ARP 请求,说“嘿,IP 3.3.3.1 在 MAC FF:11 上”,而实际上,它在 eth1 上。
然后下一个数据包到达 eth0,目的地是 MAC FF:11 和 IP 3.3.3.1,并且由于路由表,所有返回 3.3.3.x IP 的数据包都会从 eth1 出去,所以我的数据包在黑洞中丢失了,但那是另一个故事。
就我而言,我的情况更像这样:
SERVER
<==eth0||eth1==>
MAC FF:11 || MAC FF:22
<==eth0.200 || eth1.200==>
IP 3.3.3.1 || IP 1.1.0.1
<==eth0.201 || eth1.201==>
IP 1.1.1.1 || IP 3.3.3.9
<==eth0.202 || eth1.202==>
IP 1.1.2.1 || IP 3.3.3.17
<==eth0.203 || eth1.203==>
IP 1.1.3.1 || IP 3.3.3.25
<==eth0.204 || eth1.204==>
IP 1.1.4.1 || IP 3.3.3.33
依此类推,直到 eth0.213。问题是,如您所见,1.1.0.0 网络在 eth1 上,而 3.3.3.0 在 eth0 上,其余网络则颠倒了。
我希望从后来使用建议的 sysctl 命令发现的情况来看,如果禁用 RPF,SERVER 最终会回复那些请求 eth1.200 上的 1.1.0.1 MAC 的 ARP 数据包,但不幸的是我无法确认。
我实际上可以确认该命令只能在受影响的子接口上运行,并且它们将立即应用更改。
答案1
Linux 旨在响应任何接口上的 ARP 请求。假设主机拥有 IP 地址,而不是特定接口。您看到的称为 ARP Flux。
如果您的接口位于同一第 2 层广播域中,您将会看到此信息。您提到您正在使用 VLAN,这应该不会使这种情况发生,但这取决于 VLAN 被标记的位置(由操作系统或交换机等)。
您可以使用以下方式在 Linux 中更改此行为系统控制
arp_ignore - 整数
定义不同的模式来响应接收到的解析本地目标 IP 地址的 ARP 请求并发送回复:
0 - (默认): 回复任意本地目标IP地址,配置在任意接口上
1 - 仅当目标 IP 地址是传入接口上配置的本地地址时才回复
2 - 仅当目标 IP 地址是传入接口上配置的本地地址,并且与发送方的 IP 地址都属于此接口上的同一子网时才回复
3 - 不回复配置了范围主机的本地地址,仅回复全局和链接地址的解析
编辑:重新阅读您的问题后,听起来您可能需要禁用每个 NIC 上的反向路径过滤器。
sysctl -w net.ipv4.conf.eth0/102.rp_filter=0
sysctl -w net.ipv4.conf.eth0/103.rp_filter=0