Windows の VPN が PowerShell で実際に何をルーティングしているかを確認する方法

VPN のタイルが接続済みでもカバレッジの証明にはなりません。保存済みプロファイルのフラグ、現在のルート テーブル、NRPT の規則をこの順で確認してください。

Windows 11 のノート PC で VPN クライアントを接続すると、タイルは「接続済み」になり、社内ファイル共有は開き、公開サイトはオフィスの Wi-Fi から直接読み込まれていました。この混在は壊れたトンネルのように見えます。しかしこれは、一部のトラフィックを VPN に通し、残りを物理アダプターに残すプロファイルの正常な出力です。強制トンネリングは Windows が優先する既定ルートを変えるだけで、より具体的なルートを削除せず、接続が切れたときにトラフィックが止まることも保証しません。以下は、クライアントがカバレッジを主張したときに私がたどる順序です：クライアントの状態、保存済みプロファイル、適用されたルート、リゾルバー、そして実際のフローです。

クライアントから始め、そこで信頼をやめる

クライアントが最初に見るべき場所なのは、どのプロファイルが有効かを教えてくれるからにすぎません。接続のプロパティを開き、正確なプロファイル名、それが現在のユーザー向けかマシン上の全員向けか、接続後に ncpa.cpl に現れるアダプターを記録します。私の検証用ノート PC ではアダプターがプロファイル名を名乗っていたため、ルートの出力は読みやすくなりました。他のマシンでは WAN Miniport のエントリとして表示され、名前からは何も分かりません。

クライアントが教えてくれないのはカバレッジです。接続済みのタイルが示すのはトンネルの状態であり、宛先の一覧ではありません。サードパーティのクライアントも独自の構成を保持しているため、ネイティブの Windows プロファイルとそこから読むすべてのプロパティは、そのクライアントがインストールしたものと無関係かもしれません。VPN が AnyConnect、OpenVPN GUI、WireGuard、ベンダーのエージェント経由で導入された場合、以下の PowerShell チェックはほとんど当てはまらず、代わりにそのクライアント自身のスプリット トンネルとルーティングの設定を読むべきです。

保存済みプロファイルを読み、タイルは読まない

ネイティブの Windows プロファイル (IKEv2、L2TP、SSTP、または MDM が配布するもの) では、保存されたスプリット トンネルの判断は一つのプロパティです。

Get-VpnConnection -Name 'Office' | Select-Object Name, ServerAddress, SplitTunneling, DnsSuffix

プロファイルがデバイス上の全員向けに作成された場合は -AllUserConnection を付けます。これがないと現在のユーザーの一覧を読むことになり、空だったり、似た名前の別のエントリが入っていたりします。False という値が SplitTunneling にある場合、プロファイルがフル トンネルとして保存されたことを意味します：Windows は VPN アダプター経由の既定ルートをインストールします。True はスプリット トンネルを意味し、カバレッジはそのプロファイルが配布するルートと名前解決の規則だけに依存します。

その値は構成として扱い、観測として扱わないでください。接続時点でプロファイルが要求した内容を記録しているだけです。Windows は、別のインターフェイスのより具体的なルート、ポリシー設定、以前の接続の残骸によって、異なる適用ルートになることがあるため、このブール値だけで疑問は解決しません。

保存された値を適用済みのルート テーブルと比較する

接続後は、テーブル全体をスクロールするのではなく、トンネル アダプターのルートを一覧します。

$vpn = Get-NetAdapter | Where-Object InterfaceDescription -match 'VPN|WAN Miniport'
Get-NetRoute -InterfaceIndex $vpn.ifIndex | Sort-Object DestinationPrefix
Find-NetRoute -RemoteIPAddress 10.20.4.15 | Select-Object -First 1

Find-NetRoute が有用な半分です。クライアントが決して答えない問いに答えます：この宛先について、Windows は実際にどのインターフェイスとどの送信元アドレスを使うのか。社内ホスト、公開ホスト、意図的な例外と考えるものに対して実行します。フル トンネルのプロファイルなら、公開アドレスに対してトンネル インターフェイスを示すはずです。スプリット トンネルのプロファイルでは通常そこに物理アダプターが示され、社内プレフィックスは引き続き VPN に解決されます。

