strongSwan から AWS Site-to-Site へ: Child SA が何も選択しない理由

IKE トンネルが上がっていても、子アソシエーションがサブネットを除外していれば通信は通りません。まず AWS のローカル CIDR とリモート CIDR を leftsubnet と rightsubnet と比較してください。

コンソールは up を示し、strongSwan は確立した IKE アソシエーションを報告しているのに、パケットは届きません。次に比較すべきは事前共有鍵ではなく、両側がトンネルに守られていると信じているプレフィックスの組です。最初の二つが、トンネルがそもそも通信を運べるかどうかを決めるため、以下の確認を順番に進めてください。

AWS の呼び方を strongSwan の用語に置き換える

AWS は顧客側から接続を説明し、カスタマーゲートウェイのアドレスとローカル CIDR はあなたの側に、リモート CIDR は VPC に属します。strongSwan は両端を left と right と呼び、あなたのプレフィックスは leftsubnet に、VPC のプレフィックスは rightsubnet に入ります。片方の組を逆にすると、間違った通信を交渉して選択するトンネルになります。

AWS が接続用に生成する設定をダウンロードし、トンネルのアドレスとプレフィックスも含めてその接続だけの基準として扱ってください。作成時に CIDR の両方の欄を空にすると、サービスは各側で既定の 0.0.0.0/0 を使います。狭いプレフィックスで設定されたルーターはそれに決して一致しないため、欄を埋めるか、セレクターを意図的に広げてください。

ここでの不一致はルーティング障害のように見えますが、そうではありません。

AWS が実際に見ているアドレスを固定する

NAT の背後にあるルーターは、相手側が一度も知らないインターフェースから IKE を送信することがあります。AWS に記録されるゲートウェイアドレスは、AWS が回線上で観測するものと同じでなければならず、ルーターは既定ルートに従うのではなく同じローカルアドレスに固定する必要があります。

conn %default
    local_addrs = 203.0.113.10

strongSwan では local_addrs が IKE の送信元アドレスを選び、古い OpenSwan の設定は同じ考えを left と書きます。公開アドレスを持つインターフェースに向け、以前のルーターから残ったルールが黙って捨ててしまうため、次に NAT 機器そのもので UDP 500 と 4500 がそのホストに届くことを確認してください。正しいセレクターの組でも送信元アドレスが違えば失敗し、ログは提案のせいにします。その誤誘導こそ、送信元アドレスに独自の確認が必要な理由です。

前のルーターに正しかったルールはよく残るため、転送ルールは当然とみなさず確認してください。

フェーズ 1 とフェーズ 2 を分けて扱う

AWS は IKE と ESP のオプションを別々の一覧として示します。二つの一覧は独立しているため、両側が受け入れる IKE スイートは ESP の提案について何も語りません。生成された設定から両方を読み、一つずつ比較してください。

conn aws
    ike = aes256-sha1-modp1024
    esp = aes256gcm16

構文は実装間をまたぎません。OpenSwan で動く組、たとえば phase2alg=aes_gcm と ike=aes256-sha1;modp1024 は、strongSwan の esp= と ike= の形に訳す必要があり、アルゴリズム名も異なります。GCM は暗号化しながら認証するため、SHA と組み合わせた CBC スイートと違い、別個の整合性変換を必要としません。翻訳せずに一方のデーモンから他方へ貼り付けたフェーズ 2 の行は、セレクターの不一致のように読める拒否を生みます。

トンネルの表示ではなく子アソシエーションを確認する

接続は読み込まれるのに子アソシエーションが上がらない場合、提案かセレクターのどちらかが拒否されています。子が上がってもそのセレクターがあなたのプレフィックスを除外していれば、パケットはトンネルに届く前にフィルターされます。コンソールの表示は IKE 層しか覆わないため、どちらが起きたかは分かりません。

ipsec statusall

子のセキュリティアソシエーションを探し、その横に表示されるトラフィックセレクターを読み、生成された設定のプレフィックスと比較してください。

ローカルプレフィックス内のホストから VPC プレフィックス内のホストへ試し、戻り経路と AWS 側のセキュリティグループやネットワーク ACL も確認してください。正しいセレクターは、後からパケットが捨てられることを防ぎません。

セレクターが一致しても失敗し続ける場合

両側のルートがトンネルを指していることを確認し、次に NAT 機器がポリシーの想定しない形で通信を書き換えていないことを確認してください。ポリシーベースのトンネルはパケットのアドレスで照合するため、ポリシー判定の後に適用される変換は結果を変えます。

別の提案を変える前に、両側で受信と送信のパケットを一つずつ記録してください。

チケットに セレクター、フェーズ 1 とフェーズ 2 の提案、送信元アドレス を記録してください。これら四つの値で、電話なしに大半の site-to-site 障害を説明できます。

関連記事