AWS VPN の PSK をローテーションする:どちらのトンネルが落ち、いつか
AWS VPN トンネルの事前共有キーを 1 つ変更すると、両端が合意するまでそのトンネルは落ちます。まず代替経路を証明し、その後で 1 本ずつローテーションします。
両端が事前共有キーについて食い違った瞬間にトンネルは落ち、両側が新しい値を持つのを待って落ちたままになります。この部分は想定内で、AWS は変更を選択したトンネルの中断として扱い、キーが異なる間はピアが IKE を完了しません。人々を驚かせるのは後半です。もう一方のトンネルは、運べることを確認していない限り、自分からトラフィックを引き受けることはありません。この順序でローテーションすれば、中断は一本のトンネル内に収まります。
キーが変わると実際に何が起きるか
ModifyVpnTunnelOptions は、外向き IP アドレスで識別される一本のトンネルのオプションを書き換えます。トンネルは破棄されて再構築されるため、IKE と IPsec は新しいキーでゼロから交渉します。AWS は中断が数分続く可能性があるとしており、ルーティングプロトコルが気づくには十分な長さです。同じ接続のもう一方のトンネルは、この呼び出しの影響を受けません。
何かを送る前に知っておくべき二つ目の影響があります。変更操作はトンネルオプションの全体を受け取るため、省略したフィールドは既定値で書き戻されます。フェーズ 1 やフェーズ 2 の有効期間、あるいはデッドピア検出の設定を調整していた場合は、現在の値を同じリクエストで渡すか、後で復元する計画を立ててください。
まず現在の値を読み、次にひとつのフィールドだけを変更します。この順序がこの作業の規律そのものです。
まず AWS のトンネルを正しいピアに一致させる
コンソールはトンネルを順番でラベル付けしますが、お使いのデバイスはそのラベルを使いません。外向き IP アドレスでトンネルを識別し、カスタマーゲートウェイのピア設定と突き合わせてください。ローカル設定のトンネル 1 は、AWS がトンネル 1 と呼ぶトンネルを編集している証拠にはなりません。
接続そのものから始め、両方のトンネルと、それぞれが現在保持しているキーを一覧します:
aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
--query "VpnConnections[0].Options.TunnelOptions[].[OutsideIpAddress,PreSharedKey]"返ってくるキーが現在使用中のキーなので、何かを変更する前にピア設定と比較してください。既に存在する不一致は、そもそも安定したことのないトンネルを説明します。
まずもう一方のトンネルにトラフィックを運ばせる
ひとつの接続に二本のトンネルがあることは、デバイスが両方を設定していること、両方が必要なプレフィックスを広告していること、トラフィックが両者の間を流れることを証明しません。代替トンネルのネゴシエーション、そのルート、双方向の実際のアプリケーションフローを確認してください。BGP では、ライブな隣接関係は有用な証拠ですが、プレフィックスの確認と同じではありません。静的ルーティングでは、ゲートウェイが経路をどう選び、優先経路が消えたときに何をするかを確認してください。
代替がワークロードを運べない場合は、キーに触れる前に中断を計画するか、代替トンネルを修理してください。コンソールページのステータスランプは、無停止サービスを約束するものではありません。
一本のトンネルをローテーションし、実際のトラフィックで検証する
代替経路が証明できたら、手順は短いです。トンネルのアドレス、そのピア、秘密でない設定を記録し、これから壊すトンネルに依存しない管理経路をゲートウェイに対して確保してください。
- 選択した外向きアドレスについてカスタマーゲートウェイのピアを更新するか、API 呼び出しの数秒後に反映されるよう変更を準備します。
- 新しいキーに現在の有効期間と DPD 値を加えて、変更呼び出しを送ります。
- IKE と IPsec が戻るのを待ち、その後にルートと必要なプレフィックスを確認します。
- そのトンネルに代表的なアプリケーションフローを通し、両方向を監視します。
両端が食い違い、AWS が変更を適用している間はトンネルを使えないため、ピアの更新は昼食後ではなく即座に続ける必要があります。変更したトンネルが実際のトラフィックを運んで初めて、もう一方で同じ手順を繰り返してください。
最初のトンネルの後も復旧やルーティングが不確かなら止めてください。半分しか動かない二本のトンネルは、動くと分かっている一本より悪いです。
復旧が行き詰まったら IKE 側を読む
両端が新しいキーを持った後も落ちたままのトンネルは、通常ローテーションが露呈させたポリシーの不一致であり、作り出したものではありません。提案、ピアが送る識別情報、トラフィックセレクタはすべて AWS 側と一致している必要があり、確立済みのトンネルを生き延びた値でも新しいネゴシエーションでは拒否されることがあります。キーを 二度目に変更する前に、ネゴシエーションの状態とそれに付随するメッセージを読んでください。
aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
--query "VpnConnections[0].VgwTelemetry[].[OutsideIpAddress,Status,StatusMessage]"変更を取り消す必要がある場合でも、以前に動いていたという理由だけで古いキーを戻さないでください。漏えいしたキーは漏えいしたものとして扱い、代わりにネゴシエーションを直します。両方のトンネルを検証し、各ピアがどの値を持つかを記録するようシークレット台帳を更新して終え、AWS のトンネルオプションのドキュメントをランブックのそばに置いてください。