VPNトンネルのアドレスが受信ポートを開かない理由
トンネルアドレスはそこへルーティングできるピアに対してクライアントを識別するもので、リスナーを決して作りません。バインド、戻り経路、次にポリシーを確認してください。
オフィスのVPNに接続し、ポート8443で小さなサービスを起動し、トンネルアドレスを同僚に送ると、クライアントは接続済みと報告したまま接続は失敗します。トンネルには何も壊れておらず、アドレスは割り当てられ、セッションは確立しており、応答を運ぶはずのパケットが単に一度も通されていないだけです。以下の三つの確認を順番に行い、失敗したところで止めてください。それぞれ修正方法が異なり、VPNに関係するのはそのうち一つだけです。
まず、ソケットが実際にどこにバインドされているかを見ます
何かがルーティングされる前に、呼び出し側が到達できるアドレスで何かが待ち受けている必要があります。開発サーバーがよくある原因で、多くは既定でループバックにバインドされ、同じマシンから発信された接続しか受け付けません。トンネルアドレスはそのバインドを変えず、VPNが関与するよりずっと前にオペレーティングシステムが接続を拒否します。
ss -ltnp | grep 8443
netstat -ano | findstr 8443状態ではなくローカルアドレスの列を読みます。127.0.0.1:8443 はループバックのみを意味し、修正は 0.0.0.0 またはトンネルアドレス自体へのバインドです。0.0.0.0:8443 はすべてのインターフェースで受け付け、マシンに公開アドレスもある場合には多くの人が意図するより広くなります。10.64.7.15:8443 は同僚が到達できる場所だけで待ち受ける狭い版です。同じ出力のプロセス名にも注意してください。以前のテストで残ったインスタンスが、ポートが開いているように見えて誤った内容で応答するよくある原因です。
次に、そのアドレスへルーティングできるものがあるかを問います
トンネルアドレスは、そのプレフィックスをトンネルへ送るように設定されたピアにとってのみ意味を持ちます。同僚のマシンには独自のテーブルがあり、トンネルのサブネットへの経路がなければ、パケットは既定ゲートウェイへ進み、アドレスの存在を知らない場所で消えます。これは呼び出し側のルーティングの話であり、あなた側の許可の話ではありません。
| Symptom from the caller | What it usually means | Where to look next |
|---|---|---|
| Connection refused immediately | Nothing is listening on the address the packet reached | The bind address and the process owning the port |
| Connection times out with no reply | A policy dropped the packet, or no route returns | Server forwarding, host firewall, cloud security group |
| Works from the same machine only | Listener is on loopback, or no route reaches the tunnel address | Bind address, then the caller's route to that prefix |
二人のクライアントの間にあるサーバーも同じくらい重要です。一般的なリモートアクセスの設計では、各クライアントがゲートウェイへ外向きの接続を開き、ゲートウェイがそのフローの状態を保持するため、応答はすでに知っている経路で戻ります。あるクライアントから別のクライアントへの接続は、ゲートウェイが受け入れて転送しなければならない新しいフローであり、多くの導入ではクライアント同士を分離するために意図的に無効にしています。コンシューマー向けVPNサービスは通常既定で分離し、企業向けゲートウェイはグループ単位で許可することもあります。
ホスト側で何かを変更する前に方向を確認します。トンネルアドレスがゲートウェイ自身からは応答するがピアからは応答しないなら、違いはゲートウェイのクライアント間接続の設定であり、ローカルファイアウォールの編集では決して代用できません。
最後に、フローを許可するポリシーを見つけます
ルーティングされたパケットと応答するサービスの間には三つのポリシー層があります。VPNサーバーの転送判断、ホストのファイアウォール、そしてインスタンスの前にあるクラウドのセキュリティグループです。三つすべてが一致する必要があり、失敗の仕方もそれぞれ異なるため、上の表の症状はブラウザーのエラーメッセージより役に立ちます。
ホストのファイアウォールは、バインドに成功した後に忘れられる層です。LANインターフェースでポートを許可するルールは、トンネルインターフェースでも自動的に許可するわけではありません。インターフェース単位のルールは正しい設計であり、オフィスからは動くが自宅からは動かないサービスのよくある原因でもあります。ルールのポート番号ではなく適用範囲を読んでください。
ステートフルフィルタリングは逆のケースを説明します。ノートPCからの外向き接続は状態を作り、その応答は受信ルールなしで通されます。同僚の接続は背後に状態のないまったく新しいフローなので、明示的な許可が必要です。この非対称性こそが、自分のマシンで動くブラウザーセッションが外部からの到達性について何も語らない理由のすべてです。
一つの確認が失敗したら、トンネルではなく設計を変えます
要件が同僚にローカルサービスを開いてもらうことなら、正直な答えは通常、受信アクセスのために作られた仕組みです。リバースSSHトンネルが最小で、あなたのマシンが同僚のすでに到達できるホストへ外向きに接続し、リスナーはそのホスト上に存在します。
ssh -N -R 8443:127.0.0.1:8443 [email protected]リレーにはSSHサーバー設定で GatewayPorts clientspecified が必要です。そうでなければ転送されたリスナーはリレー上のループバックにバインドされ、同僚は以前と同じ拒否に遭います。半日より長く続くものには、ヘルスチェックと公開名の証明書を備えたロードバランサーやingressのほうが適した道具であり、二つのネットワークが本当に通信する必要があるときは、両方のサブネットへの経路を持つサイト間トンネルが正解です。
これらの設計はいずれも露出を明示的にします。それが要点です。VPNはすでに利用を許可されていたネットワーク間でパケットを運ぶものであり、サービスを公開せず、ノートPCをインターネットに面したホストに変えることもありません。三つの層のどれを変えるかを決めることが課題であり、トンネルがその一つになることはほとんどありません。