Windows のパブリック ファイアウォール プロファイルで VPN クライアントがブロックされる

Windows は VPN アダプターをパブリックとして分類するため、LAN の規則は決して適用されません。プロファイルを確認し、受信規則を 一つプールに限定してから、ポートを検証してください。

トンネルは稼働し、ゲートウェイは ping に応答し、ファイル共有はそれでもタイムアウトします。この組み合わせがルーティングの問題であることはまれで、Windows が VPN アダプターのサブネットをパブリック プロファイルに置いたため、プライベート用またはドメイン用に書かれた許可規則は一つも適用されていません。オフィスに問題なく届くノート PC でも、他のすべてのクライアントにサービスを提供する RRAS サーバーでも経験しましたし、関係するプロファイルを特定すれば修正は短時間で済みます。以下が私の作業順序と、次の手順の前に止めるべきかを教える確認です。

トラフィックが実際にどのプロファイルで到着するかを特定する

Windows ファイアウォールに単一のグローバル モードはありません。接続された各インターフェイスはカテゴリを持ち、受信パケットは到着したインターフェイスのカテゴリでフィルターされます。つまり、トンネル内のクライアントが何に到達できるかを決めるのは VPN アダプターのプロファイルであり、隣の Wi-Fi やイーサネットのアダプターではありません。変更する前に両方の事実を確認してください：

Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory, IPv4Connectivity
Get-NetFirewallProfile -Name Public | Select-Object Name, Enabled, DefaultInboundAction

標準の OpenVPN または WireGuard のインストールでは、VPN アダプターは未確認のネットワークとして表示され、パブリック プロファイルに入ります。これは Windows が分類できないすべてのネットワークの既定値で、ドメイン コントローラーが応答したことも、一致するゲートウェイ プロファイルがあったこともありません。インターフェイス名はここでは無関係なので、アダプターを「VPN」や「Corp」と呼んでも何も変わりません。DomainAuthenticated にはドメイン参加済みのマシンが必要です、そのインターフェイス経由で実際にドメイン コントローラーに到達できる必要があり、サブネットを一つだけ運ぶ分割トンネルではこの条件を満たしません。

必要な規則がすでに VPN プールに限定され、たった今読んだカテゴリにすでに適用されているなら、ここで止めてください。フィルタリングはあなたの層ではなく、次に見るべきはサービス構成です。この確認は 十秒で済み、一時間の規則編集を節約します。カテゴリ名とそれぞれが対象とする範囲はGet-NetConnectionProfile のリファレンスに記載されています。

規則を編集する前に、ルーティングではなくフィルタリングであることを確認する

Ping は弱いテストです。サービス ポートが破棄されている間に ICMP は通過し、ホストは LAN から応答しながら、同じ要求をトンネル経由では拒否することがあります。クライアントが必要とするポートをクライアントからテストします。

Test-NetConnection 10.8.0.1 -Port 445
Test-NetConnection 10.8.0.1 -Port 3389 -InformationLevel Detailed

ポート テストが失敗したら、二つの層を切り分けます。トンネルやルートの障害は通常、ゲートウェイ アドレスからまったく応答がない形で現れ、ファイアウォールによる破棄は、応答するゲートウェイと応答しないサービス ポートとして現れます。RRAS でプールを公開している Windows サーバーでは、同じテストをクライアントから実行し、サーバー自身のプロファイルを読みます。RAS インターフェイスが、受信規則でクライアント範囲にまったく触れないカテゴリに入っていることがあり、そのためにそのマシンは自分の LAN には応答し、トンネル内のすべてのクライアントを拒否するのです。

結果がまだ曖昧なときは、関係するプロファイルの破棄をログに記録して読みます：

