EC2 から AWS Client VPN のノート PC に到達できない理由
Client VPN は IPv4 のクライアント送信元をエンドポイントのネットワークインターフェイスに変換します。そのため応答は届き、EC2 からの新規接続は届きません。
AWS Client VPN 経由で接続したノート PC は、EC2 上のアプリケーションに問題なく到達します。次に逆方向、EC2 からクライアントに割り当てられたアドレスへ試すと、接続はハングするか拒否されます。この非対称性がセキュリティグループのルール漏れであることはほとんどありません。VPC サブネットに関連付けられた Client VPN エンドポイントでは、AWS が IPv4 のクライアント送信元をエンドポイントのネットワークインターフェイスに変換するため、ノート PC を表す受信側の VPC アドレスは存在しません。
キャプチャが示すものから始める
クライアントの接続中に EC2 ホストでキャプチャを取り、アプリケーションが実際に見ている送信元アドレスを読み取ります。それがクライアントプールのアドレスではなく VPC 側のエンドポイントインターフェイスであれば、ルールを一つも変える前に変換が確認できます。
クライアントプールは割り当て範囲であり、戻り経路を持つサブネットではありません。この区別を誤る点が、こうした調査のほとんどのはまりどころです。
非対称性を説明する変換
三つのフローが混同されますが、実際に試されるのはそのうちの一つだけです。
| Flow | Started by | What the VPC sees | Outcome |
|---|---|---|---|
| Client to EC2 service | The client | A translated source at the endpoint interface | Works, with a stateful reply |
| EC2 host to client pool address | The EC2 host | A destination with no route and no translation state | No usable path |
| Client to client | A client, when the feature is configured | Traffic mediated by the endpoint | Works only with that feature and its authorisation |
Client VPN のコンポーネントの説明には、IPv4 のクライアント送信元がエンドポイントのインターフェイスに変換されると明記されており、中央の行に一致するものがない理由がわかります。
新しい接続には経路、アドレス解決の手順、認可の判断が必要です。他人のセッションの変換状態は、そのどれも提供しません。
応答が新規接続ではない理由
TCP の応答は既存のエントリと照合されるため、受信ルールがまったくなくても戻りの経路は機能します。EC2 ホストからの新しい SYN には照合するエントリがなく、VPC が到達方法を知らない宛先への通常の送信試行になります。
だからこそ、これを一方向にしか流れない通信と表現するのは誤解を招きます。このセッションでは戻りの通信が継続的に流れています。経路がないのは開始の側です。
本来機能すべきセッションを今も壊すもの
セキュリティグループ、ネットワーク ACL、ノート PC 自身のファイアウォールは、成功すべき接続すべてに関係します。失敗した ping が最も情報を与えないのは、ICMP のポリシーが目的の TCP ポリシーと別であることが多いためです。
これらのルールは変換後の送信元に対して書き、クライアントのアドレスに対して書かないでください。ネットワーク上に決して現れないアドレスに紐づけたルールが、この設計で最も多い自ら招く障害です。
VPC が本当に会話を始めなければならない場合
サービスがワークステーションに通知する必要がある場合は、方向を反転し、クライアントにサービスが応答する常設の送信チャネルを保持させます。リモートネットワーク全体を VPC から到達可能にする必要がある場合は、Client VPN がすでに行っていると仮定せず、プレフィックスとアクセスポリシーを公開するアーキテクチャを選択してください。クライアント間アクセスは、独自の経路と認可オブジェクトを持つ 三つ目のより狭いケースです。いずれも既存のエンドポイントのチェックボックスではありません。
IPv4 の説明の範囲も正直に保ってください。現在の AWS ドキュメントは、この変換が適用されない IPv6 と、別の方法でルーティングする他の接続モデルを分けています。
ラベルを付けた 三つの手順で試します。クライアントが許可されたセッションを開き、VPC のサービスがそのセッションに応答し、VPC のホストがクライアントに向けて新しいセッションを開く。最初の二つが成功して 三つ目が失敗するのがこの設計の想定された形であり、ファイアウォールルールで追いかけるべき不具合ではありません。