通过网桥运行 IPv6 时未收到数据包

Question

我有一个带有两个网络接口的设置：eth0和tap0，桥接br0

bridge name     bridge id               STP enabled     interfaces
br0             8000.************       no              eth0
                                                        tap0

除了本地 IPv6地址之外，既没有eth0也tap0没有 IP 地址eth0：

2: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UP group default qlen 1000
    link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
    inet6 fe80::XXXX:XXXX:XXXX:XXXX/64 scope link 
       valid_lft forever preferred_lft forever
41: tap0: <NO-CARRIER,BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc fq_codel master br0 state DOWN group default qlen 100
    link/ether YY:YY:YY:YY:YY:YY brd ff:ff:ff:ff:ff:ff

但是，网桥具有静态 IPv4 地址和无状态配置的 IPv6 地址。因为我需要配置这个无状态的 IPv6 地址，如果是为了eth0，我配置的 MACtap0大于的 MAC eth0（因此 brctl 会选择eth0MAC 作为br0MAC）。因此，br0分配给自己的 IP 地址与eth0没有任何其他接口时选择的 IP 地址相同。

请注意，隐私扩展被禁用（在all任何特定接口上）。

所以br0看起来像这样：

42: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
    inet 192.168.X.Y/24 brd 192.168.X.255 scope global br0
        valid_lft forever preferred_lft forever
    inet6 ZZZZ:ZZZZ:ZZZZ:ZZZZ:ZZZZ:ZZZZ:ZZZZ:ZZZZ/64 scope global 
        valid_lft 7123sec preferred_lft 3523sec
    inet6 fe80::ZZZZ:ZZZZ:ZZZZ:ZZZZ/64 scope link 
       valid_lft forever preferred_lft forever

所以有一个公共地址和一个本地 IPv6 地址，公共地址与 MAC 匹配（因为它是由无状态选择的）。当我现在发送 ICMPv6 数据包时，我没有收到回复：

PING google.com(2a00:1450:4001:80e::1008) 56 data bytes
^C
--- google.com ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 1999ms

然而，当使用 tcpdump 检查时，我看到数据包正在发送，回复到达服务器和我的 IP，即我实际上在数据包转储中看到回复，并且它被寻址到br0. 我试图指定每个接口，ping6 -I <interface>但没有成功。

所以现在我没有想法：我发送数据包，收到正确地址的回复，但系统似乎仍在丢弃它而不是接受它。为什么它会丢弃它们？这个可以调试吗？

编辑：我确实有 IPv6 路由，运行ip -6 route收益：

XXXX:XXX:XXXX:XXXX::/64 dev br0  proto kernel  metric 256  expires 6997sec
fe80::/64 dev br0  proto kernel  metric 256 
fe80::/64 dev eth0  proto kernel  metric 256 
default via fe80::XXX:XXXX:XXXX:XXXX dev br0  proto ra  metric 1024  expires 1597sec

第一行是我的路由器 (Fritz Box) 中报告的 ISP 分配的前缀，这似乎是正确的，因为这应该是我的本地网络（对吗？），所以我不需要网关。另外两个是链接本地地址，再次很好。

现在的最后一条路线应该很有趣吧？我在那里找到的 IP似乎与我的路由器相匹配。我可以 ping 它，但前提是指定接口，即运行ping6 <ip>产量：

connect: Invalid argument

但ping6 -I br0 <ip>有效：

PING <ip>(<ip>) from <myip> br0: 56 data bytes
64 bytes from <ip> icmp_seq=1 ttl=64 time=0.534 ms
64 bytes from <ip> icmp_seq=2 ttl=64 time=0.393 ms
64 bytes from <ip> icmp_seq=3 ttl=64 time=0.350 ms
64 bytes from <ip> icmp_seq=4 ttl=64 time=0.369 ms
^C
--- <ip> ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 2999ms
rtt min/avg/max/mdev = 0.350/0.411/0.534/0.075 ms

当然<ip>是路由器的IP，也就是fe80::...上面的地址。我在我的路由器配置中找不到它告诉我这个地址的点，但是，我确实找到了它的唯一本地地址（ULA）并且它以fd80::但除此之外是相同的，所以我非常有信心这是我的路由器 IPv6 地址。

但是：我可以使用nslookup -query=AAAA fritz.box它来查找我的路由器 IP，这会产生两个响应：ULA ( fd00::...) 和前缀 ( 2a02:...) 中的 ISP 分配的 IPv6 地址具有相同的后缀（我猜它是通过使用 SLAAC 和 MAC 来选择它的） . 这里没有出现的fe00:...是在路由中输入的以它开头的 IP 。

也许有人对这种奇怪的行为有一个解释......

Answer 1

我不能说我可以追踪到问题的根源，但至少我找到了一个“黑客”来让它发挥作用。我必须确保我的网桥实际上从我的eth0接口获取 MAC，而不是随机分配的tap0MAC。为了确保这种情况发生，您只需确保您的tap0地址大于eth0：

/usr/bin/openvpn --mktun --dev tap0
ip link set dev tap0 down
ip link set dev tap0 address 5a:c0:02:9e:ae:3c
ip link set dev tap0 up

现在创建网桥将选择eth0的 MAC，然后将正确配置 SLAAC。我不明白为什么它会这样工作，但现在甚至端口转发也工作正常，一切看起来都很好。

现在，路线似乎设置正确，我可以到达外部和内部系统。