AWS に Site-to-Site VPN トンネルを開始させる方法
起動アクションと DPD タイムアウトアクションは別の問いに答えます。AWS に開始させる方を設定し、その後でピアのアドレスとアプリのルートを確認します。
既定では、AWS Site-to-Site VPN は customer gateway がネゴシエーションを開始するのを待ちます。その既定は設定であって法則ではなく、設定の名前は Startup action です。それに手を伸ばす前に、よく混同される二つの問いを分けてください。トンネルを確立するのは誰か、そして気にしているパケットにその中を通るルートがあるかどうかです。トンネルのオプションにあるのは前者だけです。
起動アクションと DPD タイムアウトアクションを分ける
トンネルごとの二つのオプションは二つの異なるイベントを制御し、一方を設定しても他方については何も言えません。
| Event | Option | Useful values |
|---|---|---|
| A new or modified VPN connection needs a tunnel | Startup action | add waits for the peer; start asks AWS to initiate |
| Dead peer detection times out | DPD timeout action | clear ends the session, restart reinitiates, none does nothing |
AWS が新規または変更されたトンネルを立ち上げるべきなら、次を選びます: start。DPD タイムアウト後にネゴシエーションも再開すべきなら、そのイベント用に別途 restart を構成します。どちらのオプションもアプリの再試行ポリシーではなく、どちらも鍵更新の間隔ではありません。DPD はピアが生きているかを確認し、鍵更新は稼働中のトンネルで security associations を置き換えます。
トンネルがまだ up と報告しているのにタイムアウトするアプリは、データパスの問題を抱えています。DPD タイマーを短くしても直りませんし、後で説明が必要な混乱を増やすこともあります。
AWS にネゴシエーションを送る先があるか確認する
AWS 側からの開始は IKEv2 でのみ可能で、AWS は提案をどこへ送るか知るために customer gateway のパブリックアドレスを必要とします。痛いのは、アドレスなしで作成された証明書認証の customer gateway リソースです。AWS のドキュメントは、アドレス付きで新しい customer gateway リソースを作成し、その後 VPN 接続をそちらへ向けるよう変更する手順を説明しています。
証明書はピアが誰かを証明します。ピアがどこにいるかは AWS に伝えません。これは別の要件です。だから対処は新しい証明書ではなく、新しい customer gateway リソースです。証明書を差し替えても、AWS には同じ欠けた宛先が残るだけです。
customer gateway が NAT の背後にある場合、AWS には構成済みの responder identity も必要です。 IDr、ピアの ID がデバイスの期待と一致するようにするためです。変えたばかりのオプションを責める前に、その値と IKE トラフィックを通すファイアウォール経路を確認してください。 start を選んでも、到達できない、あるいは誤って識別されたピアに提案を受け入れさせることはできません。
変更を一つのトンネルに適用し、中断を想定する
VPN 接続には独立したオプションを持つ二つのトンネルがあるので、外部アドレスでどちらを編集しているか確認します。AWS は一度に一つのトンネルしか変更できず、選択したトンネル上の接続は数分間中断することがあります。
- Site-to-Site VPN 接続を選び、Modify VPN tunnel options を開きます。
- 外部 IP アドレスでトンネルを選び、その IKE バージョンと customer gateway リソースを確認します。
- 本当に望む起動と DPD のアクションを設定し、自分で管理できる時間帯に保存します。
- 変更したトンネルが確立することを確認し、次の変更の前に他方のトンネルとルーティングを確認します。
保守の前に一つ注意すべき挙動があります。AWS の開始を有効にするとタイムアウトはありません。AWS はトンネルが上がるまで試し続け、customer gateway が delete-SA メッセージを送ると再開します。ピアを意図的に落とすと、AWS は叩き続け、ピアのログにそれが残ります。
トンネルの状態だけでなく、アプリの経路を検証する
up と報告するトンネルは、機能するリクエストと同じではありません。VPC に接続した Lambda 関数には、顧客プレフィックスへの subnet ルート、トラフィックを許可する security group と network ACL のルール、正しいアドレスを返す名前解決、そして 顧客側の戻り経路が依然として必要です。
アプリのコンテキストから実際のリクエストで一度試し、失敗したら flow logs を読みます。AWS の開始が切られていてアイドルのトンネルがパケットを必要とするとき、keepalive トラフィックは正当な選択肢ですが、名前を挙げられる監視上の判断であるべきで、関数にボルト止めされた説明のない ping ループではありません。
まず誰がトンネルを確立するかを選び、そのうえで残りの失敗をその層で診断します。 AWS の開始に関するドキュメント は、アドレス、ID、再試行の要件をコンソールのヒントより詳しく扱っています。