/64 を分割しても IPv6 は VPN クライアントにルーティングされない

クライアントはグローバル IPv6 アドレスを表示し、ハンドシェイクは完了しているのに、インターネットから何も返ってきません。プール設定は正しいからこそ正しく見え、アドレスは有効で、トンネルはそれを運んでいます。失敗しているのは配送であり、配送は VPN サーバーの上流で下される判断に依存していて、クライアント側の設定では一切影響を与えられません。

誤解：あなたの /64 の一部はすでに到達可能

その話は魅力的です：サーバーに公開 /64 があり、それを半分に分け、残り半分を VPN プールに渡せば、それらのクライアントはインターネット上にいる、というものです。プレフィックスを分割すれば確かに衝突なくアドレスを割り当てられます。しかし、それらのアドレスの一つ宛てのパケットがどこへ行くべきかを上流ネットワークがどう決めるかは変わりません。

IPv6 には頼るべき既定の変換層がないため、戻り経路はルーティングとして、またはリンク層の配送として存在しなければなりません。クライアントのトンネルアドレス宛てのパケットは上流ルーターに届き、そのルーターは自分のテーブルから転送を判断します。テーブルが物理リンクを指していれば、VPN サーバーが何を信じていようとパケットはそこへ行きます。

これが失敗のすべてです：行きの方向はサーバーが送るので機能し、戻りの方向は上流がクライアントの存在を一度も知らなかったために、一ホップ先で死にます。

リンク上の配送が本当に必要とするもの

上流が /64 全体を物理リンク上にあると見なすと、各宛先アドレスを近隣探索で解決します。そのリンク上に要請を送り、アドレスの所有者が応答することを期待します。トンネルの背後にいる VPN クライアントはそのリンク上におらず応答できないため、要請は無応答のままとなり、パケットは破棄されます。

/65 を切り出してもその期待は変わりません。上流は依然としてその範囲をリンク上として扱うのは、考えを変える唯一のものが、クライアントの代わりに応答するルートかプロキシだからです。VPN 設定を編集しただけではどちらも現れません。この隙間こそが、プールが自分自身のクライアント間では完璧に機能しながら、他のどこからも到達できない理由です。

プロキシ近隣探索は二つの世界を橋渡しできる仕組みです。ゲートウェイは自分が所有する特定のクライアントアドレスへの要請に応答し、トラフィックをトンネルへ転送します。これは機能しますが、もう提供していないアドレスの代わりに応答することが他人のトラフィックをブラックホール化するため、プールに追随するライフサイクルを持つまさにそのアドレスに限定しなければなりません。上流によっては予期しないプロキシ応答を受け付けないため、この設計にはプロバイダーの同意も必要です。

ルーティングされた配送が必要とするもの

よりクリーンな設計は、上流が実際にあなたのゲートウェイへルーティングする割り当てです。それは委任されたプレフィックスか、より小さなブロックへの静的ルートであり、どちらでも要件は同じです。上流のテーブルがクライアント範囲についてあなたのサーバーを指していなければならず、そうなれば戻りトラフィックはゲートウェイに届き、ゲートウェイがそれをトンネルへ転送します。

ルーティングされた配送は近隣探索の問いを完全に取り除きます。だからこそ、何か巧妙なものを構築する前にプロバイダーへそれを求める価値があり、ルートは書面で要求し、次のホップが上流から実際に到達できるアドレスであることを確認してください。

どちらの設計も、ゲートウェイでの IPv6 転送の有効化と、転送フローを両方向に許可するファイアウォール規則を必要とします。配送は経路の残りにとって前提であり、代替ではありません。転送を無効にしたまま機能するルートは、ルートが欠けているのとまったく同じ沈黙を生むため、何かを再設計する前に両方を確認してください。

正しく設定すべき二つの独立したルート

プールのプレフィックスとクライアント自身の既定ルートは別の設定であり、混同するとトンネルが壊れたように見える部分的な接続になります。プールはサーバーにどのアドレスを配布するかを伝えます。クライアントのルートは、クライアントがどの宛先をそもそもトンネルへ送るかを決めます。

server-ipv6 2001:db8:42:100::/64
push "redirect-gateway ipv6 !ipv4"

上記のプレフィックスはドキュメント用の空間であり、リダイレクトは IPv6 のみに適用されます。それは、IPv6 の配送がまだ修正されている間にデュアルスタック展開がしばしば望むことそのものであり、IPv4 のリダイレクトは IPv6 のカバレッジを確立せず、どちらの設定も他方を含意しません。

適用するポリシーにかかわらず、IPv6 が依存する制御トラフィックを機能させ続けてください。Packet Too Big メッセージは TCP と UDP だけを許可するファイアウォールの典型的な犠牲者であり、それらを落とすと、接続は確立するものの大きな転送で止まるようになります。

ルーター広告は三つ目の可動部です。ゲートウェイが上流リンクで広告を始めると、クライアントや近隣がリンク上のプレフィックスについて信じる内容が変わり、いま文書化した設計を静かに無効にしてしまう可能性があります。

設計を記録して、再構築がそれを再現できるようにする

クライアントの割り当て、クライアントの宛先ルート、そして割り当てに対する上流の配送方法という三つの対象を別々に書き留めてください。三つすべてを持つ読者は展開を再構築でき、プール設定だけを持つ読者は元のバグを再現します。

次に、外から戻ってこなければならないパケットで、戻り方向を明示的にテストしてください。openvpn(8) のマニュアルは server-ipv6 と redirect のオプションを扱っており、プロバイダーのルーティング確認がマニュアルでは扱えない半分を補います。