Windows の分割トンネル：ゲートウェイのチェックと欠けたプレフィックス

トンネルは接続済みと報告し、Wiki はまだ読み込める。それからダウンロードが止まり、棚の共有が応答しなくなる。トンネルは仕事を果たし、プロファイルはあらゆる宛先を主張しただけだった。

Windows は VPN 接続を経路の判断として扱う。その判断が狭められるまで、マシンはオフィスへ引っ越したかのように振る舞う。

なぜ動いているトンネルが障害のように感じられるのか

リモートゲートウェイの使用を許可されたプロファイルは、トンネル経由の既定ルートをインストールする。するとローカルリンク上にない宛先はすべて、オフィスのファイアウォールから出ていく。ローカルの共有は応答しなくなり、その通信は今や別の大陸まで往復して戻ってくる。クライアントの状態にはそれが何も現れない。

症状はわざと紛らわしい。名前解決はまだ動くのに共有がタイムアウトする、あるいはその逆もある。利用者は VPN が壊れたと言い、クライアントは自分は正常だと言い、どちらの発言も正確である。

IPv4 ダイアログに隠れたチェックボックス

設定はいくつものダイアログの奥にある。ncpa.cpl を開き、接続を右クリックし、IPv4 のプロパティ、詳細設定と進み、接続をリモートの既定ゲートウェイにするオプションを外す。このひとつのチェックが、そのプロファイルを全トンネルにするかどうかを決める。プロファイルの他の設定はすべて有効なままだ。

route print -4 の出力を再接続の前後で比べる。以前トンネルを指していた 0.0.0.0 の項目は消え、社内プレフィックスは残っているはずだ。

route print -4 | findstr /c:"0.0.0.0"
Get-VpnConnection -Name 'Work VPN' | Select-Object Name, SplitTunneling, Routes

インターフェイスのメトリックを変えても代わりにはならない。メトリックは競合するふたつの既定ルートのどちらかを選ぶだけで、接続のたびに自分の既定ルートを入れ直すクライアントは、どんな数値を設定してもその競争に勝つ。

誰も一覧に載せなかったプレフィックス

分割トンネルは プロファイルに記録されたプレフィックスだけ を公開する。プロファイルを書いた後に追加されたオフィスのサブネットは、トンネルがまったく健全でも到達できないままになる。報告は壊れた VPN ではなく、壊れたサーバーとして届く。

手で足したルートは、ゲートウェイのアドレスが変わるまで隙間を埋める。プレフィックスを接続に記録するほうが堅牢であり、推測したアドレスではなく接続に従う。

route -p add 172.20.8.0 mask 255.255.255.0 10.8.0.1
Add-VpnConnectionRoute -ConnectionName 'Work VPN' -DestinationPrefix 172.20.8.0/24
Get-VpnConnection -Name 'Work VPN' | Select-Object -ExpandProperty Routes

保存された一覧と実際のテーブルを一緒に読む。保存されたプレフィックスがあっても、接続が上がった後に管理エージェントが経路を絞り込むと、テーブルには決して届かないことがある。逆に、レジストリの経路が停止中のアダプターを指している場合もある。どちらか一方の見方だけでは全体像は語れない。

再起動後に結果を証明する

両方向にトレースし、名前で解決する。公開側のトレースは ISP から出るはずで、内部のトレースはトンネルに入るはずで、内部のホストはアドレスだけでなく名前でも応答するはずだ。

tracert -4 www.example.com
tracert -4 wiki.corp.example
ping -4 fileserver.corp.example
ping -4 172.20.8.20

切断、再接続、再起動を一度ずつ行った後に繰り返す。手動の再接続を生き延びて再起動で消えるプレフィックスは、プロファイルに保存されていなかった。

プリンターと NAS も試験に残す。ノート PC の隣の機器を切り捨てる分割トンネルは、より小さくて厄介な問題を作ることでひとつを解決したのだから、パラメーターの綴りをモジュールの版と照らし合わせる場所は、Microsoft の Add-VpnConnectionRoute のリファレンス だ。