VPNアドレスを許可リストに入れたのに遮断される？経路をたどる

VPNアプリが表示するアドレスを許可リストに入れても、遮断されたポートが直ることはほとんどなく、その理由はパケットが説明します。ファイアウォールはあなたのルールを無視しているのではなく、クライアント画面には一切表示されない送信元アドレスを評価しています。宛先がその値を報告するまで、ルールの編集はすべて推測です。

サービスに届くリクエストから始めます。トンネルアドレス、出口アドレス、その間の変換は、宛先がいずれかを確認するまで仮説にとどまります。

アプリのアドレスは届くアドレスではない

VPN接続は少なくとも四つのアドレスを持ち、それぞれ別に名付ける価値があります。サーバーのエンドポイント、クライアントに割り当てられた内部トンネルアドレス、ローカルのWi-FiまたはEthernetアドレス、そしてトラフィックがプロバイダーを離れた後にウェブサイトが見る公開アドレスです。クライアント画面には二つ目しか表示されないことがあり、ルールに名前を付ける前に四つすべてを名付けてください。分割トンネルでは、公開宛先へのリクエストがトンネルを完全に迂回することがあり、失敗しているセッションは利用者が開始したと思っているものではありません。

この四つのうち、ルールが許可するのはどれかを決め、反対側から確認します。要件が本当にオフィスのアドレスなら、条件は経路とそのサイトの出口構成であり、Office VPNというラベルの接続が単独でどちらかを提供するわけではありません。

一つのリクエストをフィルタリング境界までたどる

クライアントが使う宛先アドレスとポートを確認し、その宛先が想定した経路をたどるか確かめます。公開されたコンテナポート、リバースプロキシ、ポート転送は、編集したことのないホストへ判断を移すことがあります。これらの各ホップは独自のポリシーを持てます。経路を先に確定すれば、どのパケットも届かないルールを直す手間を省けます。

許可されたLinuxホストで、変更する前に有効なルールを順番に読みます。転送サービスやコンテナサービスはしばしば独自のチェーンへジャンプするので、ジャンプ先と最終判定の両方を確認します。

iptables -vnL INPUT --line-numbers
iptables -S INPUT | head -n 40
ss -ltnp | grep -E ':(443|9443)\b'

チケットに該当するルール番号を記載します。それがなければ、次の読み手はどの編集が結果を変えたのか分かりません。タイムスタンプのないルール番号は依然として曖昧です。

一つの限定したキャプチャで経路を確認する

無害なリクエスト一つと狭いキャプチャ一つで、繰り返し戻ってくる問いに決着がつきます。宛先ポートと調査対象のホストで絞り込み、パケット数を制限し、リクエストが完了したらすぐにキャプチャを止めます。

tcpdump -ni any 'tcp dst port 9443' -c 20

キャプチャ内の送信元、該当ルールが示す送信元、アプリケーションが記録した拒否という三つの値を並べて比べます。これらはすべて異なり得て、IPルールが決めたドロップを説明するのは最初の一つだけです。転送されたHTTPヘッダーはプロキシ層に属するので、そのヘッダーを引用したログはファイアウォールが評価した送信元を表しません。

ルールだけでなくチェーンの順序を読む

iptablesのリファレンスは順序立った通過を記述しており、該当する終端拒否より下にある許可がパケットを救うことは決してありません。以前に受け入れられた接続は新規と異なる振る舞いをすることもあるので、古い成功は新しいルールについて何も語りません。許可が間違っていると決めつける前に、許可より上にある拒否やドロップを探します。ルールごとのカウンターは、どのルールがパケットを見たかも教えてくれます。

何が起きるかを見るためにルールを削除するのは、観察ではなく変更です。カウンターを読み、ルール番号を記録し、元のポリシーを変更記録に残します。テストが避けられないなら、チェーンのコピーで実行します。

所有者が管理するルールを変更する

意図した送信元とサービスのポリシーだけを、それを所有する人を通じて更新します。共有された変換済みの出口は同時に多数の利用者を代表し得るので、そのアドレスを許可しても誰も認証されず、背後のアプリケーション権限はそのままです。

アドレスが動き続ける場合の持続的な答えは、より長い例外リストではなく、安定した出口か認証された経路です。観測した送信元、宛先ポート、ルール番号を記録します。