再帰ルーティング：トンネルが自分のパケットを捕まえるとき

トンネルが上がり、ログにはハンドシェイク完了と出て、その一秒後に同じセッションが落ちてループ状に再接続します。このパターンには明確な原因があります——サーバーへの経路がいまトンネルの内側を指しているため、トンネルを運ぶパケットがトンネルの中へ送られているのです。認証は何も変わっていないので、資格情報を入れ直しても意味がありません。ルート変更の前後で外側の経路を比べれば、再帰はすぐに見えます。

まず外側の経路を確認する

関係するパケットは一つではなく二つです。内側のパケットはアプリケーションのもので暗号化されるべきものであり、外側のパケットはサーバー宛てで、トンネルに依存しない経路でそこへ届かなければなりません。

ip route get 198.51.100.7
ip rule show
ip route show table all | grep -F 198.51.100.7
wg show wg0 endpoints

トンネルが上がったあと、カーネルにサーバーのアドレスへの経路を尋ね、デフォルトルートが変わったあとにもう一度尋ねます。次のホップがトンネルデバイスに落ちるなら、それが再帰そのもので、パケットキャプチャをしなくても分かります。インターフェースへの束縛、マーク、ネットワーク名前空間があると単純な検索は不完全になるので、クライアント自身が使う文脈で確かめてください。答えが正しく見えるのにセッションがループし続けるときは、メインテーブルだけでなくルーティングポリシーの規則を読んでください。

セッションが一瞬だけ生き残る理由

新しいルートが入る前にハンドシェイクは完了するので、最初の数秒は正常に見えます。クライアントがデフォルトルートを足した瞬間、次の外側パケットはそれに従って、そのパケットが通るべきインターフェースへ入っていきます。サーバーには何も届かず、クライアントは再送し、試行はタイムアウトするかセッションを切ってやり直しになります。

この順序が、ノートPCでは動いてルーターでは失敗する理由と、接続時ではなく通信が始まったときに障害が起きやすい理由を説明し、ループも説明できます。再起動のたびに、経路が不可能にする前にセッションが復旧してしまうのです。

端点の例外を誰が持つか突き止める

対応しているクライアントは自分で例外を用意します。元のゲートウェイ経由でサーバーへのホストルートを通すか、外側ソケットをトンネルの外に保つマークを使いますが、問題は、ほかの何かがそれを消したか上書きしたかどうかです。

ルートベースの IPsec では、どのパケットがトンネルに入るかを決めるポリシーセレクターを調べ、ピアのアドレスが除外されていることを確認します。WireGuard では、インターフェースのファイアウォールマークとポリシー規則が転送パケットをトンネルの外に保つので、手で足したデフォルトルートはその仕組みを壊し得ます。二つ目の VPN プロファイルや、デフォルトルートを書き換える管理スクリプトがよくある犯人です。広いバイパス規則を一つずつ足していくのが常套的な結果で、ルーティングの不具合が誰にも維持できない表に変わってしまいます。

ネットワーク変更後にもう一度確認する

Wi-Fi ゲートウェイ経由のホストルートは、マシンが別のネットワークへ移るまで正しいままです。そのとき同じ症状が、設定を何も変えていないのに戻ってきます。

端点のアドレス、接続前後の経路、それぞれが使ったインターフェースを記録します。この三つがあれば、クライアントの不具合と上書きをたいてい切り分けられ、記録した人が去ったあとも残ります。

新しいネットワークで再接続し、同じ読み取りを繰り返します。例外がまた欠けているなら、修正はそれを持つプロファイルの側にあり、障害中に打ち込んだ一度きりのコマンドではありません。