IPv6 だけのネットワークはトンネルが始まる前に VPN を壊す

ノート PC が IPv6 だけを配る会議場の Wi-Fi に接続し、VPN クライアントは回り続けて失敗するが、同じプロファイルは一時間前のホテルでは動いていた。認証情報は何も変わっていない。変わったのは、クライアントが IPv6 だけを運ぶネットワークを通って IPv4 の宛先に到達しなければならなくなったことであり、すべてのクライアントがその方法を知っているわけではない。

パケットが通るのと同じ五つの手順をたどる。

ステップ 1：名前解決を見る

プロファイルがホスト名を使うなら、最初の問いはリゾルバが何を返すかである。dig AAAA vpn.example.com は IPv6 だけのネットワークで、本物の AAAA レコードを返すか、DNS64 による合成レコードを返すか、何も返さない。合成された応答は変換プレフィックスの中に IPv4 の宛先を符号化しており、そのとき初めて IPv6 の宛先を持たないクライアントが到達できる。IPv4 アドレスを直書きしたプロファイルは、合成すべき名前が存在しないためここまで来ない。

その一つの違いが「あちらでは動くのにこちらでは失敗する」という報告の大半を説明し、見るのにコマンド一つで足りる。

ステップ 2：クライアントが呼んだアドレスファミリーを見る

進行バーではなくソケットを見る。IPv6 だけのリンク上で IPv4 アドレスへ IPv4 ソケットを開くクライアントは送り先を持たず、失敗は名前のエラーではなくタイムアウトとして現れる。接続中の ss -tanp は、リモートアドレスと試みたアドレスファミリーを示す。それを ip -6 route と比べ、既定が本物の IPv6 ネクストホップであることを確かめる。

ソケットテーブルのアドレスファミリーが事実である。進行バーは誰かが書いた要約だ。

ステップ 3：変換とトンネルを分ける

NAT64 と DNS64 はアクセスネットワークが IPv4 の宛先に到達する方法であり、トンネルが上がった後はトンネルに対して何もしない。変換された経路の上に張られたトンネルは、それでも自分自身の内部アドレッシングを交渉し、内部の IPv4 または IPv6 のカバレッジは別のポリシー問題である。クライアントが接続しても何にも届かないなら、変換は済んでおりルーティングに入っているので、証拠の異なる別の調査になる。

変換の失敗は、決して接続しないように見える。内部カバレッジの失敗は、接続するが何にも届かないように見える。

ステップ 4：同じプロファイルを別のネットワークで試す

同じプロファイル、クライアントのバージョン、認証情報をデュアルスタックのネットワークに持ち込んで繰り返す。そこで動き、IPv6 だけの経路で失敗するなら、変数はプロファイルではなくアクセスネットワークである。最終的な修正はクライアントの更新か別の宛先だから、クライアントのバージョンとネットワークの状態をチケットに記録する。

VPN が壊れているという報告は対応できない。IPv6 だけのアクセスでのみ失敗するという報告はバグ報告である。

ステップ 5：セキュリティ設定ではなく経路を直す

誘惑される修理はどれも事態を悪化させる。IPv6 を無効にすると、ネットワークが提供する唯一の経路が消える。クライアントを公開リゾルバに向けると、その合成は変換器の後ろのリゾルバから来る必要がある DNS64 の合成が壊れる。証明書の検証を切ると、正体を確認できない何かへの接続が得られる。どれも修理ではなく、そのうち二つはインシデントより長く残るセキュリティの後退である。

本当の選択肢は、ネットワーク変換モデルを支えるクライアントか、到達可能な IPv6 アドレスを持つ宛先である。どちらかを求めよう。