VPNは接続済みなのにファイアウォールが遮断する：どちらが原因か見分ける方法

クライアントは接続済みと言い、リソースは依然として拒否し、次の定番の一手は何かを無効にすることです。その文の二つの制御は別の仕事をします。VPNは対象トラフィックの経路を作り、ファイアウォールは接続ごとに通過可否を決めます。拒否するポリシーを持つ正常なトンネルは、利用者の席からは壊れたトンネルとまったく同じに見えるので、どの層が答えているかを見つけるのが仕事です。以下が私が使う順序で、止まるべき合図も添えます。

経路とポリシーを分ける

まず障害の形から見ます。無料の情報だからです。パケットのドロップはタイムアウトになります。クライアントは再試行し、何も戻らず、コマンドは諦めるまでぶら下がります。拒否は拒絶かリセットで、何かが答えて「いいえ」と言ったのです。待ち受けないサービスはホスト自身で拒否し、ファイアウォールは一切関与しません。

この三つの結果は別の層を指します。タイムアウトは、どこかのポリシーが静かに捨てているか、経路がマシンから出ていないことを意味します。拒否は、ホストに届き、そのスタックかホストのファイアウォールが断ったことを意味します。完全な沈黙で、トンネルのインターフェースが上がり、宛先への経路がないなら、経路が誤っており、ファイアウォールのルールでは直りません。

経路を一度で読む

トンネルが宛先を覆っているかを確認してから最初のルールを見てください。オフィスのサブネットだけを運ぶ分割トンネルは別の範囲への要求を経路に乗せず、そのとき障害はファイアウォールの遮断のように見えますが、そうではありません：

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

経路の出力は、パケットが出ていくインターフェースと、それが持つ送信元アドレスを示します。そのインターフェースがトンネルではなく物理NICなら、問題はルーティングかトンネルの許可範囲にあり、ファイアウォールではなくVPNの設定に属します。

VPN固有の罠が一つあり、独自の確認に値します。WireGuardでは、ピアの AllowedIPs は経路であると同時に暗号フィルタです。送信元アドレスがピアの許可集合に合わないパケットは、どのファイアウォールルールも見られる前に破棄されます。したがって完全に正しいホストのファイアウォールが、ポリシーのように見える静かな破棄の後ろに置かれることがあり、修正はルールではなく鍵の設定行です。

答えている層でポリシーを読む

経路が正しくなったら、ホストから外側へポリシーをたどり、カウンタが動くただ一つの層に注目します：

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

待ち受けソケットは、ルールとは別の問いに答えます。ポートで何も待ち受けていなければ、カーネルが接続を拒否し、受信ルールは関係ありません。ソケットがあり、リモートクライアントからの接続がタイムアウトするなら、経路のどこかで破棄が起きており、ルールのカウンタがここで起きているかを教えます。

外から推測するのではなく、疑っているプロファイルやチェーンでログを有効にします。送信元、宛先、ポートを示す破棄が一件記録されれば、層とルールが特定でき、パケットが届いたことも証明できます。これはクライアント側のどんな試験でも確かめられません。

トンネルがそこで終わる場合はゲートウェイの判断を読む

サイト間やリモートアクセスのゲートウェイでは、VPNが利用者を認証し、ポリシーがリソースを許可します。これは別々の付与です。トンネルに入れた利用者がすべての内部ホストに自動で入れるわけではなく、拒否はトンネル自体が健全なまま転送ルールから来ることがよくあります。同じ分離はIPsecにも現れ、トラフィックを選ぶセキュリティポリシーと、それを通すフィルタは別物であり、だからこそ両者は異なる機構として RFC 4301。

戻りの経路も行きと同じくらい丁寧に確認します。 ステートフルフィルタは応答を見る必要があるので、トンネルを通る片方向とその周りを通る逆方向という非対称なルーティングは、ランダムに見え、一部のクライアントからしか再現しない破棄を生みます。トラフィックがゲートウェイに届いて止まるなら、何かを広げる前に転送ルールと戻りの経路を一緒に読みます。

ゲートウェイは、NATやマスカレードのルールが本当の送信元を隠せる場所でもあります。内部ホストがクライアントではなくゲートウェイのアドレスを見るなら、クライアントプールに一致すべきホストのファイアウォールルールは決して一致せず、修正は各サーバーではなくゲートウェイに属します。

最も狭い層を変え、それから検証する

広い修理に抵抗します。ホストのファイアウォールを無効にし、すべてを許可するルールを足し、すべてのインターフェースを信頼済みプロファイルに押し込むことは、いずれも仕事をしていた制御を外し、変更はインシデントの後も残ります。送信元範囲と問題のポートに限定したルールは見直しやすく、外しやすく、マシンの残りのポリシーを無傷で残します。

失敗したのと同じ試験を同じクライアントから、再接続後にもう一度行うのは、トンネルが再交渉する前に一致していたルールがその後に一致しなくなることがあるからです：

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

閉じる前に：

• 宛先への経路はトンネルのインターフェースから出ており、送信元アドレスはポリシーが期待するものと一致している。
• ポートで何かが待ち受けており、拒否やタイムアウトは想定ではなく名指しのルールに帰されている。
• ゲートウェイは両方向に転送し、宛先はルールを書いた送信元を見ている。
• 試験を通すためにどの制御も無効にしておらず、加えた変更は一つの送信元範囲と一つのポートを名指ししている。