EC2 の Elastic IP はインスタンスのプライベート VPN アドレスではない

インスタンスにはプライベートアドレスがあり、Elastic IP はそれに関連付けられ、そのパブリック /32 へのルートが、両者が同じものになることを期待して VPN に追加されます。しかし同じにはなりません。Elastic IP はゲストの外側で、インターネットゲートウェイによって、インターネット経路を通るトラフィックに対して行われる変換です。ゲストのオペレーティングシステムは、そのアドレスがインターフェイスに設定されているのを決して見ません。トンネルインターフェイスに追加しても上流の変換は再現されず、同じマシンに二つ目の矛盾した同一性を作り出すだけです。

二つのアドレス、一つのインスタンス

インスタンスのネットワークインターフェイスは VPC 内のプライベートアドレスを保持しており、それがゲストの知っているアドレスです。Elastic IP は同じインターフェイスに関連付けられていますが、マッピングのパブリック側に存在します。

インターネット経由でインスタンスに届くものはすべて、プライベートアドレスに変換されて到着します。インスタンスがインターネットへ送るものはすべて、Elastic IP を送信元として出ていきます。これも同じ変換によるものです。

ゲストの内側には一つのアドレスしかありません。外側には二つあります。この非対称性が、この分野の混乱のほとんどを説明します。ゲストはゲートウェイが何を変換するかを設定できません。実際に保持しているアドレスでしか応答できません。

インターネットゲートウェイが実際に行うこと

AWS の インターネットゲートウェイに関するドキュメント は、その配置を説明しています。インスタンスは自身のプライベート IPv4 アドレスを認識しており、ゲートウェイがインターネット経路のトラフィックに対して対応するパブリック IPv4 または Elastic IP への変換を提供します。

これはネットワークアドレス変換であり、エイリアスではありません。マッピングはゲートウェイが維持し、関連付けに結び付き、それを通過するパケットにのみ適用されます。関連付けを外せば、ゲストが何も気づかないままパブリックな同一性は消えます。

そのため、パブリック /32 宛てのプライベート VPN パケットが、ゲストのローカルアドレス宛てのプライベートパケットとして再解釈されることはありません。パケットは一致するルートに従い、そのルートがパケットをインターネットゲートウェイへ送ります。ゲートウェイの動作は、経路が双方向で許可されているかどうかに依存します。

トンネルインターフェイスの手法が失敗する理由

Elastic IP をトンネルインターフェイスに割り当てると、ゲストはパブリックアドレスをローカルなものとして扱うよう求められます。すると同じアドレスを二つのものが主張します。インターネット経路上のゲートウェイの変換と、トンネル内のローカルインターフェイスです。戻りトラフィックには、どちらが適用されるかという一貫した答えがありません。

動作しているように見える場合でも、設計は本当の問いを隠しています。クライアントはトンネル経由でプライベートアドレスに到達するか、インターネット経由でパブリックエンドポイントに到達するかのどちらかであり、二つの経路はセキュリティグループ、ログ、障害の種類が異なります。

問題はアドレスではありませんでした。経路の選択でした。

三つの目的、三つの設計

目的がパブリックな VPN エンドポイントであれば、Elastic IP が適切な道具です。リモートピアはインターネット経由で接続し、暗号化されたトランスポートはインスタンスで終端します。その後、内部のアプリケーショントラフィックはプライベートアドレスを使います。

目的がアプリケーションへのプライベートなアクセスであれば、宛先はプライベートアドレスか、そこへ解決するプライベート DNS 名であり、VPN ルート、セキュリティグループ、戻り経路のすべてが一致している必要があります。その設計に Elastic IP はまったく登場しません。

目的が VPN ユーザーに対する安定したパブリックな出口の同一性であれば、それは出口側の NAT 設計であり、クライアントのトンネル上のアドレスではありません。似て聞こえる三つの目的は三つの異なる図を生み、そのうち Elastic IP を新しい場所に置くのは一つだけです。

選んだ経路を検証する

プライベートアクセスの場合、VPN ルートがプライベートプレフィックスを覆っていること、VPC のルートテーブルがトラフィックをトンネルへ戻すこと、セキュリティグループがクライアントの送信元を許可すること、クライアント自身のファイアウォールが応答を許可することを確認します。そのうえで、ping ではなく実際のリクエストを一つ試します。

パブリックアクセスの場合、クライアントのインターネット出口、パブリックな入口のルーティングとそのセキュリティポリシーを確認します。VPN クライアントがトンネル経由でパブリックエンドポイントに到達できるかは、トンネルの出口とファイアウォールの規則に依存し、Elastic IP の関連付けには依存しません。

パブリックなホスト名を両側から機能させる必要がある場合は、VPN クライアントにはプライベートアドレスを、それ以外のすべてにはパブリックアドレスを返す DNS 設計を使い、証明書はアドレスではなく名前に有効なままにします。作業の順序は、目的に名前を付け、それに属するアドレスを選び、ルート、ポリシー、一つのリクエストを検証する、です。