0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AWS Site-to-Site VPN接続が不安定なときの原因切り分けと対処法

0
Posted at

概要

AWS Site-to-Site VPNの接続が不安定になる原因の多くは、IKE/IPsecの交渉パラメータやトラフィックセレクタの不整合です。本記事では、カスタマーゲートウェイ(CGW)側のログからエラーを特定し、AWS側の要件に合わせて設定を調整する実践的な手順を解説します。

目次

  • Site-to-Site VPNの基本的な仕組み
  • IKEv1とIKEv2の違いと選び方
  • 不整合が起きやすい典型的なパターン
  • トラブルシューティングの実践手順
  • 安定稼働のためのベストプラクティス
  • 終わりに

Site-to-Site VPNの基本的な仕組み

AWS Site-to-Site VPNは、オンプレミス環境とAWS間を暗号化トンネルで接続するサービスです。接続には以下のコンポーネントが関与します。

image.png

登場するコンポーネント

  • カスタマーゲートウェイ(CGW):オンプレミス側のVPN機器
  • 仮想プライベートゲートウェイ(VGW)またはTransit Gateway(TGW):AWS側の終端
  • VPN接続:冗長性確保のため2本のトンネルで構成

ハンドシェイクの流れ

VPN接続の確立は、IKE(Internet Key Exchange)プロトコルによる2段階の交渉で行われます。

フェーズ1(IKE SA確立)

まず、暗号化通信を行うための安全な通信路を確立します。このフェーズでは以下のパラメータを交渉します。

  • 暗号化アルゴリズム(AES-128/256、AES-GCMなど)
  • 整合性アルゴリズム(SHA-1/SHA-2など)
  • Diffie-Hellman(DH)グループ
  • IKEバージョン(v1またはv2)

事前共有鍵(PSK)とIDによる相互認証も、このフェーズで実施されます。

フェーズ2(IPsec/Child SA確立)

次に、実際のデータを暗号化して送るためのSA(Security Association)を確立します。

  • 暗号化・整合性アルゴリズム
  • PFS(Perfect Forward Secrecy)グループ
  • SA有効期間(ライフタイム)
  • トラフィックセレクタ(どのサブネット間の通信を許可するか)

データ転送とルーティング

確立後は、ESP(Encapsulating Security Payload)プロトコルでデータを暗号化して送信します。NAT-Tが有効な場合はUDP/4500ポートを使用します。

DPD(Dead Peer Detection)やKeepaliveで対向装置の生存確認を行い、必要に応じて再交渉します。ルーティングは静的ルートまたはBGPで行い、BGPを使用すると経路障害時の自動フェイルオーバーが可能になります。

IKEv1とIKEv2の違いと選び方

Site-to-Site VPNではIKEv1とIKEv2のどちらかを選択しますが、それぞれで交渉の流れやログに表示される用語、エラーメッセージが異なります。トラブルシューティング時にはこの違いを理解しておくことが重要です。

IKEv1の交渉フロー

IKEv1では2段階のフェーズで接続を確立します。

フェーズ1(ISAKMP/IKE SA確立)

  • Main Mode(6メッセージ交換)またはAggressive Mode(3メッセージ交換)
  • 暗号化、整合性、DHグループ、認証方式を交渉
  • 注意:AWSはAggressive Modeに非対応のため、Main Modeのみ使用可能

フェーズ2(Quick Mode)

  • 3メッセージでIPsec SAを確立
  • ESP暗号化、PFSグループ、ライフタイム、Proxy-ID(トラフィックセレクタ)を交渉

IKEv1の特徴

  • DPD(Dead Peer Detection)は実装依存で、機器によって動作が異なる
  • フラグメント耐性が弱く、MTU問題が発生しやすい
  • 各フェーズのライフタイムが独立して管理される

IKEv2の交渉フロー

IKEv2では、より効率的で堅牢な交渉フローを採用しています。

IKE_SA_INIT

  • SA提案とDiffie-Hellman交換、ノンス交換で基盤を構築
  • 2メッセージで完了

IKE_AUTH

  • IDと認証を実施してIKE SAを確立
  • 同時に最初のCHILD_SAも作成
  • 2メッセージで完了

CREATE_CHILD_SA

  • 追加のCHILD_SAや再鍵交換に使用
  • 1つのIKE SA配下に複数のCHILD_SAを管理可能

