パブリック IP が変わり VPN が通信を通さなくなった

ISP の再接続や上流での変換の変更は VPN セッションのパブリックな送信元を変えますが、クライアントのローカルなプライベートアドレスは通常そのままとどまります。そのためトンネルは接続済みに見えるのに、中を何も有効に通っていない状態になります。この二つの観察は同時に成り立つので、報告が紛らわしくなるのです。

四つの確認を順番に進め、最初に失敗したところで止めます。

実際に変わったのはどのアドレスか

ローカルインターフェースの状態を、遠隔のエンドポイントが見ている送信元と比較します。比較してよいと認められた地点で行ってください。新しいパブリックアドレスは新しいローカルゲートウェイを意味しませんし、ローカルインターフェースの変化もパブリックな送信元が動いたことを保証しません。その間の変換があるため、両者は独立した事実です。正確な経路と観測した時刻を記録してください。古い報告からコピーした位置情報ラベルは別の問いに答えるものだからです。

外側の送信元が変わったのか、内側のトンネルアドレスが変わったのか、両方なのかを明確に尋ねてください。最初のものだけが、もはや存在しない経路へ送り続ける相手を説明します。

移動はプロトコルに任せる

ピアが移動したことを知る方法はプロトコルごとに異なります。そしてその違いは、そもそも介入すべきかどうかに影響します。WireGuard は、そのピアの鍵で認証されるパケットを受け取るとピアのエンドポイントを更新するので、設定なしでアドレス変更を吸収できます。IKEv2 には同じ目的の MOBIKE があり、両端が対応していれば使えます。古い設計は代わりにトンネルを作り直して復旧します。

してはいけないのは、認証されていないメッセージを、ピアの識別情報が移った証拠として受け入れることです。新しいアドレスを主張するデータグラムの偽造は簡単で、攻撃者のエンドポイントへ誘導できるとクライアントが信じてしまうからです。仕組みは認証されたプロトコルであり、通知ではありません。

wg show wg0 endpoints
wg show wg0 latest-handshakes
conntrack -L -p udp --dport 51820 | head -n 10

古い外側のバインドを消す

プロトコルがローミングに対応しているのに通信が失敗し続けるとき、障害は多くの場合、途中にある状態保持型の機器です。あるいは遠端のポリシーです。古いフローを追跡していたファイアウォールは古いエントリを残すことがあり、古い送信元に紐づいたサーバー側のアクセス規則は新しいものを黙って落とします。マッピングを消して規則を再確認するほうが、資格情報を入れ替えるより速いです。

調査の間は必要な遮断を維持してください。トンネルが復旧するかを試すためにポリシーを大きく開いても原因については何も分からず、導入状態を元より悪くするだけです。

新しいリクエストで再試験する

変更前に確立したアプリケーションセッションは生き残りません。土台にしていた四つ組がもう存在しないからです。復旧後に新しいリクエストを生成し、それが完了することを確認してください。古いダウンロードがゼロのままとどまるのを見てトンネルがまだ壊れていると判断するのではなく。この一つの区別が、こうした報告の多くを解決します。

そのうえで診断の両半分を記録します。上流で何が変わったのか、どの対応済みの復旧手順でフローが戻ったのか。次回はもっと速くなり、そのメモこそが速くする理由です。

新しいリクエストが成功し、古いものが決して再開しないなら、トンネルは直っており、アプリケーションは再接続するだけで済みます。