Wi-Fiの切り替えやEthernet接続でVPNが切れる理由

二つの事象（ノートPCが別のWi-Fiネットワークへ移った場合と、Wi-Fiが上がったままケーブルが差し込まれた場合）が一つの障害として報告されます。クライアントは接続中と言い続け、アイコンは正常に見え、トンネルは何も運びません。内部で動き得るのはリンク、ローカルアドレス、デフォルト経路という三つの状態だけで、どれが動いたかが、トンネルが自力で回復するのか再接続が要るのかを決めます。私は、アカウント設定の変更で直ったことが一度もないこの順に、それらを確認します。

リンク、アドレス、経路は独立して動く

同じネットワーク内のアクセスポイント間のローミングは、通常はL2のイベントです。無線が再関連付けし、インターフェースはアドレスとゲートウェイを保ち、トンネルが依存するものは何も変わらないため、大きなオフィスを歩き回っても気づかないことがあります。別のSSIDへの参加はそれとは違い、古いインターフェースが落ち、DHCPが新しいアドレス、新しいゲートウェイ、新しいリゾルバを配り、トンネルが使っていた外側のフローは存在しなくなります。

Ethernetは三つ目の形を加えます。Wi-Fiは決して落ちないのでリンクイベントはまったく発生しませんが、有線インターフェースが独自のアドレスで現れ、多くの場合メトリックでデフォルト経路を奪います。トンネルはもはや優先されない経路を走り続けるか、クライアントがソケットを開始時の無線ネットワークに固定したままにします。ブラウザから見るとどちらも同じで、ケーブルがカチッと入った瞬間にページが止まります。

つまり最初の問いはWi-Fiが変わったかどうかではありません。トンネルが上がっている間に、束縛されているアドレス、または端点への経路が変わったかどうかです。

外側のソケットは、たった今消えたアドレスに固定されている

すべてのトンネルは外側のフローで、ローカルのアドレスとポートがサーバーのアドレスとポートと話します。Linuxでは古い送信元に束縛されたUDPソケットであり、アドレスを持つインターフェースが削除されると、送信はEADDRNOTAVAILで失敗するか、サーバーが見たことのない送信元で新しいインターフェースから出ていきます。

遠い側も独自のピン留めを保ちます。MOBIKEのないIKEv2 SAはアドレスの組で識別され、OpenVPNセッションは学習したピアアドレスに結び付き、NATマッピングはそれを作ったプライベートアドレス、ポート、パブリックアドレスに属します。別のNATの背後に移れば、すべての応答はもう存在しないマッピングへ送られます。あなたのマシンの設定は何も間違っておらず、五つ組が去ったネットワークを指しているだけです。

理論を立てる前に、状態を読みます

• ss -unp は各トンネルソケットが実際に保持しているローカルアドレスとポートを表示します。
• ip route get 203.0.113.10 はカーネルが今端点に対して使う送信元アドレスとデバイスを出力します。
• wg show wg0 endpoints、swanctl --list-sas またはクライアントログは、遠い側が話していると信じているピアアドレスを表示します。

ソケットのアドレスと経路検索が食い違えば断絶を見つけたことになり、資格情報の変更ではそれに触れられません。

新しい送信元アドレスに対して各プロトコルがすること

クライアントは変化を程度の差こそあれ吸収し、私が再接続の挙動から推測せずにクライアント設定と突き合わせるのはこの表です。

WireGuardのローミング規則は一方向にしか働きません。クライアントが先に新しいアドレスから送る必要があり、古いインターフェースに束縛されたままのソケットは決してそれを行わないため、トンネルが生きているように見えてもハンドシェイクのタイマーは古びていきます。プロトコルの説明 は端点更新の条件を正確に述べており、設定を変える前に読む価値があります。

MOBIKEは交渉されるもので、仮定されるものではありません。サーバーが提供しなければクライアントは再確立しなければならず、これはSA一覧やログから確認する事実であって、回るインジケーターから推測するものではありません。