IKEv2の特徴

  • NAT-TとDPDが標準で組み込まれている
  • エラー通知が明確(TS_UNACCEPTABLEなど具体的なエラーコード)
  • IKEフラグメンテーション対応で、MTU問題に強い
  • メッセージ往復回数が少なく、接続確立が高速

バージョン別の主な違い

項目 IKEv1 IKEv2
フェーズの呼び方 Phase 1(Main/Aggressive Mode)→ Phase 2(Quick Mode) IKE_SA_INIT → IKE_AUTH → CHILD_SA
トラフィックセレクタ Proxy-ID(Quick Modeで合意) TSi/TSr(CHILD_SAで合意)
典型的なエラー NO_PROPOSAL_CHOSEN(P1/P2)、QM failed、Proxy-ID mismatch NO_PROPOSAL_CHOSEN(IKE/CHILD)、TS_UNACCEPTABLE、AUTHENTICATION_FAILED
再鍵交換 Phase 1/2それぞれのライフタイムで独立に再交渉 IKE SAと各CHILD_SAを独立に再鍵交換(rekey)、必要に応じて再認証(reauth)
NAT-T対応 実装依存 標準組み込み
DPD 実装依存 標準組み込み
フラグメント耐性 弱い 強い(IKEフラグメンテーション対応)
メッセージ効率 低い(6+3メッセージ) 高い(4メッセージ)

バージョン選択のガイドライン

IKEv2を推奨するケース

  • 新規構築時(AWSも基本的にIKEv2を推奨)
  • NAT越えが必要な環境
  • MTU/MSS問題が懸念される環境
  • 接続安定性を重視する場合

IKEv1を選択するケース

  • レガシー機器でIKEv2に対応していない
  • 既存環境でIKEv1が安定稼働しており、移行リスクを避けたい

不整合が起きやすい典型的なパターン

VPN接続が不安定になる原因の多くは、フェーズ1または2での交渉パラメータの不整合です。以下に典型的なパターンと対処法を示します。

IKEバージョンの不一致

症状:フェーズ1でNO_PROPOSAL_CHOSENエラーが発生

対処法:CGW側とAWS側で同じIKEバージョンを使用します。IKEv2の方が再接続時の安定性が高いため、可能であればIKEv2への統一を推奨します。

バージョン別の典型的な不整合パターン

IKEv1とIKEv2では、不整合が発生する箇所とエラーメッセージが異なります。以下にバージョン別の典型パターンを示します。

IKEv1で多い不整合

Phase 1提案のミスマッチ

  • 症状:NO_PROPOSAL_CHOSENエラー(Phase 1で発生)
  • 対処法:暗号化、整合性、DHグループの組み合わせをAWS推奨セットに含める
    • 暗号化:AES-128/256
    • 整合性:SHA-2系
    • DHグループ:14/16/19

Proxy-IDの不一致

  • 症状:Quick Mode(Phase 2)でProxy-ID mismatchエラー
  • 対処法:
    • ルートベースVPN:0.0.0.0/0対0.0.0.0/0など広いセレクタを許容
    • ポリシーベースVPN:VPC CIDRとオンプレミスCIDRの全組み合わせを明示的に設定

Aggressive Modeの使用

  • 症状:Phase 1で接続が確立できない
  • 対処法:AWSはAggressive Modeに非対応のため、Main Modeに変更

IKEv2で多い不整合

TS_UNACCEPTABLE(トラフィックセレクタ不一致)

  • 症状:CHILD_SA確立時にTS_UNACCEPTABLEエラー
  • 対処法:TSi/TSrの範囲を調整
    • ルートベースVPN:広めのセレクタを設定
    • ポリシーベースVPN:実際のトラフィックに合わせて正確に設定

CHILD_SAの暗号・PFS・ライフタイム不一致

  • 症状:CREATE_CHILD_SAでNO_PROPOSAL_CHOSENエラー
  • 対処法:CHILD_SAの提案にAWSがサポートする複数の組み合わせを許容設定として追加。ライフタイムは両側で近い値に設定

再鍵交換の衝突

  • 症状:定期的にCHILD_SAが切断と再接続を繰り返す
  • 対処法:再鍵マージン、リトライ設定、DPDタイマーを見直し。どちら側がイニシエータになるか方針を決めると安定性が向上

フェーズ1の暗号・整合性・DHグループの不一致

症状:フェーズ1(IKEv1)またはIKE_SA_INIT(IKEv2)でNO_PROPOSAL_CHOSENエラー

