ファイアウォールがVPNを遮断しているのか？段階を追った確認

VPNのタイムアウトが一度起きたという事実は、使える応答が返らなかったことだけを示し、理由については何も示さない。プロファイルが誤ったポートを示しているかもしれず、サーバーが停止しているかもしれず、戻り経路が機能しないまま要求が届いているかもしれない。どれも残す痕跡が異なり、その痕跡がどの規則に触れるべきかを教えてくれる。以下の四つの段階を順に進める。いずれかが症状を説明した時点で止める。

ステップ1：サーバーとトランスポートを確認する

サーバー名、トランスポート、ポートはローカルの変更ではなく、事業者の現行プロファイルから読む。手元のノートPCで変えたポートが公開サーバー側にリスナーを作ることはなく、その不一致は遮断と同一のタイムアウトを生む。プロファイルが対応済みの代替トランスポートを用意しているなら、修正ではなく代替手段として記録する。名前を解決し、その答えを事業者が公開しているアドレスと突き合わせる。

古いDNSレコードは、一度も応答しなかったホストへクライアントを送る。これもフィルターを装う別の障害であり、除外するのに問い合わせ一回で足りる。

両方の値をチケットに書く。以後の比較はすべてこれを使い、これがないチケットは調査を最初からやり直させる。

ステップ2：統制された比較一回で経路を証明する

端末とプロファイルを変えずに、別の信頼できるアクセス網で試す。そこでトンネルが上がれば、違いは元の経路かそのポリシーにある。元の網で二台目の承認済み端末が動けば、違いは一台目の端末にある。この二つの比較のどちらかは、ほぼ常に決定的になる。

先に正規のネットワークサインインを済ませる。キャプティブポータルは完了するまで遮断のように見える。

実際に使っているポートを試験し、TCPの結果はTCPに関する情報としてだけ扱う。

Resolve-DnsName vpn.corp.example
tracert -h 8 -w 500 vpn.corp.example
Test-NetConnection vpn.corp.example -Port 443 -InformationLevel Detailed

443番ポートでのTCPハンドシェイク成功は、そこにリスナーが応答したことを示す。51820番のUDPリスナーについては何も示さず、ネゴシエーションが完了したかも示さない。

ステップ3：失敗した瞬間のセキュリティイベントを読む

ファイアウォールのイベントは入手できる最も強い証拠だが、先に述べるべき注意点がある。多くの既定プロファイルではログが無効なので、空のログを無実の証拠と読む前に、該当プロファイルが破棄を記録しているかを確認する。ログが有効なら、イベントは規則、方向、アドレスを示し、これは規則変更にまさに必要な情報だ。アプリケーション規則とポート規則は別のオブジェクトであり、管理ポリシーがローカル設定を上書きすることがある。ある規則が実際にどのクライアントとどのサービスを対象にしているかを確認する。

プロファイルの状態と直近のイベントは、隣のホストではなく失敗したマシンから集める。

イベントの時刻は自分の試験時刻と突き合わせる。規則名が一致していても時刻が違えば偶然だ。

Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, LogBlocked
Get-NetFirewallRule -Enabled True -Direction Outbound | Where-Object DisplayName -match 'VPN'
Get-WinEvent -LogName 'Microsoft-Windows-Windows Firewall With Advanced Security/Firewall' -MaxEvents 20

自分が管理するサーバーでは、要求がそもそもリスナーに届いたかを問う。応答なしで到着しているパケットは転送か戻り経路の問題だ。まったく現れない要求はフィルタリングかアドレッシングの問題だ。

ステップ4：トンネルが上がった後に転送を試験する

ファイアウォールはセッションを許可しながら、セッションが到達したいものすべてを拒否できる。転送のsysctl、NAT規則、戻り経路はいずれも認証より後ろにあり、VPNポートへの広い例外はそのどれも直さない。内部の宛先とインターネットの宛先を別々に試験する。通常は異なる理由で失敗するからだ。内部の名前が失敗してアドレスが通るなら、どの規則よりも先にプッシュされたDNSを見る。

クライアントが接続し、失敗する要求を試みている間に、サーバーで以下の三つの確認を実行する。

トンネルインターフェイスのカウンターが要点だ。パケットが入ったか、何か出たかを示す。

sysctl net.ipv4.ip_forward
nft list ruleset | grep -n -E 'forward|masquerade'
tcpdump -ni tun0 -c 10

トンネルにパケットが届くのに宛先へ何も出ないなら、疑わしいのは転送かNATだ。何も届かないならセッションは上がっているがクライアントが送っておらず、見るべき場所はクライアントの経路表だ。

修正を確認し、役に立たなかったものを外す

承認された修正の後、失敗した試験をそのまま繰り返し、同じプロファイルと端末に対して結果を記録する。そのうえで、結果を変えなかった一時的な例外を外す。使われない例外は積み上がり、どれも誰も覚えていない判断になるからだ。残すものは狭く保つ。宛先一つ、ポート一つ、方向一つ、担当一人。

同じ三つのコマンドを再実行し、変更前に保存した出力と比較する。

Test-NetConnection vpn.corp.example -Port 443 -InformationLevel Detailed
tracert -h 8 -w 500 vpn.corp.example
Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match 'VPN' | Select-Object DisplayName, Action

比較用の網が動き、元の網が依然として失敗し、イベントが空のままなら、残る容疑者はホストではなく経路だ。両方の比較結果を添えて、具体的な主張としてネットワークの責任者に渡す。無効化したファイアウォールプロファイルより、ここで止めるほうがよい。