WindowsのVPNアダプターはプライベートとパブリックのどちらにすべきか？
3つのテストで、WindowsのVPNアダプターをプライベートプロファイルに置くべきかを判断します。信頼できる経路、安定した分類、そして本当に必要な規則です。
WindowsのVPNアダプターをプライベートに設定するのは、企業トンネルには正しく、商用VPNクライアントには誤りであり、その違いは見た目だけではありません。ネットワークカテゴリはファイアウォールプロファイルを選ぶため、一度の変更でルール一式がまとめて許可されます。ログオンスクリプトがすべての未識別アダプターをプライベートに設定し、ホテルの無線LANでファイル共有が静かに露出した例を見たことがあります。答えを決める条件は三つあり、設定に触れる前にすべてが満たされている必要があります。
カテゴリが実際に決めるもの
Network Location Awarenessは、アダプターが報告できる、ゲートウェイのアドレスとMAC、DNSサフィックス、ドメインコントローラーが応答するかどうか、ネットワークがインターネットに到達するかどうかといった情報から、接続ごとに署名を作ります。Windowsはその署名にプロファイルを結び付け、ファイアウォールはそのプロファイルのルール一式を適用します。識別に失敗したときの代替がパブリックであり、動作しているトンネルでも未識別ネットワークと表示されるのはそのためです。
TUNやTAPのアダプターは識別に使える情報をほとんど与えず、トンネルの相手はゲートウェイではなく単一のアドレスであることが多く、DNSはトンネル内だけに配られる場合があり、アダプター自体に既定ルートもありません。結果として付くラベルはファイアウォールへの入力を表すもので、トンネルの健全性ではありません。VPNが接続した瞬間にプライベートプロファイルの規則が一致しなくなるのはそのためです。
条件一：トンネルが信頼できる経路である
プライベートを選ぶことは、検出と受信の規則がそのサブネットをローカルとして扱うため、このインターフェイス経由で到達できるすべてが、少なくとも自分のLANと同じ程度に信頼できると主張することです。ファイルサーバーやプリンターがある管理されたサブネットへの企業トンネルでは、この主張はたいてい成り立ちます。アダプターは組織が管理するネットワークへの扉であり、向こう側のマシンは自分のマシンを許可したのと同じポリシーで許可されています。
商用VPNの出口はこのテストに合格しません。他の加入者が出口のサブネットを共有しており、プライベートと印を付けると、ネットワーク検出、LLMNR、NetBIOSの名前解決が見知らぬ者ばかりのセグメントに置かれます。スプリットトンネルも、アダプターが一つのアプリケーションへの単一ホストルートしか運ばない場合は失敗し得て、信頼できるサブネットが存在しないため、カテゴリを変えても何も得られません。
条件二：分類が再接続後も維持される
新しいゲートウェイやDNSサフィックスは新しい署名を生み、Windowsはそれに対して新しいプロファイル判定を行います。したがって一度きりのSet-NetConnectionProfileは次の再接続までしか持たず、永遠ではありません。設定がひとりでに戻るのはそのときなので、プロファイルは最初の接続後ではなく再接続後に確認してください。
これを恒久化する方法は三つあります。最もきれいなのはポリシーで、secpol.mscを開き、Network List Manager Policiesに進み、未識別ネットワークのポリシーを含めてネットワークの場所の種類を設定することで、プロファイルはコマンドではなくポリシーで適用されます。二つ目は接続ごとのスクリプトか、トンネルが上がった後にPowerShellコマンドレットを実行するスケジュールタスクです。三つ目は昔ながらのルート技で、識別に調べるためのゲートウェイを与えます：
route -p add 0.0.0.0 mask 0.0.0.0 10.8.0.1 metric 50 IF 24
Get-NetConnectionProfileルート技は回避策であって分類ではありません。メトリックの関係が変わったときや、VPNクライアントが再接続時にルートを書き換えたときに壊れ、二番目の既定ルートに落ちるすべてのものの経路選択を静かに変えてしまいます。
条件三：プライベートのルール一式が必要である
プライベートには通常、ファイルとプリンターの共有、ネットワーク検出、リモート管理のグループが含まれます。トンネル越しにSMB共有やプリンターに到達することが目的なら、それがカテゴリを変える本当の理由です。一つのWebアプリケーションへの送信アクセスが目的なら、カテゴリは無関係なので、送信規則を書き、パブリックのままにして、そこで止めてください。
| Scenario | Category | Why |
|---|---|---|
| Corporate tunnel to a file server or printer | Private | Private rules carry the sharing you need |
| Commercial VPN for privacy | Public | The exit subnet is shared with strangers |
| Split tunnel with a single host route | Public | No trusted subnet and an unstable signature |
| Site-to-site tunnel to a branch LAN | Private | The far subnet is managed like the local one |
| Lab adapter you control end to end | Private | Discovery helps and nothing else is exposed |
表は出発点として読み、自分のビルドでどのプライベート規則が実際に有効かを確認してください。強化されたイメージではプライベートプロファイルからファイル共有が完全に削除されていることがあり、その場合は規則を戻すまでカテゴリを変えても何も達成できません。その確認はコマンド一つで済み、長い午後を節約できます。
ほかを広げずに変更する
ワイルドカードではなくインターフェイスインデックスを対象にし、前後で一覧を読んでください：
Get-NetConnectionProfile
Set-NetConnectionProfile -InterfaceIndex 24 -NetworkCategory Private
Get-NetFirewallProfile保存されたプロファイルはレジストリのNetworkListキーの下にあり、Category値がパブリック、プライベート、ドメインのネットワークを分けています。編集は可能ですが間違えやすく、変更すべきはアダプターの現在の署名に一致するエントリであり、以前のアドレスが残した古いエントリではありません。古いエントリはエディター上では正しく見え、再接続時には何もしません。
すべての未識別アダプターをプライベートにするスクリプトを配るのは、信頼できない無線LANで検出を開くことの一行版になるため、何をするにしても避けてください。共有が必要なのがトンネルのサブネットだけなら、プロファイルはパブリックのままにし、トンネルのリモートアドレス範囲に限定した受信規則を追加してください。ファイアウォール規則のほうがカテゴリより狭いのです。
ラベルではなく共有を検証する
変更後はラベルを信じるのではなく、リソースそのものを試してください：
Test-NetConnection files.corp.example -Port 445
Resolve-DnsName files.corp.exampleアダプターがプライベートを示しているのに共有が失敗し続けるなら、カテゴリはもう問題ではありません。名前解決、欠けたルート、共有のアクセス許可のいずれも同じ症状を生み、プロファイルを再度変えてもどれも直りません。一度再接続してGet-NetConnectionProfileを再実行し、設定が維持されたことを確認したうえで、残った不具合を通常のSMB問題として扱ってください。
チェックリスト：トンネルが管理された経路であること、プロファイルが再接続後も維持されること、必要なプライベート規則がイメージ上に存在すること、共有が名前解決されてポート445で応答することを確認してください。最初の三つのいずれかが偽なら、アダプターはパブリックのままにし、限定した規則でアクセスの問題を解決してください。