Windows VPN が残した古いルートを削除する方法

セッションは数時間前に終わり、アダプターも消えたのに、ルートはまだテーブルに残り、インターフェイス 42 を指しています。その行を削除するのはコマンド一つですが、正しい行だと判断するには四つの確認が必要です。ルート テーブルは共有されるため、広範囲に削除すると他の接続がまだ使っている経路まで消え、トンネルを運ぶ経路も含まれます。以下の各手順は、一致し得るエントリが一つだけになるまで対象を絞り込みます。

1. エントリが古いのか意図的なのかを判断する

再起動を生き延びたエントリはどこかに書き込まれており、その場所はたいてい事故ではなく判断です。スプリット トンネリングは残骸そっくりのルートに依存しており、一つのプレフィックスをトンネル経由で送るポリシーは、一つの一覧では古いエントリと区別できません。ルートがいつ現れたかを尋ねてください；トンネルが上がっている間だけ存在するルートはクライアントの構成に属するため、クリーンアップ コマンドは適切な道具ではありません。意図的なルートを削除すると、次回の接続は誰も見ていない手順で失敗します。

エンドポイントのルートには独自の警告が必要です。クライアントが VPN サーバーへのホスト ルートを追加し、暗号化されたパケットがローカル接続経由で届くようにしている場合、そのルートを削除すると次回の再接続でトンネルが崩れ、症状はサーバーの障害のように読めます。何も触る前に、宛先をクライアントが接続するアドレスと比較してください：VPN サーバーと一致する単一のパブリック アドレスは外側の経路であり、ゴミではありません。

2. エントリを特定する四つのフィールドを記録する

二つのインターフェイスが同じ宛先へのルートを持てるため、プレフィックスだけでは識別子になりません。宛先プレフィックス、インターフェイス インデックス、ネクスト ホップ、ポリシー ストアを、これら四つの値が一つのエントリを正確に表すので記録してください。一つの一覧でそのすべてが得られます：

Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetric

メトリックで並べ替えると、コンピューターが実際に優先するルートが上に来て、残骸はたいていそこに座っています。トンネルが上がっている間と、落ちた後でもう一度エントリを比較してください：アダプターと一緒に消えるルートはクライアントのもので、残るルートは別の何かが書き込んだものです。ポリシー ストアは人が飛ばしがちなフィールドであり、アクティブ ストアから削除したエントリが次回のポリシー更新後に戻ってくるため、再出現を説明するのもこれです。状態を変えるものを実行する前に、四つの値を書き留めてください。

3. 削除をプレビューし、それから一つのエントリを削除する

Remove-NetRoute は Get-NetRoute が出力したのと同じプレフィックスとインターフェイス インデックスを受け付け、プレビュー スイッチもあるので、推測する必要はありません：次の順序でこのペアを実行します。

Remove-NetRoute -DestinationPrefix 10.20.0.0/16 -InterfaceIndex 42 -WhatIf
Remove-NetRoute -DestinationPrefix 10.20.0.0/16 -InterfaceIndex 42

プレビューは削除するオブジェクトを出力するので、スイッチを外す前にプレフィックス、インターフェイス、ネクスト ホップをメモと照合してください。どちらの行も永続エントリには届きません；アクティブ ストアが既定だからです；特定したルートがそこに住んでいる場合は -PolicyStore PersistentStore を追加してください；そうしないと削除は成功したように見え、エントリは次回のポリシー更新で戻ります。セッションがリモートのときは、自分の接続を運ぶルートを削除するとその接続が終わるため、帯域外の復旧経路を確保してください。テーブルを消すコマンドには決して手を伸ばさないでください。

4. 元に戻すコンポーネントを特定する

所有者がまだルートをインストールするよう構成されている間は、削除は修正ではありません。所有者はたいてい、スプリット トンネル一覧を持つ VPN クライアントのプロファイル、ログオン時にルートを追加するスクリプトやスケジュールされたタスク、マシンに適用されたドメイン ポリシーのどれかです。接続のたびに実行されるため、最初にプロファイルを確認してください：

Get-VpnConnection | Select-Object Name,SplitTunneling,ServerAddress
Get-NetRoute -PolicyStore PersistentStore

永続エントリは何も接続せずに見えるので、VPN セッションなしで再起動後に戻ってくるルートは、ほぼ常にそのストアかスタートアップ スクリプトに住んでいます。そこで所有者を直せば、手動削除は治療ではなく検証になります。

5. 参照、隣接、メモを確認する

きれいな結果とは「ルートが消えた」ことではなく、想定したインターフェイスを参照が選ぶようになったということです。影響を受けたプレフィックスへのパケットがどこへ行くかをマシンに尋ねてください：残骸はまだ死んだインデックスを指し、きれいな答えはオンリンクのインターフェイスか正しいゲートウェイを指すからです。Find-NetRoute は一度に一つのアドレスについて答えます：

Find-NetRoute -RemoteIPAddress 10.20.4.7

次に隣接を試します：スプリット トンネルがまだ必要とする二つ目のプレフィックスを選び、ルートを一つ余分に外すのがこのクリーンアップが招く誤りだから、その参照が変わっていないことを確認してください。元々失敗したアプリケーションを再試行し、今どのコンポーネントがプレフィックスを所有しているかを記録します。Microsoft の Get-NetRoute ドキュメントには、手順二で書き留めたフィールドが一覧されています。半年後、そのメモが同じエントリを二度診断することを防ぎます。