VPN接続後にルートメトリックが変わった：それが意味すること
メトリックが小さいことは、同じくらい具体的なルート同士の同点を解消するだけです。VPNルートの数値を編集する前に、ポリシールール、プレフィックス、エンドポイントのホストルートを確認してください。
VPNに接続し、route printを実行すると、デフォルトルートのメトリックが以前よりずっと小さくなっています。自然な結論は、VPNがデフォルトルートを取ったのはその数値が小さいからだ、というものです。実際にそうであることもありますが、多くの場合メトリックは決定要因ではなく、編集しても何も変わりません。選択はもっと前の段階で、プレフィックス長やポリシールールによって行われているからです。
症状は現実で、以前はWi-Fiアダプターから出ていたトラフィックが今はトンネルから出る、あるいはその逆です。メトリックは固定の順序で実行される検索への入力の一つであり、数値に触れる前に読むべきはその順序です。
その数値が実際に競合する相手
最初の比較は優先度ではなく具体性です。10.20.0.0/16のルートは10.0.0.0/8に勝ち、メトリックが何と言おうとどちらも0.0.0.0/0に勝ちます。マシン上で最も低いメトリックのデフォルトルートをインストールするVPNでも、宛先に一致するより具体的なルートには負けます、クライアントが自分のサーバー用にインストールするホストルートも含めて。
だからデフォルトのメトリックを下げても、直接接続されたサブネットをトンネルに入れることはできません。そのサブネットをVPN内に入れたいなら、プレフィックスのルートを追加するか、ポリシールールでトンネルのテーブルを選びます。メトリックはその作業には向かないレバーです。
| Check in this order | Question | Where you read it |
|---|---|---|
| 1. Policy and table | Which routing table does this traffic use? | ip rule, client profile |
| 2. Prefix length | Which matching route is most specific? | route print, ip route |
| 3. Metric | Which of the equally specific routes is preferred? | route print, ip route |
| 4. Interface state | Is the chosen next hop reachable? | adapter status, link state |
Linuxはメトリックより先にテーブルを決める
Linuxではカーネルがまずポリシーデータベースを参照します。ip ruleはルールとそれらが選択するテーブルを一覧し、ip route get 203.0.113.10はカーネルがその宛先に実際に使うテーブル、ルート、送信元アドレスを報告します。テーブル100内のメトリックがメインテーブルのルートと競合することは決してありません、ルールがメトリックを比較する前にテーブルを選んでいるからです。
だからルートはip route show table allで正しく見えても、トラフィックを運ばないことがあります。一致したルールを読み、次にそれが選んだテーブルを読み、その中のルートを比較します。誤ったテーブルが選ばれているなら、もう一方のテーブルでメトリックを編集しても役に立ちません。
Windowsは二つのメトリックを組み合わせる
Windowsにはデフォルトでポリシーデータベースがありませんが、ルートメトリックとインターフェイスメトリックを組み合わせ、自動インターフェイスメトリックはリンク速度やアダプターの状態で変わります。だから同じルートでも、ドッキングステーションや仮想アダプターが現れた後に挙動が変わることがあります。Find-NetRoute -RemoteIPAddress 203.0.113.10は選択された送信元アドレス、次のホップ、インターフェイスを報告し、生のテーブルより実際の判断に近い情報を示します。
ルートとインターフェイスの値を一緒に読みます。インターフェイスメトリックを上げると、ルートエントリを変えずにトラフィックが移動することがあり、自分のルートを所有するVPNクライアントは再接続時にそれらを再インストールし、あなたの編集を破棄します。
トンネルのエンドポイントをトンネルの外に保つ
どのトンネルにも、トンネルを通らない自分のサーバーへの経路が必要です。クライアントは物理ゲートウェイ経由でエンドポイントのホストルートをインストールし、そのルートはクライアントが追加するデフォルトより具体的であり続けなければなりません。それを削除したり、そのアドレスの検索でトンネルを勝たせたりすると、カプセル化されたパケットは本来構築すべきトンネルに入ろうとします。接続は失敗するかループします。
メトリックを変更する前と後に、そのホストルートを確認してください：物理的な次のホップを指し、再接続後も残っている必要があります。クライアントが所有している場合は、上書きされる実行時の値ではなくプロファイルや管理構成を変更します。
両方のアドレスファミリーとアプリのコンテキストを確認する
IPv4とIPv6は別々のテーブルを持つ別々の判断です。VPNがIPv4を運びながら、IPv6がローカルルーターを使い続けることがあり、一方のファミリーでのメトリック変更は他方について何も語りません。両方を確認し、次にアプリケーションのコンテキストを確認します。インターフェイスに束縛されたプロセス、コンテナの名前空間、アプリごとのVPNは、シェルとは別のテーブルを見ることがあります。
実際の宛先に対する判断を報告するツールで検証し、テーブルの全一覧で判断しないでください。選ばれたルートが設計の意図どおりなら、そこで止めます。画面で最小の数値でないメトリックは欠陥ではなく、無理に最小にするとトンネルが依存するエンドポイントの経路が壊れることがあります。