VPN のルートキャッシュが変更を隠していませんか？三つの点を確認する

変更が反映されないとき、最初に思いつくのはルートキャッシュの消去ですが、現代の Linux では無駄な作業です：グローバルな IPv4 ルートキャッシュは何年も前に削除されたので、ip route show cache は何も出力せず、消すものもありません。あなたを欺く状態は一つ上の層にあります：ソケット、NAT マッピング、リゾルバ、または古いプロファイルを再適用したネットワークマネージャです。三つの問いがこれらのケースを分けます：誤った経路は新しいフローから来ているのか古い接続から来ているのか、プラットフォームがそもそもルートをキャッシュするのか、状態はルーティングにあるのかその上にあるのか。インターフェースをリセットする前にそれらに答えてください。

確認一：古い経路は新しいフローから来ているか？

確立済みの接続は、作成時のルートを保持します。そのためトンネル経由の SSH セッションはルーティングテーブルの変更を生き延び、新しいセッションはすぐに新しい経路を取りますが、「変更しても何も起きない」が多くの場合「古いソケットがまだ保持している」を意味するのも同じ理由です。既に開いているウィンドウではなく、新しいプロセスで試してください。

ss -tnp | head
ip route get 1.1.1.1
curl -m 5 -sS -o /dev/null -w '%{remote_ip}
' https://example.com

最後のコマンドは新しい接続が実際に到達したアドレスを出力し、これはステータス画面を信頼せずに実際の経路を見る最も安価な方法です。それを、名前空間やインターフェースが使うはずだった送信元アドレスと比較してください。

新しいフローが正しい経路を取り、古いフローが回復しないなら、ルーティングを見るのはやめてください。経路は正しく、セッションが古かったのです。

確認二：プラットフォームはそもそもルートキャッシュを持つか？

Linux では、ほとんどのガイドが意味する意味では答えはノーです。破棄すべきグローバルな宛先キャッシュはなく、選択したルートを保持するソケット単位のエントリはソケットと共に解放されます。ip-route のマニュアルのキャッシュの節は歴史的な挙動を説明しているのであって、現在のカーネルで消去できるものではありません。

他のプラットフォームは異なり、助言のコピーが失敗するのはまさにここです。Windows は宛先キャッシュを保持し、netsh interface ip delete destinationcache で消去できます。BSD と macOS は route -n get で宛先ごとの検索を公開し、それぞれのキャッシュは独自のスケジュールで期限切れになります。そのどれかで動くコマンドは Linux では何もしないため、同じ修正が試す人の半分で失敗するように見えるのです。

NAT や conntrack のテーブルはルートキャッシュではありませんが、同じ症状を生みます。変更前に変換されたフローはその変換を保持し、conntrack -L はルーティングポリシーが先に進んだ後もずっとそれを表示します。それは古い状態ですが、ルートを消してもそれには触れません。

確認三：状態はルーティングにあるのか、その上にあるのか？

他の何かを読む前に、宛先に対して ip route get、次に from と送信元アドレスを付けた同じコマンド、次に ip rule show という現在の検索を読んでください。この三つが意図と一致するなら、ルーティングは直す層ではなく、古い観測は別の場所から来ています。

よくある三つの容疑者がルーティングの上に座っています。ネットワークマネージャが削除の数秒後に保存済みプロファイルからルートを再インストールして変更が戻ったように見える場合は、テーブルを再編集する前に nmcli connection show --active とユニットの状態を確認してください。リゾルバのキャッシュは古いアドレスを返すため、キャッシュを迂回するツールで同じ名前を問い合わせるまで、ルーティング障害のように見えます。アプリケーションの接続プールは古い宛先への動作中のソケットを保持し、カーネルに新しい判断を求めることはありません。

三つの答えから何を結論できるか

答えを合わせると、修理方法はたいてい自ずと述べられます。ルートキャッシュのないプラットフォームで新しいフローが誤った経路を取るなら、ポリシーが本当に誤っていますので、トンネルがインストールしたルールとテーブルを読んでください。古いセッションが止まる一方で新しいフローが正しい経路を取るなら、問題はアプリケーションかソケットです。どちらの場合も経路が正しく観測が壊れているなら、状態はルーティングの上にあります。

一般的なリフレッシュに抗ってください。ネットワークスタックを再起動したり、デフォルトルートがトンネルであるマシンですべてのルートを削除したりすると、修正に使っている接続そのものを切ってしまい、どの層が失敗したかを教えてくれた証拠も壊します。

どうしても何かを消す必要があるなら、一つのプロセスのソケット、一つの conntrack エントリ、リゾルバのキャッシュという、診断に合う最小のものだけを消してください。その後、同じ新しいフローのテストを繰り返し、何が変わったかを書き留めてください。

メモでは三つの状態を分けておく

保存された設定、現在の検索、観測されたフローは三つの異なる事実ですので、それらを「キャッシュ」にまとめてしまうことが、障害を再現しにくくします。ルートを所有するプロファイルやユニット、ip route get の出力、実際の接続の送信元と宛先を書き留めてください。

Windows の宛先キャッシュを消す修正は Linux ホストに当てはまる修正ではなく、両者の間でコピーされた手順は誤った教訓を教えるため、その横にプラットフォームとクライアントのバージョンを記録してください。問題を他の人に渡すとき、その三行があれば推測ではなく失敗状態を再現できます。