☰

与 apipa 的接口（即 169.254.xx）

tag-icon • tag-icon networking routing networkmanager internet tcp-ip
与 apipa 的接口（即 169.254.xx）

我有一台带有两个接口（eth0 和 eth1）的 ubuntu 机器。 Eth0 接口具有 dhcp 地址，eth1 具有 apipa (169.254.xx) 地址。 eth1 未连接，eth0 连接到本地网络。从我的桌面（也连接到同一网络）我可以 ping 169.254.xx 地址并可以执行 scp 等。

这怎么可能？没有启用路由。

答案1

只是为了澄清：APIPA是 Microsoft 的原始命名，已标准化为IPv4 链路本地地址的动态配置（IPv4LL）。

以下是可能发生的情况：

  • 桌面本身有一条通往 IPv4LL LAN 的路由，可能除了通过 Ubuntu 使用的相同 DHCP 获得的更“经典”路由之外，例如专用 LAN 192.168.1.0/24。

  • Ubuntu 本身有一个 IPv4LL 地址以太网1，比方说 169.254.5.6

  • 当 Desktop 自联机（可直接访问）起寻找 169.254.5.6 时，它会以广播形式发送 169.254.5.6 的 ARP 请求，

  • Ubuntu 接收广播。作为 Linux 主机，它遵循弱宿主模型：添加到其接口的 IP 地址属于主机而不是其接口。对于 IPv4 来说都是如此和对于 ARP，如文档中所述arp_filter环境：

arp_filter- 布尔值

[...]

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

所以它回答分配给 169.254.5.6 的 ARP 请求以太网1，但是在以太网0在被问到的地方，使用以太网0的以太网 MAC 地址。

  • 桌面现在已解析第 2 层以太网地址，更新其 ARP 表并向 Ubuntu 的 169.254.5.6 发送 IPv4 ICMP 回显请求数据包，其中目标 MAC 地址为 Ubuntu 的 eth0 MAC 地址，

  • Ubuntu，遵循弱主机模型，使用 IPv4 ICMP 回显回复请求。由于 OP 告诉它正在工作，这进一步意味着：

    • 桌面源地址也是 IPv4LL，Ubuntu 上也有 169.254.0.0/16 路由以太网0具有较低的度量（或者如果相等的话首先使用），所以回复出现在右侧，

    • 或者更可能的是，桌面没有使用 IPv4LL 源来查询 IPv4LL 地址 169.254.5.6，因此它与 Ubuntu 的 IP 地址位于同一 IP 网络（由 DHCP 设置）中以太网0Ubuntu 也在右侧回答（因为它的路由表在 eth0 上有一个类似 192.168.1.0/24 的条目）。这种情况（不使用 IPv4LL 源）是由RFC：

当 IPv4 链路本地地址和可路由地址在同一接口上可用时，应优先选择可路由地址作为
新通信的源地址，但从 IPv4 链路本地地址发送或发送到
IPv4 链路本地地址的数据包仍按预期传送。

假设我的解释中没有遗漏任何内容，那么是哪种情况？

当然，这种行为并不完全正确。因为每个广播域都应该有自己的私有 IPv4LL LAN，并且不能将地址泄露给其他域。

这在实践中意味着，如果具有默认配置的 Linux 主机参与多个此类 IPv4LL 网络（每个接口一个），它可能（不确定，见下文）不允许任何其他系统使用其自己的任何 IPv4LL 地址，或者即使它们不在同一侧，也无需切换自己的 IPv4LL 地址，因为碰撞检测。但在实际应用中，仍然因为Weak Host Model的原因，默认情况下会有多条到169.254.0.0/16的路由进入该地多宿主（错误）配置。通常只有一条路线可以正常工作：第一个路线等于显示的ip route show 169.254.0.0/16。其他人可能有有效的 ARP，但可能没有有效的 IP 路由。这需要正确配置主机以实现多宿主（在这种情况下，它可能会停止应答发送到上面“错误”接口的 ARP，并且不会触发此问题），并且与 IPv4LL 集成也无济于事。大多数情况下，IPv6 不会发生这种情况，因为任何链路本地地址的使用都必须包含接口。

相关内容