Set-NetFirewallProfile -Name Public -LogBlocked True `
  -LogFileName "$env:systemroot\system32\LogFiles\Firewall\pfirewall.log"

クライアントのアドレスとポートを DROP とともに示すエントリは決定的で、どの規則が欠けていたかも示します。何も記録がないのにクライアントの SYN が現れないログは、ホストより上流を示すので、別のファイアウォール オブジェクトに触れる前にトンネル、NAT 規則、プールのルートに戻ってください。

それをプールに限定

修正は、送信元アドレスが世界全体ではなくプールである一つの受信許可規則です。昇格したセッションから実行します

New-NetFirewallRule -DisplayName "VPN clients - SMB 445" `
  -Direction Inbound -Action Allow -Protocol TCP -LocalPort 445 `
  -RemoteAddress 10.8.0.0/24 -Profile Public

サービスが単一のバイナリである場合は、ポート一覧ではなく-Programパラメーターを使ったプログラム限定の規則を優先してください。これにより例外はプロセスにも送信元範囲にも限定されます

プロファイルの選択は、同じ間違いが逆方向で起きる場所です。-Profile Publicアダプターがパブリックで、パブリックのままであれば十分です。-Profile Anyサービスが Windows のアダプター分類に関係なく動作する必要がある場合に正当化できますが、リモート範囲が維持されている間だけです。決して正当化できないのは-RemoteAddress Anyパブリック プロファイルでの使用です。その規則はノート PC が接続するすべてのカフェやホテルのネットワークに付いていき、そのサブネットを共有する誰にでもポートを開きます

プールを規則のそばに記録します。-RemoteAddress 10.8.0.0/24VPN プールの番号が振り直された日に静かに一致しなくなり、障害は元のバグとまったく同じに見えるため、もう半日を費やすことになります。規則にはサービスと送信元範囲の名前を付け、-Groupと一緒に保ち、プールの定義が変わるたびに読み直してください。一画面で監査できる規則一覧は、誰も見つけられない正しい規則に勝ります。

カテゴリが判断そのものであるときだけカテゴリを変える

インターフェイスをプライベートに切り替える方法も機能しますが、それは誤った既定です。プライベート プロファイルには多数の組み込み許可規則があり、ファイルとプリンターの共有、ネットワーク探索、リモート デスクトップ、さらにベースラインによってはそれ以上を対象とするため、VPN アダプターを再分類するとトンネル内のすべてのクライアントに対して一斉に有効になります。範囲を限定した 一つの規則は、一つのサービスを 一つの範囲に与えます。信頼できないネットワークにも接続するノート PC では、その違いは見た目だけのものではありません。

分類が本当に誤っている場合もあります：オフィスのサブネットを運ぶ常時接続またはサイト間のトンネルは信頼されたインフラであり、そのアダプターをプライベートとしてマークするのは、チケットごとではなくポリシーによって一度だけ行う正当な設計判断です。行う場合は明示的に行ってください：

Set-NetConnectionProfile -InterfaceAlias "OpenVPN TAP-Windows6" -NetworkCategory Private

管理対象デバイスでは、まずグループ ポリシーまたは MDM ベースラインがその設定を所有していないか確認します。所有している場合、ローカルの変更は次の更新で元に戻り、gpresult /h所有しているポリシーが示されます。エンドポイントではなくそこで修正してください

両端から検証し、記録を残す

変更後に、ユーザーが報告したフローをクライアントから検証します：

Test-NetConnection 10.8.0.1 -Port 445
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallAddressFilter | Select-Object RemoteAddress
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallPortFilter | Select-Object Protocol, LocalPort

その後、来週壊れるものについてループを閉じます。ホストを再起動して再テストしてください。誤ったプロファイルに限定された規則は、アダプターが別のカテゴリで戻るまで機能し続けるので、二台目のクライアントからテストしてください。古いリースを持つ一台のクライアントがプールの不一致を隠すことがあります。追加した規則と削除した規則を数えてください。重複する例外こそが、二行の修正を誰もレビューできないフィルター ポリシーに変える道だからです。

完了と言う前に:

  • 規則で示されたプロファイルは、トラフィックが到着するインターフェイスのプロファイルです。
  • リモート範囲は VPN プールで、そのプールはサーバーが実際に配布するものと一致します。
  • 追加した規則はいずれも-RemoteAddress Anyパブリック プロファイルでは使用していません。
  • テストを通すために無効化したものはなく、カテゴリの変更はすべて誰が承認したかを記録します。

関連記事