IPv6 はパブリックをサブネットにルーティングします。

IPv6 はパブリックをサブネットにルーティングします。

プロバイダからクライアントへのLinux / Debian IPV6ルーティングは機能しません。
IPV4 NAT/ルーティングはiptables安定して動作しますdnsmasqが、IPv6 で転送が有効になっていても動作させることはできません。
RADVDは新しいネットワークをリリースしますが、パブリックIPv6アドレスにアクセスできません。

簡略化された図面

                                        SW
                                         |    +---------+
                                         +--->| client  |
             PUBLIC              PRIVATE |    +---------+
                                         |
    ~/-(PR)-+       +---(ER)---+         | C0 +--(CL)---+
     public |P0  E0 | extender | E1      +--->| client  |
     vendor |<----->|  router  |<------->|    +---------+
            |       +----------+         |
 ~/---------+                            |    +---------+
                                         +--->| client  |
                                         |    +---------+

 Where:
    PR ISP Public router
       P0 Public network interface
    ER extender router Debian based, trying to configure
       E0 Public network interface
       E1 Private network interface
    CL Test Client
       C0 Private network interface

radvdumpER(アドレス編集)を使用してパブリックパスを表示する

    ...
    route 2600:..:5b10::/60
    {
            AdvRoutePreference high;
            AdvRouteLifetime 1209600;
    }; # End of route definition

ER はradvdE1 (2600:..:5b11) に新しい /64 ネットワークをパブリッシュし、
CL はパブリッシュされたネットワークを受信し、2600:..:5b11 ネットワークのグローバルアドレスとして自己構成します。
ERはping6を実行し、ipv6.google.com、P0、E0、E1、C0に接続できます。
CLはping6を実行してE0とE1に接続できますが、.. P0(パブリックアドレスではありません)

ER-> E1にtcpdumpERの定期ルーター広告を表示します。
CLでパブリックアドレスをpingすると、ER-E1でキャプチャされる内容は次のとおりです。

fe80::..:d477 is ER-E1
fe80::..:dff6 and 2600:..:5b11:..:f48 are CL-C0
fe80::..:f380 is PR-p0
2607:f8b0:4002:c0c::8a is ipv6.google.com

IP6 fe80::..:d477 > ff02::1: ICMP6, router advertisement, length 56
IP6 2600:..:5b11:..:f48 > 2607:f8b0:4002:c0c::8a: ICMP6, echo request, seq 1, length 64
IP6 fe80::..:dff6 > fe80::..:d477: ICMP6, neighbor solicitation, who has fe80::..:d477, length 32
IP6 fe80::..:d477 > fe80::..:dff6: ICMP6, neighbor advertisement, tgt is fe80::..:d477, length 24
IP6 fe80::..:d477 > fe80::..:dff6: ICMP6, neighbor solicitation, who has fe80::..:dff6, length 32
IP6 fe80::..:dff6 > fe80::..:d477: ICMP6, neighbor advertisement, tgt is fe80::..:dff6, length 24
IP6 fe80::..:d477 > ff02::1: ICMP6, router advertisement, length 56

CLへのPingはメッセージなしで中断されます(タイムアウトまで)。

ER->E0 tcpdump(単純化):

IP6 2600:..:5b11:..:f48 > 2607:f8b0:4002:c0c::8a: ICMP6, echo request, seq 1, length 64
IP6 fe80::..:c446 > fe80::19d7:1db3:c381:23a: ICMP6, neighbor advertisement, tgt is fe80::..:c446, length 24
IP6 fe80::..:c446 > fe80::..:f380: ICMP6, neighbor solicitation, who has fe80::..:f380, length 32
IP6 fe80::..:f380 > fe80::..:c446: ICMP6, neighbor advertisement, tgt is fe80::..:f380, length 24
IP6 fe80::..:f380 > fe80::..:c446: ICMP6, neighbor solicitation, who has fe80::..:c446, length 32
IP6 fe80::..:c446 > fe80::..:f380: ICMP6, neighbor advertisement, tgt is fe80::..:c446, length 24

ERルーティングテーブル(eth0 = E0 eth1 = E1)

2600:..:5b10::13 dev eth0 proto kernel metric 256  pref medium
2600:..:5b10::/64 dev eth0 proto kernel metric 256  expires 1209445sec pref medium
2600:..:5b10::/64 dev eth0 proto kernel metric 303  mtu 1500 pref medium
2600:..:5b11::/64 dev eth1 proto kernel metric 256  pref medium
fe80::/64 dev eth0 proto kernel metric 256  pref medium
fe80::/64 dev eth1 proto kernel metric 256  pref medium
default via fe80::..:f380 dev eth0 metric 303  mtu 1500 pref medium
default via fe80::..:f380 dev eth0 proto ra metric 1024  expires 1645sec hoplimit 64 pref medium

この時点ではファイアウォールは含まれず、ip6tablesも含まれません。

ERでは、すべてのデフォルト値にForward = 1とProxy_ndp = 1を設定しました。

ベストアンサー1

ご覧のとおり、ping echoリクエストはE1に到着してE0に発行されるため、ERではすべてが正常です。

しかし、PRに問題があります。 pingエコー応答が到着すると、宛先アドレスがあります2600:...:5b11:...:f48。ただし、PRは5b10/60P0の背後にあるサブネットについてのみ知っており、E0を介して接続できる他のサブネットがあることに気付いていません5b11/64。だから私の推測する(インターフェイスダンプでこれを確認する必要があります)2600:...:5b11:...:f48P0はネイバー要求を実行するPRですが、ERは応答しないため(アドレスを所有していないため)PRはパケットを破棄します。

このようにサブネットを使用してIPv6を設定したことがないので、何を推奨するのかわかりません。私が試した最初のことは、E0に広告を5b11/64送り、この追加情報が原因でP0がパケットを転送することを確認することでした。

編集する

私が見つけたNDPPD、隣人はプロトコルエージェントの悪魔を発見します。 PRがネイ​​バー要求を送信したが応答を受信しなかった場合、ERでndppdを使用すると問題が解決する可能性があります。

私はまだそれを直接使用していません。

おすすめ記事