対処法:CGW側のプロポーザルに、AWSがサポートする複数の組み合わせを許容設定として追加します。推奨設定は以下の通りです。

  • 暗号化:AES-256またはAES-128
  • 整合性:SHA-2系(SHA-256以上)
  • DHグループ:14/16/19(Group 2は非推奨)

フェーズ2の暗号スイート・PFS・ライフタイムの不一致

症状:フェーズ2でTS_UNACCEPTABLEやNO_PROPOSAL_CHOSENエラー、頻繁な再送

対処法:フェーズ2の設定をAWSの要件に合わせます。

パラメータ AWS推奨値 注意点
暗号化 AES-256/128 GCMモードも使用可能
整合性 SHA-2系 SHA-1は非推奨
PFSグループ 14/16/19 Group 2は避ける
ライフタイム 3600秒(1時間) 極端に短いと再交渉が頻発

片側だけライフタイムが極端に短いと、再交渉が頻発して接続が不安定になります。

トラフィックセレクタ(Proxy-ID)の不一致

症状:フェーズ2が確立できない、特定のサブネット間だけ通信できない

対処法:VPN機器のタイプに応じた設定が必要です。

  • ルートベースVPN:0.0.0.0/0対0.0.0.0/0など広いセレクタを許容
  • ポリシーベースVPN:VPC CIDRとオンプレミスCIDRの全組み合わせを明示的に設定

可能であれば、VTI(Virtual Tunnel Interface)を使用してルートベースVPNに統一すると、トラフィックセレクタの管理が簡単になります。

認証情報の不一致

症状:AUTHENTICATION_FAILEDエラー

対処法

  • 事前共有鍵(PSK)が両側で一致しているか確認
  • IDタイプ(IPアドレス/FQDN)がAWS側の期待と合っているか確認
  • NAT越えの場合、IDの扱いに特に注意

DPD・再鍵交換の衝突

症状:定期的に切断と再接続が発生、BGPセッションも断続的にダウン

対処法

  • DPDタイマーと再鍵交換のマージン・リトライ設定を見直す
  • どちら側がイニシエータになるかの方針を決め、同時交渉を避ける設定にする

MTU・MSSの問題

症状:小さいパケットは通るが、大きいパケットだけ落ちる。TCPセッションが不安定

対処法

  • トンネルインターフェースでTCP MSS clampingを設定(推奨値:1350〜1400バイト)
  • PMTUDを有効化
  • Path MTU Discoveryで実際の最大パケットサイズを測定して調整

トラブルシューティングの実践手順

VPN接続の問題を効率的に解決するには、以下の順序で調査を進めます。

1. CGW側のログ取得と分析

まず、カスタマーゲートウェイ側でIKE/IPsecのデバッグログを取得します。AWS側のCloudWatchメトリクスではトンネルの状態しか見えませんが、CGW側ログでは交渉の詳細を確認できます。

ログから以下を特定します。

  • 失敗したフェーズ(IKEv1:Phase 1/2、IKEv2:IKE_SA_INIT/IKE_AUTH/CREATE_CHILD_SA)
  • エラーコード(NO_PROPOSAL_CHOSEN、TS_UNACCEPTABLE、AUTHENTICATION_FAILEDなど)
  • 提案された暗号スイートと拒否理由

バージョン別のログ確認ポイント

IKEv1の場合:

  • Phase 1のMain Modeで失敗している場合、暗号化・整合性・DHグループの不一致を疑う
  • Phase 2のQuick Modeで失敗している場合、Proxy-IDやESP暗号スイートの不一致を疑う

IKEv2の場合:

  • IKE_SA_INITで失敗している場合、暗号化提案やDHグループの不一致を疑う
  • IKE_AUTHで失敗している場合、認証情報(PSK、IDタイプ)の問題を疑う
  • CREATE_CHILD_SAでTS_UNACCEPTABLEが出ている場合、トラフィックセレクタの範囲を確認

2. AWS側設定の最新化

AWSマネジメントコンソールから、VPN接続の設定ファイルを再ダウンロードします。

重要なポイント:

  • CGW機器のベンダー、モデル、OSバージョンを正確に選択
  • トンネルオプション(IKEバージョン、DPD間隔、再鍵マージンなど)がカスタマイズされている場合は記録

AWS公式の『What is AWS Site-to-Site VPN?』 ( https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html ) では、各ベンダー向けのサンプル設定が提供されています。

3. CGW側設定の調整

