Windows VPN のルート テーブルに 0.0.0.0/1 と 128.0.0.0/1 が表示される理由

Windows の VPN に接続してルート テーブルを開くと、二つのエントリが目立ちます。0.0.0.0/1 と 128.0.0.0/1 です。これらは入力ミスではなく、既定ルートを置き換えるものでもありません。表示されるかどうかは 一つのプロファイル オプション次第で、このペアはスプリット トンネル機能ではなくフル トンネルを構成する方法です。一行でも変更する前に、オプション、プレフィックス、インターフェイスをまとめて読んでください。

既定ゲートウェイ オプションがインストールするもの

すべてをトンネル経由で送るプロファイル オプションは、この二つのプレフィックスを追加することで機能します。オプションを外すと両方とも消え、トンネル アダプターに渡されたサブネットだけをカバーするルートが残ります。チェック ボックスが制御するのはこのペアであり、単一の既定ルートを書き換えるわけではありません。そのためチェックを外した後のテーブルは、削除ではなく部分的な書き換えに見えます。

0.0.0.0/1 は IPv4 空間の下半分を、128.0.0.0/1 は上半分をカバーするため、合わせてすべてのユニキャスト アドレスをカバーします。どちらも既定の 0.0.0.0/0 より具体的であるため、最長プレフィックス一致により通常のトラフィックはトンネルへ送られ、物理的な既定ルートはその場に残ります。その既定ルートを残すのは見た目の問題ではありません。暗号化されたペイロードを包むパケットはサーバーのパブリック アドレス宛であり、物理アダプターから出ていく必要があります。既定ルートを分割せずに置き換えると、トンネル自身のトランスポートがトンネルに入ろうとし、これは接続ではなくループになります。

したがって、VPN アダプターを指す文字どおりの 0.0.0.0/0 があれば、一度立ち止まる価値があります。ネイティブ クライアントは通常そんなものは書きませんから、手動ルートか別クライアントの構成が知らないうちにテーブルを変えたということです。下流の何かをデバッグする前に、それを見つけてください。

ゲートウェイを保存するより切断処理の方が安い

一つではなく二つのエントリにする実用的な理由は切断処理です。クライアントは接続中はちょうど 二本のルートを所有し、切断時にそれらを削除して、その時点で物理アダプターが持っているものを残します。単一の既定ルートを置き換えたクライアントは、以前のゲートウェイを覚えておく必要があり、DHCP リースが変わった後には存在しないゲートウェイを復元してしまう可能性があります。所有する二つのエントリにはそのような状態がありません。

他のクライアントも同じ設計に至っています。redirect-gateway def1 を指定した OpenVPN プロファイルは、既定ルートを削除する代わりにこの二つのプレフィックスをインストールし、Windows クライアントも同じルーティング上の理由でこのパターンに従います。

分割を期待していたのにテーブルがフル トンネルのように見えるのも同じ理由です。このペアはフル トンネルを構成する方法であり、スプリット トンネルの誤りの証拠ではありません。プロファイルがリモート ゲートウェイを使う設定なら、ローカル アプリケーションが何に到達できようと、すべてがルーティングされます。

最長プレフィックスはどのメトリックよりも先に勝つ

プレフィックスの長さが他のどのフィールドよりも先に検索を決めます。メトリックは同じプレフィックスを持つルート間の同点を破るだけなので、/1 のエントリはメトリックが悪くても /0 の既定ルートに勝ちます。インターフェイス バインディングは、二つのルートが同じプレフィックスを共有し、Windows がどのアダプターでパケットを送るかを選ぶときに残るものを決めます。

route print -4
Get-NetRoute -AddressFamily IPv4 | Sort-Object DestinationPrefix
Find-NetRoute -RemoteIPAddress 10.50.5.20

スプリット トンネルのテーブルには、物理的な既定ルート、二つのハーフ既定ルート、トンネルのサブネット用ルート、追加したオフィス プレフィックスが含まれます。物理的な既定ルートはクライアントとプロファイルによってメトリックが低くも高くもなり、/1 のペアが存在する間はその違いは何も変えません。ペアが取り除かれた瞬間にすべてが変わり、そのときに古いゲートウェイや誤ったインターフェイスが表面化します。変更するつもりの 一行ではなく、テーブル全体を読んでください。

オフィス プレフィックスの所有者を一つに決める

スプリット トンネルでは、VPN を使う必要があるプレフィックスだけを指定し、それを所有する方法を一つ選びます。ルートを割り当てられたトンネル アドレスに向ける方法はそのアドレスが変わるまで機能し、インターフェイスへのバインドはアドレスの変更には耐えますが、プロファイルの再構築後にインデックスが再割り当てされると壊れます。プロファイルにバインドされた cmdlet は両方の問題を避けられますが、プロファイルが必要になります。

route -p add 10.50.0.0 mask 255.255.0.0 172.16.8.1
route -p add 10.50.0.0 mask 255.255.0.0 0.0.0.0 IF 31
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.50.0.0/16

cmdlet はプレフィックスを名前付きプロファイルにバインドするため、ルートは接続とともに現れ、接続とともに消えます。管理されたノート PC が求めているのはこれです。永続ルートは再起動を超えて残り、それを動機づけたプロファイルをも超えて残るので、引退した VPN が何年もエントリを残すことになります。プレフィックスごとに方法を一つ選び、その選択を記録してください。永続ルートとプロファイル ルートが同じプレフィックスに併存すると、切断時に解きほぐすのが面倒な重複が生まれます。どちらを選ぶにせよ、所有権はマシン上だけでなくチケットにも見えるべきです。

この節が答えるのは所有権という問いであり、構文ではありません。 一つのプレフィックスに二人の所有者がいることが避けるべき失敗モードです。

Web サイトではなく宛先で検証する

出口アドレスを報告する Web サイトではなく、トンネルを通過すべき宛先をテストしてください。 Find-NetRoute は選択されたルートと送信元アドレスを返すので、オフィス プレフィックスと物理的な既定ルートのどちらが勝ったかが分かり、そのあと共有そのものを開きます。

Find-NetRoute -RemoteIPAddress 10.50.5.20
Get-VpnConnection -Name Office

出口アドレスのサイトは弱いチェックです。DNS、IPv6、ブラウザーのプロキシがそれぞれ別の経路でその要求を送る可能性があるからです。IPv4 と IPv6 は同じダイアログに別々の設定もあり、片方のボックスを外してももう片方のファミリーはそのままなので、デュアル スタックのマシンは IPv4 が分割ルートをたどる間に IPv6 をトンネル経由で運ぶことがあります。プロファイルを分割と判断する前に両方のファミリーを確認してください。ルートが正しくてもサービスが失敗するなら、残る層はルーティングではなくフィルタリングです。

クライアント管理のファイアウォールは、完璧なルート テーブルがあってもオフィスのサブネットをブロックできます。そのポリシーはプロファイルを配布した人のものであり、ルートを編集する人のものではありません。