Ping が片方向しか通らない理由：Windows がサーバーのエコーを落とす仕組み

クライアントからサーバーへは Ping が通るのに、サーバーからクライアントへは通りませんが、トンネルはどちらの文でも明らかにパケットを運んでいます。違うのは経路ではなく、各テストの最初のパケットです。一方は Windows がすでに追跡しているフローへの応答で、もう一方はどのルールも許可していない新規の受信要求であり、この違いが片方向 Ping の報告のほとんどを説明して、書くべきルールを直接指し示します。逆向きの二つのテストを行えば、一分ほどでどちらのケースか切り分けられます。

二つの方向、二つの異なる判断

クライアントがエコー要求を送ると、Windows ファイアウォールは許可を決めた送信接続として認識します。応答はその確立済みのフローの中を通って戻るため、状態を追跡するエンジンは ICMP 用の受信ルールを参照せずに通します。これが実運用におけるステートフル フィルタリングの意味であり、誰も書いていないルールは関係しません。したがってクライアントの成功は、受信ポリシーについて何も語っていません。

サーバーが先に要求を送ると、それに一致する状態はありません。Windows はそのパケットを新規の受信接続として扱い、受信ポリシーに問い合わせますが、既定では任意の送信元から届くエコー要求を想定していません。

つまりクライアントの成功が証明したのは、送信 ICMP と戻り経路が機能していることだけです。受信側の判断は一度も試されておらず、ファイアウォールは問題ないという自然な結論は、もっともらしく、そして誤りです。だからこそ、証拠がすでに揃っているチケットでもこの間違いが繰り返されます。

パケットが消えるまで追いかける

何かを変える前にアドレスを確認します。クライアントが実際に持つトンネル アドレスを使い、サーバーがクライアント背後の LAN アドレスではなくそこへ経路を向けていることを確かめます。二つの失敗はサーバーのプロンプトからは同じに見えますが、どちらもタイムアウトで終わるからであり、パケットがどこで消えるかが何を変えるべきかを決める唯一の事実です。

要求がトンネル インターフェイスに届いても何も出ていかないなら、ローカル ファイアウォールが有力な原因です。インターフェイスにまったく届かないなら、答えは上流、つまりサーバーのルート、送信ポリシー、あるいは VPN 自身のピア間配送です。

サーバーが Ping している間に、クライアントのトンネル インターフェイスでキャプチャします。要求が応答を伴わずに届くのを見ることは、Windows のルールを書く根拠になります。何も見えない場合は上流へ目を向けるべきで、その状態でルールを足しても、決して届かなかったパケットに対してマシンが寛容になるだけです。どちらにせよ、キャプチャの手間は置き換える推測より小さく済みます。

ICMP を開くのではなく、ルールを一つに絞る

どちらもこれから設定するスコープに現れるので、何かを書く前にアダプターと現在のカテゴリを特定します。そのエイリアスは Windows のインターフェイス名であり、インポートした VPN プロファイルの名前とは限りません。以下のコマンドは存在するものを一覧し、続いて適用せずに絞り込んだルールをプレビューします。

Get-NetConnectionProfile
Get-NetAdapter | Where-Object Status -eq 'Up'
New-NetFirewallRule -DisplayName "VPN server echo" -Direction Inbound -Protocol ICMPv4 -IcmpType 8 -RemoteAddress 10.63.0.1 -InterfaceAlias "Office VPN" -Profile Private -Action Allow -WhatIf

ICMPv4 のタイプ 8 がエコー要求であり、サーバーが応答を受ける必要のある唯一のメッセージです。それをサーバーのトンネル アドレスとトンネル インターフェイスに絞り、プロファイルはアダプターの実際の状態のままにします。例に合わせてネットワークの名前を変えるのは、それ自体の影響を伴う別の変更です。

このルールが対象としないもの

IPv6 のエコーはメッセージ タイプの異なる別のプロトコルなので、ICMPv4 のルールは何も語りませんし、両方のファミリーを運ぶトンネルにはもう一方のためのルールが別に必要です。このルールはほかの何も開かず、RDP、ファイル共有、その他のサービスは依然としてそれぞれのポリシーに従います。広い ICMP 許可を有効にするのではなく、狭いルールを一つに絞ることにこそ意味があります。広い許可は簡単な修正であり、あとから誰も気づかないために最も長く残る修正でもあります。

管理されたデバイスでは、次回のポリシー更新でルールが置き換えられる可能性があるため、ローカル管理者ではなくポリシーの所有者が同等の変更を行う必要があります。更新はコマンドを消し、要件だけを残すので、意図をコマンドとともにチケットに書きます。両者は同じ成果物ではなく、残るのはどちらか一方だけです。

結果は正しい方向から読む

ルールが適用されたら、サーバーから Ping して応答がクライアントに届くことを確認し、次に除外されたままであるべき送信元から Ping して届かないことを確認します。トンネルがもう一方のアドレス ファミリーを運んでいるなら、その側でも到達性テストを繰り返します。

Get-NetFirewallRule -DisplayName "VPN server echo" | Get-NetFirewallAddressFilter
ping 10.63.4.17
ping -6 fd00:63::17

有効になったルールを表示するほうが、プレビューと適用済みのルールは別の状態なので、それを作ったコマンドを信じるより有用です。アドレス フィルターが意図した送信元を示し、除外した送信元が依然としてタイムアウトするなら、ルールはそのスコープどおりに動いています。クライアント発の成功した Ping ではそれは決して示せないので、各テストの向きは結果と並べて記録に残します。チケットには両方向を残さないと、次の読み手が失敗しようのないテストを繰り返すことになります。