☰

ipv6 ping 主机得到目标主机不可达，直到运行 tcpdump

tag-icon • tag-icon linux ipv6 ping tcpdump
ipv6 ping 主机得到目标主机不可达，直到运行 tcpdump

一开始（所有电脑都启动了）当我从 Windows 电脑 ping 网关（Linux 电脑，两个网卡（一个是 USB））时，我收到：“目标主机不可达”，但是当我tcpdump -i LANINTERFACE ip6在网关上运行“ ”时，ping 得到了网关的回复，我的网络出了什么问题，有什么想法吗？
网关和 Windows 电脑使用静态 ipv6 地址。

网关的 ipv6 配置：

# ip -6 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
4: enp0s29f0u2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 2001:XXX:YYYY:ZZZZ:WWWW::1111/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::2e0:4cff:fe53:4458/64 scope link
       valid_lft forever preferred_lft forever
5: enp2s0: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 2001:XXX:YYYY:ZZZZ:WWWW::3333/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::216:d3ff:feb3:34a5/64 scope link
       valid_lft forever preferred_lft forever

在 Windows 计算机上（使用以下 IPv6 地址，静态）：

IPv6 address: 2001:XXX:YYYY:ZZZZ:WWWW::6666
Subnet prefix length: 64
Default Gateway: 2001:XXX:YYYY:ZZZZ:WWWW::1111

Linux网关路由表：

# ip -6 route
2001:XXX:YYYY:ZZZZ::/64 dev enp0s29f0u2  proto kernel  metric 256
2001:XXX:YYYY:ZZZZ::/64 dev enp2s0  proto kernel  metric 256
fe80::/64 dev enp0s29f0u2  proto kernel  metric 256
fe80::/64 dev enp2s0  proto kernel  metric 256
ff00::/8 dev enp0s29f0u2  metric 256
ff00::/8 dev enp2s0  metric 256
default via fe80::1614:4bff:fe60:63eb dev enp2s0  metric 5

我有一个 Linux 机器作为路由器（enp2s0、enp0s29f0u2），其他的是 Windows 电脑。'Wan' 连接到 Linux 机器适配器 enp2s0，enp0s29f0u2 连接到无线路由器（交换机模式（dhcp 关闭）），所有 Windows PC 都连接到无线路由器。

答案1

您的网关配置中有一个明显的错误。两个接口都配置了相同的/64。

在正确的配置中，您使用关联在 WAN 接口上使用从提供商处获得的前缀，然后使用路由前缀。如果路由前缀比 a 短/64（应该是 a），那么您可以/64从中/48为您的 LAN 挑选任意一个。例如，如果您的提供商为您提供了路由前缀2001:db8:1234::/48，您的 LAN 前缀可以是2001:db8:1234::/64、2001:db8:1234:ffff::/64、2001:db8:1234:babe::/48，或者其他 65533 种可能中的任何一种。

运行时会发生的情况tcpdump是（默认情况下）将网络接口转换为混杂模式，这意味着即使以太网帧未发送到该网络接口的 MAC 地址，硬件也会开始接受以太网帧。

目前尚不清楚这两者之间如何可能存在联系。但可以提出一个假设，然后进行检验。

网关可能会在收到邻居发现请求后，使用另一个接口的 MAC 地址进行响应。考虑到两个接口都配置了相同的 MAC 地址，这至少是一种合理的行为/64。但是，当数据包发送到另一个 MAC 地址时，网络接口将丢弃它们，直到网络接口切换到混杂模式。

你可以做很多事情来检验这个假设：

  • tcpdump不使用混杂模式（-p开关）运行。如果tcpdump在混杂模式下有帮助，但在其他模式下没有帮助，我们已经确认混杂模式会有所不同。
  • 观察邻居发现答复中发送的 MAC 地址，并将其与两个网络接口进行比较。
  • 观察发送到 IP 地址的数据包上的目标 MAC 地址，以查看它们被发送到哪个 MAC 地址（这可以使用 Ethereal 或在混杂模式下完成tcpdump）。
  • 重新配置配置了错误网络前缀的接口，看看是否有帮助。

相关内容