「逆方向にルーティングしている」という報告のほとんどは二つの罠で説明できます。最も具体的なプレフィックスが常に勝つため、物理アダプターの /24 はトンネルのメトリックがどれほど低くても VPN の既定ルートを上回ります。メトリックが同順位を決めるのは同じプレフィックスのルート間だけです。さらに IPv4 と IPv6 は別々に決まります：0.0.0.0/0 をカバーするプロファイルでも IPv6 をローカル リンクに残すことがあり、デュアルスタックのサイトが半分だけトンネルされたように見えます。トンネルが正常だと結論する前に Get-NetRoute -AddressFamily IPv6 を確認してください。

What you seeMost likely causeCheck next
Public traffic leaves the physical adapter while SplitTunneling reads FalseA more specific route on that adapter wins over the tunnel defaultFind-NetRoute for the exact destination, then look for a /24 or host route on the physical interface
Internal name fails, internal IP worksNo NRPT rule for that namespace, or a broader rule matches firstGet-DnsClientNrptPolicy and the namespace order
A dual-stack site opens directly while IPv4 uses the tunnelThe profile covers only the IPv4 default routeThe IPv6 route table on both interfaces
Routes look right but one app still goes directThe app uses its own proxy, or the client keeps a per-app listThe app's proxy settings and the client's application list

NRPT で名前解決を別に確認する

社内 IP アドレスは機能するのに社内名が失敗する場合、それはルーティングではなくリゾルバーのポリシーを示しています。Windows は名前空間ごとに名前解決ポリシー テーブルで DNS を決めており、これはルート テーブルとは独立しています。

Get-DnsClientNrptPolicy -Effective | Select-Object Namespace, NameServers
Get-DnsClientServerAddress -InterfaceIndex $vpn.ifIndex

規則が *.corp.example に一致すると、その名前空間のクエリはトンネルの DNS サーバーに送られます：スプリット トンネル モードでそれらのサーバーへのデータ パスが物理アダプター上に残っていても同じです。それが設計であり、公開サイトを開くブラウザー テストが社内名について何も語らない理由です。アダプターが期待どおりのサーバーを一覧しているのに検索が別の場所へ行く場合は、NRPT 規則の順序を比較し、より具体的な名前空間が先に一致していないか確認してください。

フローを検証し、そのうえで実際に何を求めたのかを決める

結果をマシン間で比較できるよう、宛先は決まった順序で確認します：公開アドレス、社内アドレス、社内名、そしてローカル プリンターやビデオ通話のような意図的な例外ひとつです。それぞれについて Find-NetRoute が返すインターフェイスと送信元アドレスを記録します。ポリシーを変更したら再接続し、同じ四つのチェックを繰り返します：再接続後のルート テーブルだけが、新しいプロファイルが有効になった証拠です。

次に、ルーティングと強制を切り離します。強制トンネリングは、トンネルが上がっている間は対象トラフィックをトンネル経由にすることを優先します。キル スイッチではありません。トンネルが落ちたときに何もマシンから出ないことが要件なら、それはブロック設計から来る必要があります：トンネル状態に結び付いたファイアウォール プロファイル、トラフィック フィルター付きの常時接続プロファイル、ベンダー クライアント自身のフェイル クローズ設定のいずれかです。強制トンネリングは、VPN サーバー自身のアドレスをトンネル外から到達可能なままにしておく必要もあり、「すべてを強制する」名目でそれをブロックすると、適用しようとしている接続から自分を締め出す確実な方法になります。

何かを変更する前に、この一覧を確認してください。失敗する項目は、本当の問題がどこにあるかを絞り込みます。

  • プロファイル名とスコープを確認済み（マシン全体のプロファイルには -AllUserConnection を使用）。
  • SplitTunneling を読み、カバレッジの証明ではなく構成として扱った。
  • トンネル アダプターのルートを IPv4 と IPv6 で別々に一覧した。
  • 公開、社内、例外の各宛先ひとつずつに対して Find-NetRoute を実行した。
  • 名前の失敗をルートのせいにする前に、NRPT 規則を確認した。
  • ブロック要件を再確認した：優先ルーティングは強制ブロックと同じではない。

フル トンネルかスプリット トンネルかの判断はプロファイルの所有者に属し、Microsoft のルーティング ノートはプロファイルが設定したときに Windows が実装する動作を説明しています。Microsoft: 強制トンネリングとスプリット トンネリング は、出力を読むときに開いておく参照先です。

関連記事