Windows で VPN がローカル LAN を遮断する：ルートかクライアントポリシーか

仕事用 VPN が接続した瞬間、自分のデスクのプリンター、NAS、開発機が応答しなくなる。ルートコマンド一つで数秒で直ることもあれば、同じルートが正しいのにパケットが消え続けることもあり、それは似た症状の別の問題を見ているということだ。判断は三つの問いに絞られ、これを間違った順で確認するから、人は一晩かけてルートを削除しては追加し直すことになる。

コマンドを打つ前の三つの問い

第一に、ローカルプレフィックスのエントリはあり、それは物理アダプターを指しているか？ 第二に、接続時にクライアントはゲートウェイからローカルネットワークの許可または拒否を受け取るか？ 第三に、必要なのは LAN へのアウトバウンドアクセスだけか、それともインターネット上の何かが自分のマシンで動くサービスにも到達する必要があるか？

最初の問いは、ルーティングの障害とフィルタリングの障害を分ける。二つ目は、ルートの修正がそもそも許されるかを教える。三つ目は修理の内容を変える：ルートはアウトバウンドの通信を直すが、到達できないインバウンドサービスは通常リスナーのバインドと戻り経路の問題であり、ルートはそれを悪化させる。

問い一：ルートかフィルターか名前か

何かを追加する前にテーブルを読む。インターフェイスインデックスが重要で、以下のルートコマンドはすべてそこに固定されている：

route print -4
Get-NetRoute -DestinationPrefix 192.168.1.0/24 | Format-Table InterfaceIndex,NextHop,RouteMetric

直接接続されたサブネットは、トンネルが上がっていても通常はオンリンクルートを保持するため、エントリが存在しても通信は失敗しうる。その組み合わせはルーティングの後に動くフィルターの署名であり、より具体的な二本目のルートがまったく何も変えないケースだ。

アドレスと名前で別々に試す。ping 192.168.1.50 が応答し net view 192.168.1.50 が応答しないなら、ルーティングテーブルは最初から問題ではなかった：トンネルがリゾルバーを変え、ローカル名がもう解決されないのだ。そのためにルートを足すのは無駄な作業だ。

問い二：ゲートウェイはローカル LAN へのアクセスを許可するか？

商用クライアントはルート以上のものをインストールする。接続時にポリシーを受け取り、そのポリシーにローカルネットワークの明示的な許可が含まれることがある。Cisco IPsec の配備ではグループポリシーがスプリットトンネリングの設定と、ローカル LAN アクセス用の独立したフラグを運ぶ；クライアントのチェックボックスはゲートウェイが拒否できる要求だ。AnyConnect ではプロファイルがスプリットの包含リストと除外リスト、そして同じ許可を制御する。Windows RRAS では、同等なのはプロファイルのデフォルトゲートウェイオプションと、サーバーが割り当てる静的ルートだ。

フラグが無効なとき、文書化された動作は、有効でより具体的なルートが存在してもクライアントが直接接続されたサブネットへの通信を遮断するというものだ。クライアントが所有しないルートが追加から数秒で消えるのも同じ理由で、クライアントは指示された状態を再構築しているのであって、あなたと争っているわけではない。

クライアントのログは接続時の判断を記録しており、それを読むほうがマシン上でのどんな実験より速い。ログがローカルアクセスは遮断されていると言うなら、そこで止めるべきだ：コマンドラインの修正では太刀打ちできず、残る道はポリシーの変更、トンネル経由でのリソースへの到達、クライアントを仮想マシンに閉じ込めてホストをローカルネットワークに残すことだけだ。

問い三：必要なのはどちらの方向か？

近くのデバイスへのアウトバウンド通信はルーティングの問題だ。LAN プレフィックスをローカルゲートウェイに向け、トンネルのデフォルトルートを上回るだけ低いメトリックを付ける：

route add 192.168.1.0 mask 255.255.255.0 192.168.1.1 metric 1 if 12
route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 -p

二つ目の形式は一つのデバイスを固定する。アドレス一つが要件のすべてなら、これが望みどおりで、netsh の同等なものは同じ判断をインデックスではなくインターフェイス名で記録する：

netsh interface ipv4 add route prefix=192.168.1.0/24 interface=12 nexthop=192.168.1.1 store=persistent

アドレスとマスクが一致しないと、ルートコマンドは パラメーターが正しくありません で失敗する（たとえば /24 マスクのホストアドレスの場合）。サブネットルートにはネットワークアドレスを、単一ホストにはホストマスクを使う。

インバウンドは別だ。同じマシンの VNC や SSH サーバーは、インバウンド接続への応答が VPN ゲートウェイから出て戻ってこないと到達不能になる。ルートに触る前に、サービスが何を待ち受けているかを確認する：

netstat -ano | findstr :5900

特定の一つのアドレスにバインドされたリスナーは、もう一方のインターフェイスでは応答しない。すべてのインターフェイスにバインドするのは意図的な判断で、信頼するネットワークに限定したファイアウォール規則と一緒に行う。その後になって初めて、ルートの修理が戻り経路を回復する。

合う最小の変更を適用する

もう一つのよくある手は、IPv4 の詳細設定で 「リモートネットワークでデフォルトゲートウェイを使用する」 のチェックを外すことだ。これでインターネット通信はローカルに保たれるが、同時に二つのことが起きる：VPN がデフォルト経路でなくなり、クライアントはリモートネットワーク向けのルートを multicast も含めて受け取らなくなる。外すと、サーバーが各クライアントに必要な特定のリモートプレフィックスを送らない限り、リモート LAN は消える。

この非対称性が作業の順序を決める。リモート側を完全に到達可能に保つ必要があるなら、サーバーからリモートサブネットを送り、ローカルのデフォルトには手を触れない。サーバーを変えられないなら、トンネルが割り当てたアドレス経由でリモートプレフィックスに永続ルートを追加し、route print でプレフィックスが VPN インターフェイスを指し、デフォルトが依然として物理ゲートウェイを指していることを確認する。

次に、修理が再接続後も残ることを確認する（非永続ルートはアダプターとともに消え、接続のたびに走るスクリプトがそれを置く正直な場所だからだ）。同じセッションでローカルデバイス一つとリモートリソース一つを試し、切断して再接続し、もう一度試す。ルートが正しく見えるのにローカルデバイスがまだ失敗するなら、問い二に戻る：クライアントがフィルタリングしており、答えは二本目の競合ルートではなくポリシーの変更だ。