IPv6近隣探索がルーテッドVPN越しに失敗する理由

IPv6の近隣探索は一つのリンクに属し、ルーテッドトンネルは二つのリンクの境界です。この一文で、アドレスには応答するのに他の何でも見つからない遠隔ホストの報告はほぼすべて説明できます。トンネルを調べる前に、テストしているアドレスのスコープを確認してください。リンク内アドレスはそのリンク上でのみ意味を持ち、要求ノードのマルチキャストグループも同じように限定されます。どちらもルーターを越えないため、グローバルアドレスへの ping が成功しても同じホストの探索は失敗します。

スコープが設定より先

近隣要請と近隣通知はホップ制限 255 を持ち、設計上転送されません。トンネルと遠隔 LAN の間のルーターは IPv6 パケットを転送しますが、近隣メッセージを代理で中継することはありません。したがってトンネルインターフェースの近隣キャッシュには相手とわずかな情報しか入りませんが、これは修正すべき欠陥ではなく正しい動作です。

fe80:: のようなリンク内アドレスもゾーンで限定され、同じ表記が別のリンクでは別のホストを指すことがあります。トンネルの反対側から試しても、そのアドレスが曖昧だという以外のことは何も証明できません。

罠はプレフィックスがリンク上にあるという思い込み

プレフィックスがリンク上にあると信じるホストは、パケットをルーターに渡さず近隣要請を送り、遠隔サイトへルーティングされた /64 もこれに当たります。そのようなプレフィックスがリンク上として届くと、ホストはローカルリンクに別の場所にいるホストを問い合わせ、誰も応答しません。遠隔ホストにはより小さな範囲をルーティングするか、その代理を答えるルーターでプレフィックスを終端してください。

単一サービスに /128 を使うのが最も驚きの少ない構成で、曖昧さを完全に取り除きます。近隣探索の仕様はメッセージ集合と、これを決めるリンク上のフラグを記述しています。

ブリッジは意図的にルールを変える

トンネルが Ethernet フレームを運ぶと、遠隔とローカルのセグメントは一つのリンクになり、マルチキャストは両側に届き、近隣探索はスイッチ上と同じように振る舞います。それに伴って、ブロードキャストとマルチキャストの氾濫、ブリッジをまたぐ重複アドレス検出、見えるべきでないセグメントへ漏れるルーター通知といった結果が生じます。障害ドメインも二つのサイトに及びます。どれもブリッジに反対する論拠ではなく、どれも偶発的ではなく意図的にブリッジする理由です。

探索を出現させるためにプロファイルを TUN から TAP に変えるのは、手順の順序として誤りです。サーバー、クライアント、アドレス計画が一致している必要があり、モバイルクライアントは TAP インターフェースを提供しないため、そのような設計はノートPCでは動き、スマートフォンでは失敗します。近隣プロキシとリレーは独自の要件を持つ別の仕組みであり、アプリの設定ではなくネットワーク管理者の文書化された取り決めに属します。

アプリが使うアドレスでテストする

ip -6 route get で経路を確認し、ip -6 neigh で近隣エントリを調べ、次に ルーティングされた経路でサービスを確認します。DNS と戻り経路は別の確認であり、健全な近隣エントリはどちらも証明しません。

アプリがリンク内または探索ベースの宛先を主張する場合、それは調整の演習ではなく設計の会話であり、クライアント設定ではリンク限定の仕組みをルーター越しに機能させることはできません。

どちらの設計かを書き留める

二つの配備がこの問いに異なる答えを出し当番のエンジニアがプロファイルから推測すべきではないため、インシデントの前にルーテッドかブリッジかを記録してください。

メッセージ集合を一度読めば、リンクスコープの性質を VPN の不具合として説明したくなる誘惑が消え、この分野で最も高くつく誤診を避けられます。