EC2 上の strongSwan：VPC にワークロードをルーティングさせる

トンネルは上がっており、ゲートウェイインスタンスはリモートネットワークに ping できるのに、隣のアプリケーションインスタンスは何にも届かない。壊れているわけではない。成功したテストは VPN ホストで始まったもので、そのホストが同じ IPsec 関係を通して別の送信元アドレスを運べるかは一度も問われていない。この手順書は、各失敗が見える順序で、その隙間を四つの手順で塞ぐ。

まず四つのアドレスを書き出す

以下の各手順はこれを参照するので、ルートテーブルに触る前に自分のアカウント用に埋めておく。

VPC:             10.60.0.0/16
Gateway subnet:  10.60.1.0/24, gateway ENI address 10.60.1.10
Workload subnet: 10.60.2.0/24, application address 10.60.2.20
Remote network:  10.90.0.0/24

例は、承認済みで稼働しているポリシーベースの IPsec 接続と、送信元を保持するフローを前提とする。これは一つの割り当てアドレスを借りる NAT 越しのリモートアクセスクライアントではなく、その違いがセレクタを変える必要があるかどうかを決める。

手順 1：ワークロードのサブネットにルートを与える

ワークロードのサブネットに実際に関連付けられているルートテーブルには、リモートプレフィックス宛てにゲートウェイのネットワークインターフェイスを指す経路が必要である。インスタンス内にインストールしたゲストルートはその AWS ルートテーブルのエントリではなく、どれだけ strongSwan を設定しても作られない。

AWS のアプライアンス経由のルーティングの指針は、ネットワークインターフェイス型のターゲットと、転送するインスタンスの送信元/送信先チェックの要件を説明している。そのチェック変更はゲートウェイの役割に限定し、通常のアプリケーションインスタンスはそのままにしておく。

承認済みの一つのネットワークのために、VPC のローカルルートや既存のエントリを置き換えてはいけない。関連付けと有効状態を確認するのであり、誰も使っていないルートテーブルについてコンソール画面が何を表示するかではない。似て見える二つのテーブルでも関連付けは異なりうる。重要なのはワークロードのサブネットが関連付けられているテーブルだ。

手順 2：ゲストで転送を有効にする

sysctl -w net.ipv4.ip_forward=1
# persist in /etc/sysctl.d/ and re-apply after reboot

カーネルは転送し、ホストのファイアウォールは通過を許可しなければならない。すべてを許可するのではなく、ワークロードとリモートのプレフィックス向けに意図した転送ルールを追加し、ゲートウェイのサブネットが自分のトラフィック用に使える転送経路を保つことを確認する。

この手順がつまずくのはセキュリティグループであることが多い。中間装置はインスタンス間の直接通信におけるセキュリティグループ参照の挙動を継承しないため、マネージド Client VPN の例からコピーしたルールは決して一致しないことがある。実際の経路で、両方向のセキュリティグループとサブネット ACL を確認する。

手順 3：セレクタを実際の送信元まで広げる

AWS 側で 10.60.1.10/32 だけを対象にしたポリシーは、10.60.2.20 を対象にしないまま、ゲートウェイ発の成功を説明してしまう。リモート宛てのルートはトラフィックセレクタを広げない——これが同じ驚きの後半である。

swanctl --list-sas
# read the installed CHILD-SA local and remote traffic selectors

合意した設計が VPC 全体を保護するなら両側が 10.60.0.0/16 と 10.90.0.0/24 を受け入れる必要があり、一つのワークロードだけを保護するなら、その狭いプレフィックスを意図的に使う。いずれの場合も、インストール済みの CHILD-SA ポリシーを確認する。あなたが編集した設定と、別の形で狭めた相手側は同じ合意ではない。

リモートサイトも、保持された VPC 送信元への応答を意図した IPsec ゲートウェイ経由で戻す必要があり、他の送信元 NAT ルールがある場所では保護対象トラフィックに対するサポートされた NAT 除外を維持する。未承認のワークロードを許可済みのホストアドレスに変換するのは別のアイデンティティ契約であり、望んだアクセスへの近道ではない。

手順 4：検証し、必要なら切り戻す

ワークロード自身から、新しく許可されたアプリケーション操作で試し、除外されるべき宛先でも繰り返す。リモートサービスが見る送信元アドレスと、それが使う戻り経路を記録する。ゲートウェイへの ping や緑の IKE ステータスはそのテストではない。

ゲートウェイが動いているのにワークロードが失敗し続けるなら、手順を順に逆にたどる：セレクタ、次に転送とセキュリティグループ、次に関連付けられたルートテーブルだ。それぞれ症状が異なり、当て推量は本当に誤っている一つを飛ばしてしまう。

切り戻しは同じ順序を逆にする。ワークロードのサブネットのルートは、以前のセレクタを戻したうえで最後に外し、送信元を保護しなくなったゲートウェイを指すサブネットを残さない。これらの契約が成り立つとき、セルフホスティングはゲートウェイホスト以上のものを担え、AWS マネージドの Site-to-Site VPN は別の運用モデルで、strongSwan が顧客ゲートウェイ側に置かれることもある。