PowerShellでアクティブなVPN接続を確認するときは、「VPNプロファイルが登録されている」「トンネル用アダプターがUp」「VPN経由のIPアドレスや経路がある」「目的の通信が実際にVPNへ流れる」を分けて調べます。Windows標準VPNならGet-VpnConnectionのConnectionStatusが入口ですが、サードパーティー製VPNやデバイストンネル、別ユーザーの接続は同じ一覧に出ない場合があります。本記事では、設定を変えずにプロファイル、アダプター、IP構成、経路を照合し、接続中かを安全に判断する方法を解説します。
「アクティブ」の判定を一つの表示に任せない
目的が「VPNボタンが接続済みか」「社内向け経路があるか」「特定業務サービスへの通信がVPNを通るか」「端末管理上VPN準拠か」で、必要な証拠は異なります。接続直後や再認証中には状態が変化し、Always On VPNは利用者が操作していなくても接続することがあります。判定時刻、利用者セッション、ネットワーク、接続方式、対象サービスを先に記録します。
VPNプロファイルが存在しても切断中の場合があり、逆にサードパーティー製クライアントはGet-VpnConnectionへ表示されなくても独自トンネルが有効な場合があります。アダプターがUpでも認証済みトンネルとは限らず、既定経路がVPNでもすべての宛先が同じ経路とは限りません。プロファイル状態、アダプター、アドレス、ルート、目的宛先の順に複数の観測をそろえます。
Get-VpnConnectionでユーザーVPNプロファイルを確認する
Get-VpnConnectionを引数なしで実行すると、現在のユーザーの電話帳に登録されたWindows VPN接続プロファイルを取得できます。Name、ServerAddress、TunnelType、ConnectionStatus、SplitTunnelingなどを確認します。アクティブ候補だけならConnectionStatusがConnectedのオブジェクトへ絞ります。
Get-VpnConnection |
Where-Object ConnectionStatus -eq Connected |
Select-Object Name, ConnectionStatus, TunnelType,
SplitTunneling, AllUserConnectionConnectionStatusがConnectedなら、そのWindows VPNプロファイルは取得時点で接続状態と報告されています。ただし、業務アプリの認証、社内DNS、特定サブネットへの経路、サービス側の正常性までは保証しません。ServerAddress、認証方式、DNSサフィックスは組織のネットワーク設計情報なので、一般公開するログには含めないか伏せます。資格情報や事前共有キーを表示する必要はありません。
AllUserConnectionと現在ユーザーの電話帳を区別する
Get-VpnConnection -AllUserConnectionは、グローバル電話帳のVPNプロファイルを対象にします。引数なしの結果とは保存場所と適用範囲が異なるため、両方を混ぜずに取得元を記録します。端末全体へ展開したプロファイルがAllUserConnection側にあり、利用者が作成したプロファイルが現在ユーザー側にあるなど、同じ表示名が別々に存在することも考えられます。
$userVpn = Get-VpnConnection -ErrorAction SilentlyContinue
$allVpn = Get-VpnConnection -AllUserConnection -ErrorAction SilentlyContinue
$userVpn | Select-Object Name, ConnectionStatus, AllUserConnection
$allVpn | Select-Object Name, ConnectionStatus, AllUserConnection別ユーザーの個人電話帳を通常セッションから完全に列挙できるとは限りません。Always On VPNのユーザートンネルとデバイストンネルも、実行コンテキストや管理方式により見え方が異なります。空の結果を「端末にVPNなし」と断定せず、MDM/Intune、グループポリシー、VPN製品の管理画面、利用者セッションを確認します。権限を上げるためにセキュリティ制御を弱めません。
Get-NetAdapterでトンネル用アダプターを探す
Get-NetAdapterはネットワークアダプターのName、InterfaceDescription、Status、ifIndexなどを取得します。VPN接続中に作成または有効化されるアダプターがある場合、StatusがUpになり、製品名やWAN Miniportに関係する説明が見えることがあります。ただし、名前へ「VPN」が含まれるとは限らないため、既知の正常端末や製品資料と照合します。
Get-NetAdapter -IncludeHidden |
Select-Object ifIndex, Name, InterfaceDescription, Status, LinkSpeed |
Sort-Object ifIndexWindowsにはVPN以外にもHyper-V、コンテナー、ループバック、Wi-Fi Direct、フィルター関連の仮想アダプターがあります。Upの仮想アダプターをすべてVPNと見なせません。また、一部VPNは通常のNetAdapter表示とは異なる経路やフィルターを使います。想定外のアダプターを見つけても削除・無効化せず、PnP情報、署名済みドライバー、導入製品、管理者資料を確認します。
Get-NetIPConfigurationでVPN側アドレスとDNSを照合する
Get-NetIPConfiguration -Detailedで各インターフェースのIPv4/IPv6アドレス、既定ゲートウェイ、DNSサーバー、ネットワークプロファイルを確認します。Get-NetAdapterのifIndexと対応付け、VPN接続前後で対象インターフェースにどのアドレスやDNSが追加されたかを比べます。VPN製品によってはゲートウェイが通常の形式で表示されず、経路だけが追加される場合があります。
Get-NetIPConfiguration -Detailed |
Select-Object InterfaceAlias, InterfaceIndex, IPv4Address,
IPv6Address, IPv4DefaultGateway, DNSServerVPN向けのプライベートIPがあることは重要な手掛かりですが、トンネルの認証と業務サービスの到達性を単独では保証しません。DNSサーバーが社内向けに変わっていても、NRPTやアプリ固有DNS、DoHなど別の名前解決経路が関係する場合があります。IPやDNSの値は組織構成情報なので、チケットへ貼るときはアクセス範囲を限定し、公開フォーラムでは伏せます。
Get-NetRouteでフルトンネルとスプリットトンネルを確認する
フルトンネルでは既定経路がVPNへ向く設計が多く、スプリットトンネルでは社内サブネットなど特定の宛先プレフィックスだけがVPNインターフェースへ向きます。Get-NetRouteでDestinationPrefix、InterfaceIndex、NextHop、RouteMetric、PolicyStoreを表示し、VPN接続前後または正常端末と比べます。Get-VpnConnectionのSplitTunneling設定だけで実効経路を断定しません。
Get-NetRoute |
Select-Object DestinationPrefix, InterfaceIndex, NextHop,
RouteMetric, State, PolicyStore |
Sort-Object InterfaceIndex, DestinationPrefix複数の経路が一致する場合は、一般により具体的なプレフィックスが優先され、メトリックやインターフェース設定も関係します。VPN製品が独自フィルターやアプリ単位制御を使うと、ルート表だけで全挙動を説明できません。目的の社内宛先が期待するInterfaceIndexへ向くかを確認し、経路追加・削除で無理に通すことは避けます。セキュリティ境界やデータ経路を変える可能性があります。
目的の宛先で実際に選ばれる経路を確認する
Test-NetConnectionは、対象ホストへの名前解決、選択された送信元アドレス、インターフェース、経路、ICMPやTCP接続の診断に使えます。管理者が許可した業務サービス名とポートを一つ選び、-InformationLevel Detailedまたは-DiagnoseRoutingで確認します。例のホスト名をそのまま使わず、実環境の正規のテスト先に置き換えます。
Test-NetConnection -ComputerName "internal.example.com" -Port 443 -InformationLevel DetailedTcpTestSucceededがTrueでも、TLS証明書、HTTP、認証、アプリ処理まで成功した意味ではありません。Falseでも、DNS、VPN経路、接続先停止、ポート待受、ACL、プロキシなど複数原因があります。InterfaceAlias、SourceAddress、RemoteAddressを記録し、VPNの状態と照合します。多数のアドレスやポートを走査せず、業務上許可された最小のテストにします。
サードパーティーVPNは製品固有の状態も確認する
Cisco、Fortinet、Palo Alto、Zscalerなどのクライアントやゼロトラスト製品は、Windows標準VpnClientモジュールと異なるサービス、ドライバー、アダプター、管理UIを使うことがあります。Get-VpnConnectionに出ないことは未接続の証明ではありません。製品のタスクトレイ表示、サポートされる診断画面、サービス状態、アダプター、ルート、公式ログ取得手順を使います。
独自CLIがある場合も、非公開コマンドや設定ファイルの直接編集ではなく、製品ベンダーが文書化した読み取りコマンドに限定します。ログにはユーザー名、端末ID、ゲートウェイ、内部ドメイン、証明書情報が含まれることがあるため、サポート窓口の安全な経路で共有します。Windows標準VPN向けのConnectionStatusを、サードパーティー製品の唯一の監視指標にしません。
接続の瞬断と再認証は複数時点で観測する
利用者が「時々切れる」と申告する場合、一回のConnected表示では足りません。許可された短時間だけ、Get-VpnConnection、関連アダプターのStatus、VPN向け経路、目的サービスへの少数回の接続結果を時刻付きで確認します。スリープ復帰、Wi-Fiローミング、ネットワーク切替、トークン更新、証明書期限、アイドルタイムアウトと同時刻かを見ます。
高頻度で連続テストすると端末、VPNゲートウェイ、監視へ負荷を掛け、アカウントロックや誤検知につながる場合があります。間隔、回数、対象を決め、認証を繰り返す自動化は避けます。切断・再接続ボタンを連打せず、取得した時刻、ConnectionStatus、InterfaceIndex、経路、エラー表示をVPN管理者へ渡します。必要なら製品の公式診断バンドルを承認済み手順で取得します。
確認結果をまとめるチェックリスト
- プロファイル登録、接続状態、アダプター、IP、経路、目的通信を別々に確認したか
- Get-VpnConnectionの現在ユーザーと-AllUserConnectionを区別したか
- サードパーティーVPNがVpnClient一覧へ出ない可能性を考慮したか
- Get-NetAdapterのifIndexとGet-NetIPConfigurationのアドレス・DNSを照合したか
- Get-NetRouteでフルトンネルとスプリットトンネルの実効経路を確認したか
- Test-NetConnectionのTCP成功をアプリ全体の正常と誤解していないか
- VPNサーバー、内部IP、DNS、ユーザー情報を必要以上に共有していないか
結果は取得時刻、端末名、Windowsのエディションとビルド、PowerShellの版、実行ユーザー、対象範囲とともに残します。空の結果は存在しない証明ではありません。権限、モジュール、製品方式、表示対象、リモート接続、Windows版を確認し、取得不能と未検出を分けます。変更、切断、削除、更新、再起動が必要な場合は読み取り確認から分離し、利用者への影響、管理ポリシー、バックアップ、復旧方法を確認します。
コメント