IPv4 VPNサーバー経由のIPv6には依然としてIPv6出口が必要

トンネルは上がり、クライアントはプールからIPv6アドレスを受け取りますが、それでもすべてのIPv6宛先がタイムアウトします。トンネル内で壊れているものは何もなく、IPv6はIPv4トランスポートの中をまったく問題なく走り、それは決して難しい部分ではありませんでした。あなたが配ったアドレスは、出口にはそれを送り込む先のIPv6アップストリームがないため、サーバーが守れない約束です。修理すべきは出口であり、クライアントプロファイルではありません。

症状：アドレスはあるが経路がない

クライアント側の確認では、トンネルデバイスにグローバルに見えるIPv6アドレスと、そこを指す経路が表示されるため、これがクライアントの不具合と誤読されます。通信はトンネルに入り、サーバーがカプセル化を解き、その後パケットは、経路テーブルに実在の場所へのIPv6デフォルトルートがないホストに着地します。スタックによっては即時の到達不能か、静かな破棄になり、どちらの場合もクライアントにはファイアウォールと見分けのつかないタイムアウトが見えます。

経路の欠けている半分はそこに住んでいるため、クライアントに触る前にサーバー自身の経路テーブルを読んでください。IPv4デフォルトルートが一本だけあるサーバーは、すでに答えを出しています。

カプセル化を解いた後のパケットを追う

トンネル内のパケットは通常のIPv6で、その送信元はクライアントのアドレスです。サーバーはトランスポートのカプセル化を剥がし、次にIPv6のネクストホップへ転送すべきネイティブIPv6パケットを保持します。IPv4のデフォルトルートはそれを運べず、IPv4へ変換するのは誰も配備していない別の機能です。これが失敗のすべてであり、VPNリスナーがIPv4で応答したかどうかとは何の関係もありません。

IPv6 over IPv4のカプセル化の仕組みはRFC 4213に記述されており、そこでの重要な点は、端点にはトンネルの反対側で依然として実際のIPv6接続が必要だということです。ヘッダーを包んでもアップストリームは生まれません。

二つのトンネル層、二つの独立した確認

動作している外側のトンネルは壊れた内側のトンネルを隠すため、各層を別々に検証してください。外側の経路はクライアントからサーバーへのIPv4 pingで確認し、使用するポートを確かめたうえで、次にサーバー上で内側の経路を確認します。そこでは ip -6 route 実際のアップストリームから学習したデフォルト経路または特定の経路を示す必要があり、 ip -6 addr アップストリームが受け入れる送信元プレフィックスを示す必要があります。それ未満はインターフェース上の飾りにすぎません。

ユニークローカルアドレスや、何も戻って経路付けしないグローバルに見えるプレフィックスは、喜んでインターフェースに現れてどこにも行きません。公共の到達性はアップストリームが与えるものであり、アドレスの形が与えるものではありません。

同じことがクライアントにも当てはまります： ip -6 route get 2001:4860:4860::8888 トンネルデバイスを指すべきであり、物理デバイスを指しているなら、クライアントはIPv6にVPNをまったく使っていません。

送信元プレフィックス、サイズ、ICMPv6

アップストリームに、転送のためにどの送信元プレフィックスを受け入れるかを尋ね、そのうちの一つをクライアントプールに使ってください。サーバー自身のインターフェース用に/64を渡すプロバイダーが、二つ目の/64やより大きなブロックをあなたへ経路付けしているとは限らず、その違いはサポートチケットが一つの質問で片づける半日のデバッグです。書面で尋ね、回答を設定と一緒に保管してください。

スタックが実際に使う追加のカプセル化を見込んでおき、Packet Too Bigを含めてICMPv6を動作させ続けてください。二つ目のヘッダーは使えるペイロードを縮めるので、小さなpingに応答する経路でもファイル転送では失敗し得ますし、すべてのICMPv6を落とすファイアウォールは修復可能なサイズ問題をブラックホールに変えます。サービスを告知する前に大きな転送を一回テストしてください。

まったく別の問題とは

IPv4しか使わないアプリケーションにIPv6しか使わないクライアントから到達するのはトンネリングではなく変換であり、意図的に配備されたNAT64のような仕組みが必要です。宛先は、あなたが余分なトンネルヘッダーを足したからといってそれを理解するわけではありません。歴史的な移行サービスにも同じ注意が必要であり、RFC 7526は6to4 anycastリレーモデルを廃止したので、それを前提に書かれた手順書は、もはや保守された公開リレーを持たないものを説明しています。

サーバーに使えるIPv6アップストリームがない場合、選択肢はサポートされたアップストリーム、別の出口、またはIPv6をトンネルの外に置くという文書化された決定です。受け入れられないのは、IPv6サービスが存在するとクライアントに告げながら、 彼らの通常のIPv6接続が静かにVPNを迂回していることです。