削除した VPN ルートが再接続後に戻ってくる理由

手で削除したルートが次の再接続後に戻り、テーブルは以前とまったく同じに見えます。これはルーティングの不具合ではなく、構成または接続ライフサイクルの操作から何かがエントリを再作成しています。ほとんどのランブックは有効なテーブルで止まるため、削除が一分間は機能したように見えてから失敗します。所有者を特定し、そこを変更し、再接続で証明してください。

ルートをインストールしたのは誰か

修正ではなく、候補の一覧から始めてください。VPN プロファイルが独自のルートを持てる場合もあれば、サーバーが接続時に push する場合、ネットワークマネージャーのプロファイルが宣言する場合、起動ユニットやスクリプトが追加する場合、IPsec 実装がネゴシエートしたトラフィックセレクタ用のルートをインストールする場合があります。ポリシールーティングのルールがトラフィックをまったく別のテーブルへリダイレクトすることもあります。

タイミングは構成の考古学よりも速くそれらを切り分けます。インターフェースが上がった瞬間に現れるエントリはクライアントのもの、一秒後に現れるものは通常サーバーの push によるもの、起動時に存在するものは保存された構成のものです。接続、切断、再起動の前後でテーブルを記録すれば、パターンが所有者を示します。サービスの再起動時にだけ戻るルートは、VPN ではなくユニットを指しています。

編集する前にテーブルを読む

保存されたファイルではなく、カーネル自身の見え方を見てください。プロトコル列は各エントリを何がインストールしたかを示します：

ip route show
ip route show table all
ip rule show

プロトコルフィールド、メトリック、テーブル番号を見れば、静的エントリ、カーネルが作成したエントリ、デーモンが追加したもののどれを見ているか分かります。ルール一覧が重要なのは、検索がメインテーブルを完全に離れることがあり、その場合そこでの変更がトラブルシューティング中のアプリから見えなくなるからです。行は左から右へ、宛先、ゲートウェイ、デバイス、プロトコル、メトリックの順に読んでください。

次に、実際にどのルートを使うかをカーネルに尋ねてください。保護されたアドレスは、公開アドレスより優れた探針です：

ip route get 10.20.5.7

症状ではなく所有者を変える

所有者が分かれば、変更はその所有者のものに入れます。クライアントプロファイルからルートを削除し、サーバー側の push ルートを修正するか、メトリックで勝つ競合する永続ルートを追加する代わりにネットワークマネージャーの接続を編集してください。互いに戦う二つのルールは、後から誰にも説明できないテーブルを生みます。

エンドポイントの除外は残してください。VPN サーバー自身の公開アドレスを物理ゲートウェイ経由で送るホストルートが、外側のトンネルパケットを流し続けますが、それを削除すると、トンネルは自分自身を運ぼうとします。スプリットトンネルのプロファイルでは、トンネルを迂回させるローカルサブネットにも同じ注意が必要です。

再接続して両方の経路を検証する

再接続してから、両方の宛先を一度に確認してください。保護されたアドレスと除外されたエンドポイントは別の問いに答えます：

ip route get 10.20.5.7
ip route get 198.51.100.20

前者はトンネルインターフェース経由で、後者は物理ゲートウェイ経由で解決されるはずです。両方がトンネル経由で解決されるなら除外が欠けており、どちらもそうならないならプロファイルの変更が効いておらず、思っていたのとは別の所有者を見ています。

ルートの目的、所有者、どれくらいの期間生きるべきかを書き留めてください。そのメモが、次の人が同じ削除と再接続のサイクルを繰り返すのを防ぎます。