EC2 上の Access Server フルトンネル：チェックボックス一つでは足りない理由

EC2 インスタンスの送信元/宛先チェックを無効にすることは、Access Server のインターネット出口に関する質問で最も繰り返される答えですが、それだけではクライアントに対して何も行いません。このチェックは AWS の転送制約であり、送信元または宛先が自分自身のアドレスでないパケットをインスタンスが受け入れるようにするものです。クライアントにインターネット通信をトンネル経由で送れと指示するものでも、上流への経路を作るものでも、NAT を追加するものでもありません。チェックボックスそのものが機能だというのは誤解です。

チェックが実際に制御しているもの

EC2 の各ネットワークインターフェースは、自分宛てでない通信を破棄します。ただしインスタンスがルーター、NAT デバイス、VPN ゲートウェイとして動作し、そのチェックを無効にしている場合は例外です。無効にすると転送の許可が得られます。許可は設定ではありません。インスタンスには依然としてインターネットゲートウェイや NAT デバイスへの経路が必要で、VPC のルートテーブルには対応するエントリが必要で、セキュリティグループは通信を許可している必要があり、サーバーは戻り通信を変換またはルーティングする必要があります。

何かを変更する前に aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck で現在の値を確認してください。コンソールで変更するなら、クライアントがインターネットに届かないからではなく、インスタンスが他者のために転送するから変更するのです。

クライアントのルーティングポリシーは Access Server が持つ

Access Server 3 では Access Controls を開き、Internet Access and DNS のセクションを見つけます。Internet Gateway の選択肢はフルトンネルか分割トンネルです。フルトンネルは既定の通信を VPN 内へルーティングするようクライアントに指示し、分割トンネルはインターネット通信をクライアントのローカル経路に残します。製品のワークフローで保存して適用し、その後でテストクライアントを再接続してください。ポリシーは接続時に配信されるためです。

古いリリースはメニューが異なり、一部の Community OpenVPN ビルドには同等の制御がありません。存在しない画面を探す前に、インストールされているメジャーバージョンを確認してください。次にクライアントが何を受け取ったかを確認します。フルトンネルのプロファイルはトンネル経由の既定ルートを設定すべきで、分割トンネルのプロファイルはそうすべきではありません。

トンネルの後でパケットを追う

クライアントがインターネット通信をトンネルへ送ったら、サーバーはそれを転送し、通常は変換する必要があります。Access Server は独自の NAT とルーティングの規則を管理するため、生成されたファイルに Community OpenVPN の規則を追加するのではなく、実際に有効な設定を読んでください。管理されていない規則は次の製品更新で上書きされたり競合したりします。sudo iptables -t nat -L -n -v または nftables の相当するものが、実際に何が変換されているかを示します。

AWS 側は別の経路です。パブリックサブネットのインスタンスはインターネットゲートウェイへ直接到達し、パブリックアドレスまたは弹性 IP を保ちます。プライベートサブネットのインスタンスは NAT ゲートウェイまたは NAT インスタンスへの経路が必要で、NAT デバイスは自身のインターネットゲートウェイへの経路が必要です。インターネットゲートウェイを VPC に接続しても、それだけでプライベートな送信元にパブリックな戻りアドレスが与えられるわけではありません。だから同じ Access Server の設定が一方のサブネットでは動作し、他方では静かに失敗するのです。

インスタンスのサブネットに関連付けられたルートテーブルを確認してください。VPC のメインテーブルだけでは不十分です。サブネットの関連付けはメインテーブルより優先され、古い関連付けは再構築後に動作していた設定が止まる一般的な原因です。

IP の出口と DNS を分けて考える

同じクライアントアプリケーションから、まずアドレスのリテラルを、次に名前を試してください。curl -4 https://checkip.amazonaws.com がパブリックアドレスを返すのにホスト名が失敗するなら、トンネルと NAT 経路は動作しており、問題は DNS です。プッシュされたリゾルバー、クライアントのリゾルバー状態、またはリゾルバーを遮断するセキュリティグループです。Access Server の DNS 設定は同じ Internet Access 領域にありますが、別のコード経路を通ります。

返ってきたアドレスを意図した出口と比較してください。それがインスタンスのパブリックアドレスならインスタンスが変換しており、NAT ゲートウェイのアドレスならプライベートサブネットの経路が使われています。どちらも正しいことがあります。結論できないのは、サーバー上のブラウザーがクライアントの転送を証明するという点です。

一つのチェックボックスで調査を終わらせない

IPv6 は別の判断です。IPv4 のフルトンネルポリシーは、IPv6 が運ばれるのか、遮断されるのか、漏れるのかについて何も述べていません。デュアルスタックのクライアントは IPv4 がトンネル内にある間もローカルの IPv6 経路を使い続けられます。実際に重要なアドレスファミリーを試し、もう一方を無効にすべきかを明示的に決めてください。

最後に、切断状態を試してください。フルトンネルの選択は接続中のルーティングポリシーを表すもので、トンネルが落ちたときに何が起きるかではありません。VPN の外に通信が漏れないことが要件なら、それは kill-switch とファイアウォールの問題であり、ルートテーブルからの推測ではなく独自のテストが必要です。