デフォルトルートを編集する前に Linux のポリシールーティングを確認する
ルールはフローを別のテーブルへ送り、主要なデフォルトルートを無意味にすることがあります。Linux の VPN ルートを変える前に、優先度・テーブル・所有者を読んでください。
VPN ホストは一方のインターフェースで応答し、トンネル経由で応答を返そうとしないのに、デフォルトルートは正しく見えます。ここでメインテーブルは全体像ではなくなります。Linux はポリシールールによってパケットごとにルーティングテーブルを選べるため、VPN がどれかを導入している可能性があります。デフォルトルートに触れる前にルールを読んでください。
順序は、まずルール、次に各ルールが選ぶテーブルという順序が重要です。
優先度順にルールを読む
ip rule show を実行し、上から下へ読みます。優先度の数値が評価順を決め、小さい数値ほど先に調べられます。32766 のデフォルトルールが通常は最後に意味を持つルールです。一覧が長い場合は、何かを変える前にファイルへ保存してください。
各ルールについて、優先度、一致条件「送信元・マーク・インターフェース・宛先」、参照するテーブルを記録します。使えるテーブルのないルールは行き止まりであり、ルートではありません。
IPv6 でも ip -6 rule show で同じことをします。IPv4 ファミリーにしかないポリシーは、もう一方のファミリーをメインテーブルのままにします。
各ルールが選ぶテーブルを読む
参照したテーブルごとに ip route show table <name or number> を使います。そのルートを、想定するインターフェースとネクストホップと比べます。空または不完全なテーブルは、メインテーブルでは説明できない障害を説明します。
メインテーブルにデフォルトルートが残っていても問題ありません。ルールがフローを先にテーブル 51820 へ送るなら、そのパケットに主要なデフォルトは関係ありません。
番号に見覚えがなければ /etc/iproute2/rt_tables でテーブル名を調べます。この確認は一瞬で済み、長い回り道を防ぎます。
誰がルールを導入したか調べる
NetworkManager、wg-quick、その他のスクリプトはルールを動的に導入できます。実行中に削除しても、次の再接続で元に戻ることがあります。競合するルールを追加する前に管理側の設定を確認してください。
たとえば wg-quick は、マーク付きのルールとトンネルの許可アドレス用テーブルを追加します。そのルールがあるため、これらのアドレスへの通信は主要なデフォルトを迂回します。設定を変えずに削除すると、次回の起動で復元されます。
確認中は、エンドポイントの外側ルートと管理アクセスを維持してください。出力を簡単にするために、稼働中のリモートゲートウェイですべてのルールを消してはいけません。変更後も残る管理セッションはテストの一部です。
重要な送信元コンテキストを試す
汎用の ip route get はアプリケーションのフローとは別の問いに答えます。送信元アドレスと、VPN が使う場合はマークを加えて、実際のパケットが通る経路を確認します。同じ送信元コンテキストで、含まれる宛先と除外される宛先を試します。ホストがデュアルスタックなら IPv6 でも繰り返します。
承認された修正の後、同じ二つの照会を再実行して比較します。意図したルール、テーブル、再起動後もルールが残る時間を記録します。その記録が、次のサービス再起動を不可解ではなく説明可能にします。ip-rule のマニュアルページ には一致セレクターとテーブルの構文が記載されています。