OpenVPN のルートメトリック：選んだルートがそれでも負ける理由

プロファイルのルートにメトリックを追加し、再接続しても、トラフィックは依然として間違ったインターフェースから出ています。問題が数値であることはほとんどありません。メトリックは、オペレーティングシステムがすでに比較している候補を順序付けるだけであり、より具体的なプレフィックスや、より早いポリシーテーブルが、どのメトリックも読まれる前に決定を下します。

まずプロファイルを、次にインストールされたテーブルを、そして選択ルールを順に確認してください。この順序はクライアントがルートを構築する方法と一致し、比較に決して入らない値を調整してしまうのを防ぎます。

ルート行をフィールドの順に読む

OpenVPN 2.6 のコミュニティクライアントは、IPv4 の route 行で 四つのフィールドを受け付けます。ネットワーク、ネットマスク、ゲートウェイ、そして省略可能なメトリックです。ゲートウェイの位置は、特別なキーワード vpn_gateway が入る場所です。これはこの接続の VPN 側のネクストホップを意味し、ルーティングテーブルの番号でも、物理ルーターでもありません。これを見落とすと、行の残りはその動作について誤った理解で読まれてしまいます。 ネットワークオプションのリファレンス には 四つのフィールドすべてが記載されています。

プライベートな宛先の場合、行は次のようになります：

route-metric 50
route 172.20.0.0 255.255.0.0 vpn_gateway 30

明示された 30 はそのルートに適用され、50 は数値を省略したプロファイル内の他のすべてのルートの既定値として残ります。行を左から右へ読むだけで、どの値がどこに適用されるかを判断できます。

route-metric は既定値であり、順位ではない

route-metric は、独自の数値を持たないルートのフォールバックを設定します。これはルートを何かの上に押し上げるものではなく、明示的なメトリックでインストールされたルートを並べ替えるものでもありません。

この区別は、プロファイルが両方の形式を混ぜているときに重要になります。上部近くの 一行の route-metric は権威があるように見えて非難しやすい一方、実際にトラフィックを運ぶルートは 三行下で独自のメトリックを持っているかもしれません。

一つのルートに経路を優先させたい場合は、そのルートに数値を置きます。生成されたプロファイル全体で一貫した既定値が必要なら、route-metric を使って個々の行はそのままにします。理由もなく両者を混ぜることが、誰にも説明できないルートをプロファイルに残す原因です。

クライアントが何をインストールしたかを調べる

再接続が完了したら、プロファイルではなくカーネルに問い合わせます。

ip route show はクライアントが追加したルートを一覧表示し、ip route get 172.20.5.10 はより有用な問いに答えます。この宛先が実際にどのルートを使い、どの送信元アドレスで使うかです。宛先がテーブルにない場合、クライアントはそれをインストールしていません。

ローカルのディレクティブ、サーバープッシュ、または別のネットワークマネージャー が同じプレフィックスを追加または削除でき、最後に書き込んだ者が勝ちます。作業中はエンドポイントのルートを見ておいてください。接続には、これから構築するトンネルを通らないリモートサーバーへの経路が必要だからです。

小さいメトリックがそれでも負ける理由

メトリックは同じ宛先へのルートを比較します。広いプレフィックスをより具体的にするものではありません。redirect-gateway def1 が有効な場合、クライアントは 0.0.0.0/1 と 128.0.0.0/1 をインストールし、この 二つのプレフィックスは 0.0.0.0/0 よりも具体的に IPv4 空間全体を覆います。既定ルートのメトリック 1 では、それらを上回りません。

同じ論理は重なり合う任意のペアに当てはまります。/24 はその内側のアドレスについて /16 に勝ちます。付随する数値に関係なく、検索は最初に最も具体的な一致を選び、その後でのみ同等のもの同士でメトリックを比較するからです。

これがメトリックの不具合に見えてそうではない部分です。数値を変える前に、両方の候補でプレフィックス長を確認してください。

ポリシールールはテーブルより先に実行される

Linux では、ip rule がどのルーティングテーブルを参照するかを決めます。ルールは優先度順に評価されるため、以前のテーブルがメインテーブルを読む前にルートを返すことがあります。main 内のメトリックは、先に参照されたテーブルの一致を上回ることはできません。

ip rule show を使い、次にそのルールが何を返すかを確認するために特定のテーブル（たとえば ip route show table 100）へ問い合わせます。VPN クライアントやコンテナランタイムがルールを追加した場合、答えは読んでいたテーブルではなくそこにあるかもしれません。送信元アドレスも重要です。ルールは送信元に一致し、同じ宛先をトンネルのトラフィックと LAN のトラフィックで別々に解決できるからです。

順位ではなく宛先を検証する

議論を終わらせるテストは、目的のサブネット内のホストへの 一回の問い合わせと、カーネルが選んだ送信元アドレスの確認です。その組み合わせが設計と一致していれば、一覧がきれいな順位に見えなくても、メトリックは役割を果たしています。

IPv6 と DNS はこの確認から外してください。これらは別のディレクティブで設定され、別の仕組みで解決されます。動作している IPv4 ルートは、どちらについても何も語りません。一度に 一つの層だけを変更し、問い合わせをやり直してください。