経路を決めるのはルートの優先度であり、Wi-Fiのアイコンではない

両方のインターフェースが上がっていると、カーネルはメトリックとプレフィックス長で選びます。ip route show default は候補を列挙し、ip route get 203.0.113.10 は送信元アドレスを含む実際の決定を解決します。メトリック100の有線デフォルトと600の無線デフォルトは、ケーブルが収まった瞬間に端点が動くことを意味し、一方で先にソケットを開いたアプリは古い送信元を保ちます。

Windowsも、リンク速度に偏る自動インターフェースメトリックで同じことをします。Get-NetRoute -DestinationPrefix 0.0.0.0/0 は候補を並べ替え、Find-NetRoute -RemoteIPAddress 203.0.113.10 はスタックが選ぶインターフェースと送信元を返します。外側のソケットを一つのインターフェースに束縛したクライアントは、メトリックが反転した後もそれを使い続けますが、これは束縛の判断でありルーティングの不具合ではありません。

Androidでは分割が見える形になり、ConnectivityManagerは利用可能なネットワークと別個のデフォルトを報告し、ソケットをNetworkオブジェクトに束縛するVPNアプリは再束縛するまでその束縛を保ちます。macOSではscutil --nwi がプライマリインターフェースとシステムが使う順序を出力します。

DNS、MTU、IPv6は接続とともに動く

新しい接続は新しいリゾルバをもたらします。systemd-resolvedではDNSはリンクごとで、resolvectl status はどのリンクが名前を解決するかを示し、独自のリゾルバを配るゲストネットワークでは、リンクが再び優先されるまでトンネルが押し込んだDNSが使われないままになることがあります。キャプティブポータルはさらに悪化させ、最初のHTTPSリクエストには端点ではなくポータルが答え、クライアントは死んだサーバーを記録します。

経路のMTUも変わります。EthernetとWi-Fiは通常1500バイト、PPPoEは1492、モバイル回線はしばしばそれ未満です。小さいMTUを受け継いだトンネルは大きなパケットで止まり、小さなリクエストは通るため、これは半分壊れた接続として読まれます。ping -M do -s 1472 203.0.113.10 はDFを立てた1500バイトのパケットを送るので、沈黙は経路が想定より小さいことを意味します。

IPv6はもう半分です。新しいプレフィックスを配るネットワークはデュアルスタックのクライアントが使う送信元を変え、v4のみのトンネルはポリシーが追いつくまでv6のトラフィックを外に置きます。ip -6 route show default とip -6 addr show は、新しいリンクにv6の経路があるかどうかを答えます。

説明するのではなく、遷移を再現する

無害なリクエストを一つ選び、変化の両側で同じ三つのコマンドを実行します：ip -br addr、ip route show default、ip route get 203.0.113.10。次に、トンネルがまだパケットを出しているかどうかは次の出力で分かります - tcpdump -ni any udp port 51820 WireGuardならこれ、それ以外なら対応するポートです。古い送信元から出ていくパケットは束縛の問題を意味します。新しい送信元から出て応答がないパケットは、遠い側か途中のNATを意味します。

最初の障害と同時に起きた事象を書き留める リンクダウン、アドレス変更、デフォルト経路の変更という三つです。これらは別の担当者を指し、再束縛すべきクライアント、再取得すべきアドレス、あるいは恒久的なバイパス規則ではなく設定ファイルに属する経路です。

修正済みと呼ぶ前に、直接トラフィックのブロックが隙間の間も保たれていること、名前が新しい接続で解決されることを確認してください。切り替え後もクライアントが古い端点を持ち続けるなら、まずローミングかfloatの設定を直します。正しくローミングしても応答がないなら、次の人が比較できるよう、サーバーのピア識別情報と経路上のNATを見て、両方のネットワーク文脈を記録に残してください。