web-dev-qa-db-ja.com

ブリッジを介してIPv6を実行しているときにパケットが受信されない

eth0によってブリッジされたtap0とbr0の2つのネットワークインターフェイスを備えたセットアップがあります。

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

eth0もtap0もeth0のローカルIPv6アドレス以外のIPアドレスを持っていません。

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アドレスがあります。 eth0の場合は、このステートレスIPv6アドレスを構成する必要があるため、tap0のMACをeth0のMACよりも大きく構成しました（したがって、brctlはeth0MACをbr0MACとして選択します）。その結果、br0が自分自身に割り当てるIPアドレスは、eth0が他のインターフェースなしで選択するものと同じです。

プライバシー拡張機能が無効になっていることに注意してください（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

したがって、1つのパブリックIPv6アドレスと1つのローカル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の間でパケットが送信され、応答が到着していることがわかります。つまり、実際にはseeパケットダンプ内の応答であり、IPv6アドレス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が割り当てたプレフィックスであり、これはローカルネットワークである必要があるため（正しいですか？）、ゲートウェイは必要ありません。他の2つはリンクローカルアドレスなので、やはり問題ありません。

今の最後のルートは何が面白いはずですよね？そこで見つけた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を検索すると、2つの応答が生成されます：ULA（fd00::...）と、同じサフィックスを持つプレフィックス（2a02:...）内のISPが割り当てたIPv6アドレス（推測します） MACでSLAACを使用してこれを選択します）。ここに表示されないのは、ルートに入力されたfe00:...で始まるIPです。

多分誰かがこの奇妙な行動の説明をしています...

linuxnetworkingipv6
5
javex

問題の根本を突き止めることができたとは言えませんが、少なくともそれを機能させるための「ハック」を見つけました。ブリッジが、ランダムに割り当てられたeth0 MACではなく、実際にtap0インターフェイスからMACを取得したことを確認する必要がありました。これを確実に行うには、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用に正しく構成されます。正確にはわかりませんgetなぜこのように機能するのか、しかし今ではポートフォワーディングでも正常に機能し、すべてが問題ないようです。

ルートが正しく設定されているように見え、外部システムと内部システムに到達できます。

1
javex

/etc/sysctl.confでipv6転送を有効にすることを覚えていますか？

行を変更します

 #net.ipv6.conf.all.forwarding=1

に

 net.ipv6.conf.all.forwarding=1

ただし、これによりステートレス自動構成が無効になります。

0
MariusMatutiae