☰

ARP 请求的发送者地址与目标地址来自不同的广播域

tag-icon • tag-icon arp
ARP 请求的发送者地址与目标地址来自不同的广播域

我有以下简单的网络拓扑：

服务器网络拓扑

我在这台服务器中看到了一种情况，其中 ARP 请求发件人地址（192.168.1.15) 来自与目标 (10.10.10.252）：

server:~ # tcpdump -nei eth0 host 10.10.10.252
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:56:36.152174 00:16:3e:1a:61:b4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.10.10.252 tell 192.168.1.15, length 28
16:56:37.150442 00:16:3e:1a:61:b4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.10.10.252 tell 192.168.1.15, length 28
16:56:38.150449 00:16:3e:1a:61:b4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.10.10.252 tell 192.168.1.15, length 28
16:56:39.159566 00:16:3e:1a:61:b4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.10.10.252 tell 192.168.1.15, length 28
^C
4 packets captured
5 packets received by filter
0 packets dropped by kernel
server:~ #

我是否正确，由于松散的默认值，这种行为是可能的（0）arp_公告设置？

答案1

你对内核为什么接受/执行这些 ARP 的假设是正确的，但是我会解释一下为什么它们正在发生。

关键是，您实际上拥有一个带有两个网络块的广播域。

根据定义，通常在与子网通信时，您与属于连接到该子网的接口的网络进行通信；另一方面，Linux 通常默认与接口的主 IP 进行通信。

因此，当与 r1 通信时，Linux 计算机使用接口（或第一个接口的主 IP，取决于arp_announce，必须对其进行测试）作为源，因此这些 ARP 也是如此。

回到你为什么接受它们的假设，你指出了正确的地方：

arp_announce - INTEGER 定义不同的限制级别，用于通告接口上发送的 ARP 请求中的 IP 数据包中的本地源 IP 地址： 0 - （默认）使用在任何接口上配置的任何本地地址

也可用于发送回复：

arp_filter - 0 -（默认）内核可以使用来自其他接口的地址响应 arp 请求。这可能看起来是错误的，但通常是有道理的，因为它增加了成功沟通的机会。 IP 地址由 Linux 上的整个主机拥有，而不是由特定接口拥有。仅对于负载平衡等更复杂的设置，此行为才会导致问题。

除此之外：

arp_ignore - INTEGER 定义发送回复的不同模式，以响应接收到的解析本地目标 IP 地址的 ARP 请求： 0 -（默认）：回复在任何接口上配置的任何本地目标 IP 地址

所以我们可以得出结论，Linux 服务器在服务器级别处理 ARP，并且以一种非常轻松的方式默认情况下。

对于图中的路由器 r1 来说，情况并非如此，它将取决于其操作系统/固件的本地默认设置和配置。

相关内容