ログで特定した不整合点を解消するため、CGW側の設定を調整します。

調整のコツ

  • IKE/ESPプロポーザルは複数の候補を許容する設定にする(最強設定1つだけに絞らない)
  • フェーズ1/2(IKEv1)またはIKE SA/CHILD SA(IKEv2)のライフタイムをAWS推奨値に合わせる
  • PFSグループをAWS側で受け入れ可能なグループに設定
  • トラフィックセレクタはVPN機器のタイプとIKEバージョンに応じて適切に設定
    • IKEv1:Proxy-IDを正確に設定
    • IKEv2:TSi/TSrの範囲を適切に設定
  • PSKとIDを再確認
  • NAT-TとMSS調整を有効化

バージョン別の設定チェックリスト

IKEv1の場合:

  1. Main Modeを使用しているか確認(Aggressive Modeは不可)
  2. Phase 1とPhase 2のライフタイムが適切か確認
  3. Proxy-IDがVPC CIDRとオンプレミスCIDRの組み合わせを網羅しているか確認

IKEv2の場合:

  1. IKE SAとCHILD SAのライフタイムが適切か確認
  2. TSi/TSrの範囲が実際のトラフィックをカバーしているか確認
  3. DPDとNAT-Tが有効になっているか確認(IKEv2では標準機能だが、明示的な設定が必要な場合あり)

4. 段階的な検証

設定変更後、以下の手順で検証します。

  1. まず1本目のトンネルを確立し、CloudWatchメトリクス(TunnelState)とCGWログを照合
  2. トンネル確立後、疎通テストを実施(ping、tracerouteなど)
  3. BGP使用時はピアリングと経路伝搬を確認
  4. 問題なければ2本目のトンネルも同様に確認
  5. 負荷テストや大きいパケットでの通信も検証

5. さらなる最適化

それでも不安定な場合は、以下を検討します。

  • VPN接続のトンネルオプションを見直して再作成
  • TGWとVGWのどちらを終端にするか再検討(TGWの方が多対多接続に強い)
  • ポリシーベースVPNからルートベースVPNへの移行
  • AWS Direct Connectとの組み合わせ(VPN over Direct Connect)

安定稼働のためのベストプラクティス

設計段階

  • IKEv2の採用:IKEv1より再接続が安定
  • BGPの利用:経路障害時の自動フェイルオーバーが可能
  • ルートベースVPNの選択:トラフィックセレクタの管理が容易

運用段階

  • 定期的な疎通監視:CloudWatch Alarmsでトンネル状態を監視
  • ログの定期確認:CGW側のログで再交渉の頻度や失敗パターンを把握
  • 設定のバックアップ:CGW設定とAWS設定ファイルをバージョン管理
  • 変更管理:AWS側・CGW側ともに設定変更時は事前テストを実施

セキュリティ

  • 強力な暗号スイートの使用:AES-256とSHA-2系の組み合わせ
  • PSKの定期変更:少なくとも年1回は更新
  • DH Group 2の回避:セキュリティ上のリスクがあるため非推奨

料金最適化

2025年12月時点、AWS Site-to-Site VPNの料金はap-northeast-1(東京リージョン)で以下の通りです。

  • VPN接続料金:0.048 USD/時間(約3.5 USD/月)
  • データ転送料金:0.09 USD/GB(AWS→インターネット)

データ転送量が多い場合は、AWS Direct Connectとの併用も検討してください。料金は変動する可能性があるため、最新情報は『AWS VPN Pricing』 ( https://aws.amazon.com/vpn/pricing/ ) で確認してください。

終わりに

AWS Site-to-Site VPNの接続問題の多くは、IKE/IPsecの交渉パラメータ不整合が原因です。トラブルシューティングの第一歩は、CGW側のログで具体的なエラーを特定し、AWS側の要件に合わせて設定を調整することです。

特に重要なのは、プロポーザルを複数許容する設定にすること、ライフタイムを適切に設定すること、トラフィックセレクタをVPN機器のタイプに合わせることの3点です。また、IKEv1とIKEv2では交渉フローやエラーメッセージが異なるため、使用しているバージョンに応じた対処が必要です。

これらを押さえれば、多くの接続問題は解決できます。次のステップとして、BGPによる動的ルーティングの導入や、TGWを使った複数VPC・オンプレミス間のハブアンドスポーク構成への拡張も検討してみてください。

参考文献・参考サイト

本文中で引用したURL:

その他の参考資料:

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?