VPNアダプターがパブリックファイアウォールプロファイルのままになる理由

トンネルは確立し、アカウントはドメインに対して認証され、それでも Windows は接続をパブリックとして扱います。そのため、ドメインプロファイル向けに書かれたファイアウォール規則は適用されず、ファイル共有には到達できません。よくある対処はアダプターをプライベートに設定することですが、これはどの規則が適用されるかを変えるだけで、認証については何も変えません。ラベルと対処のどちらも広く誤解されており、両者を切り分けるには三つのコマンドが必要です。

接続したアカウントはネットワークのカテゴリではない

VPN 接続の間には二つの異なる判断が行われ、それらは混同されがちです。ゲートウェイはアカウントが接続できるかを判断します。Windows は結果として得られるネットワークをどう分類するかを判断し、その分類がインターフェイスに適用されるファイアウォール規則を決めます。

ゲートウェイでのドメイン認証の成功はアカウントについての証拠です。エンドポイントがネットワークをドメインコントローラーに対して認証した証拠ではなく、ドメインのカテゴリが表すのはまさにその点です。

だからこそ、コンピューターがドメインに参加し、ドメインアカウントで接続していても、パブリックと表示されます。この分類はネットワークについてのローカルな判定であり、トンネルを開いた資格情報についての表明ではありません。アカウントが完全に有効でも、ラベルは最初の場所にとどまります。

三つのカテゴリのうち一つは設定できない

Windows は三つのカテゴリを公開しており、管理者が割り当てられるのはそのうち二つだけです。三つ目は、ネットワークをドメインコントローラーに対して正常に認証した後に、オペレーティングシステムが決定します。

Get-NetConnectionProfile | Select-Object Name,InterfaceAlias,NetworkCategory,IPv4Connectivity
Set-NetConnectionProfile -InterfaceAlias 'Corp VPN' -NetworkCategory Private
Set-NetConnectionProfile -InterfaceAlias 'Corp VPN' -NetworkCategory DomainAuthenticated

三つ目のコマンドは失敗しますが、これは権限の問題ではなく文書化された動作です。コマンドレット自身のリファレンスにも、Windows がドメイン認証から導出するため、ドメインのカテゴリはこの方法では割り当てられないと記されています。エラーを確認することは、カテゴリが設定ではなく結果であるという有用な裏付けになります。

トラフィックがブロックされているエンドポイントで最初のコマンドを実行します。ゲートウェイ自身のインターフェイス分類は、各ワークステーションが自分のトンネルをどう分類したかについては何も語りません。

規則は書かれたプロファイルに従う

カテゴリが分かれば、欠けているアクセスはたいてい自明になります。すべての Windows ファイアウォール規則はプロファイルの範囲を持ち、ドメインに限定された規則はインターフェイスがパブリックのときには適用されません。三つのコマンドでそれが理論ではなく答えになり、三つ目はプロファイルが問題ではなかった場合を捉えます：

(Get-NetFirewallRule -DisplayName 'Allow File Share').Profile
Get-NetFirewallRule -DisplayName 'Allow File Share' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

二つ目のコマンドが、曖昧な報告を修正に変えるものです。規則が VPN プールを含まないリモートアドレス範囲に限定されているなら、プロファイルを変えても解決しません。

既定の受信動作も確認してください。受信が既定でブロックされるコンピューターでは、許可規則の欠落は拒否ではなく沈黙を生みます。クライアント側からはルーティング障害と見分けがつかないため、こうしたチケットの多くは誤った前提から始まります。

どのコンピューターが規則を適用しているかを見極める

カテゴリを変える前に、ブロックがどこで起きているかを確定します。共有をホストするサーバーに独自のファイアウォールがある場合があり、その規則はクライアントがアダプターに付けた名前に関係なく VPN プールからのトラフィックに適用されます。そこでの拒否は、実行するどのローカルコマンドにも見えず、クライアント側はリソースが利用できないと報告するだけです。クライアントの分類に触れる前に、宛先自身の規則を試してください。

クライアントから特定のポートへ試し、同じ VPN 上の別のホストからの試行と比較します。両方が失敗すれば問題は宛先か経路上にあります。片方だけ失敗するなら、違いはそのコンピューターに固有で、プロファイルのカテゴリが有力な原因になります。

方向にも注意してください。受信 SMB を許可する規則は、自身の送信規則が同じトラフィックを遮断しているクライアントには何の役にも立ちません。エクスプローラーのウィンドウからは二つの失敗は区別できないため、何かを編集する前に各方向を別々に試してください。

すべてを付け替える代わりにすべきこと

広い規則を満たすために未知のネットワークをプライベートにするのは、現実の結果を伴う現実の変更です。プライベートプロファイルは通常、パブリックより多くの検出と受信トラフィックを許可します。

特定のサービスを VPN クライアントに届けたいのであれば、規則をプロファイルではなくリモートアドレスで限定してください。意図を正確に表し、分類に関係なく機能し、Windows が仮想アダプターについて正しく推測するかどうかに依存しません。インターフェイスを再分類するクライアント更新にも耐えます。プールを規則に書き込めば、次の人が尋ねずに意図を読めます。

ドメインのカテゴリが本当に期待されるのに決して現れない場合は、別の調査になります。コンピューターがドメインに参加しているか、トンネル経由でドメインコントローラーに到達できるか、セキュアチャネルが正常かを確認してください。次の三つのコマンドは、レジストリを一度も編集せずにそれに答えます：

Get-CimInstance Win32_ComputerSystem | Select-Object PartOfDomain,Domain
Test-ComputerSecureChannel -Verbose
nltest /dsgetdc:corp.example.com

この三つは、エンドポイントがそもそもネットワークを認証できたかどうかに答えます。コントローラーに到達できなければ、アダプターを何度リセットしてもドメインのカテゴリは割り当てられません。追いかけていたファイアウォール規則が真の問題だったのではなく、ラベルは壊れた経路の症状であって原因ではありませんでした。