VPN Gateway:VPN ゲートウェイのルート設定

静的ルートと BGP ルートの比較

静的ルート：宛先ベースとポリシーベースの比較

宛先ベースルートとポリシーベースルートから選択します。

ルートの優先度

VPN ゲートウェイは、次の順序でトラフィックとルートを照合します：

1. ゲートウェイはまず ポリシーベースルーティング を確認し、最長プレフィックス一致ルールではなく、ポリシー優先度によってルートを照合します。

2. 次に、ゲートウェイは 宛先ベースルーティング を確認し、最長プレフィックス一致ルールによってルートを照合します。

3. 最後に、ゲートウェイは BGP ルートテーブル を確認します。

エンドツーエンドの概要

VPN ゲートウェイを介して VPC をデータセンターに接続するには、3 つのルートテーブルが関係します：

宛先ベースルートの設定

宛先ベースルートは、宛先 IP アドレスに基づいてトラフィックを転送します。

照合ルール：

• 最長プレフィックス一致： トラフィックは、サブネットマスクが最も長いルートに一致します。たとえば、10.0.0.0/8 と 10.10.0.0/16 の両方のルートが存在する場合、10.10.10.1 宛のトラフィックは 10.10.0.0/16 ルートに一致します。

• アクティブ/スタンバイルート (レガシーのシングルトンネル VPN ゲートウェイのみ)： アクティブルートのみが照合され、スタンバイルートはスキップされます。詳細については、「アクティブ/スタンバイルートの設定」をご参照ください。

ポリシーベースルートの設定

ポリシーベースルートは、送信元 IP アドレスと宛先 IP アドレスの両方でトラフィックを照合し、宛先ベースルートや BGP ルートよりも優先されます。

照合順序：

1. ポリシー優先度： 優先度の値が最も低いルートが最初に照合されます。

2. 同じ優先度のルート： 作成時間順に照合されます。最初に一致したものが使用されます。

VPC ルートテーブルへのアドバタイズ

ポリシールートと宛先ルートが作成された後、デフォルトでは VPC ルートテーブルに 未公開 の状態になっています。手動で追加したルートを、VPC ルートテーブルで手動でルートを追加することなく、直接 VPC システムルートテーブルに公開できます。

• ルートは VPC システムルートテーブルにのみ公開され、カスタムルートテーブルには公開されません。カスタムルートテーブルにルートを追加するには、「ルートエントリの追加と削除」をご参照ください。

• ポリシーベースルートテーブルと宛先ベースルートテーブルの両方に同じ宛先 CIDR ブロックを持つルートが存在する場合、一方のテーブルからルートを取り消すと、もう一方のテーブルからも取り消されます。

• 公開するルートと同じ宛先 CIDR ブロックを持つが、異なるネクストホップを持つルートエントリが VPC ルートテーブルにすでに存在する場合 (たとえば、ピアリング接続や NAT ゲートウェイを指している場合)、公開時にシステムはルートの競合 (重複ルート) をプロンプト表示します。ビジネス要件を評価した後、競合するルートを削除するか、CIDR ブロックの計画を調整し、競合が解決されたら再度公開操作を実行してください。詳細については、「重複ルートエラーの処理」をご参照ください。

制限事項

これらの制限は、宛先ベースルートとポリシーベースルートの両方に適用されます：

• 宛先 CIDR ブロックが 0.0.0.0/0 のルートは追加できません。

• 100.64.0.0/10 (サブネットおよびスーパーネットを含む) へのルートを追加しないでください。これにより、IPsec 接続またはネゴシエーションの失敗が発生します。

• システムがルートの競合を報告した場合は、「重複ルートエラーの処理」をご参照ください。

エンドツーエンドの概要

BGP ルートアドバタイズの原則

• クラウドへのインバウンド： データセンターから BGP 経由でアドバタイズされたルート → VPN ゲートウェイに伝播 → VPC システムルートテーブルに自動的に伝播 (ルート伝播の有効化が必要)。

• クラウドからのアウトバウンド： VPC システムルートテーブルのシステムルートエントリ → VPN ゲートウェイによって自動的に学習 (ルート伝播の有効化が必要) → BGP 経由でデータセンターに伝播。

手順

開始する前に、以下を確認してください：

• VPN ゲートウェイが BGP をサポートしていること。詳細については、「VPN ゲートウェイが BGP をサポートしているかどうかの確認」をご参照ください。

• ご利用のデータセンターのゲートウェイデバイスが BGP をサポートしていること。

制限事項

• 各 VPN ゲートウェイの BGP ルートテーブルは最大 50 ルートをサポートします (200 まで拡張可能。アカウントマネージャーにお問い合わせください)。

• VPN ゲートウェイは、宛先 CIDR ブロックが 0.0.0.0/0 の BGP ルートを受け入れません。

• 同じ VPN ゲートウェイ上の複数の IPsec-VPN 接続で BGP が有効になっている場合、すべての接続で ローカル ASN は同じでなければなりません。

• 異なる IPsec-VPN 接続間でルートを交換しないでください。

• 1 つの VPC が複数の VPN ゲートウェイに関連付けられている場合、ゲートウェイは相互に BGP ピアリングをサポートしません。異なる VPN ゲートウェイ間でルートを交換しないでください。

• 1 つの VPC が、すべて BGP を使用し、同じカスタマーゲートウェイに接続する複数の VPN ゲートウェイに関連付けられている場合、ルーティングループを防ぐために、各 VPN ゲートウェイ上の IPsec-VPN 接続のローカル ASN は同一でなければなりません。

• 複数のデュアルトンネル IPsec-VPN 接続が同時に BGP を使用する場合、各接続によって学習されるルートの宛先 CIDR ブロックは重複してはなりません。

• Express Connect 回線と VPN ゲートウェイをアクティブ/スタンバイで VPC にアクセスするために使用する場合、VBR (Virtual Border Router) と VPN ゲートウェイで設定されたローカル ASN は同じでなければなりません。

• VPN ゲートウェイの VPC が Cloud Enterprise Network (CEN) に属している場合は、ルートの重複を有効にします。これは、2019 年 3 月以降に作成された CEN インスタンスではデフォルトで有効になっています。

• 同じ CEN 内の複数の VPC が BGP を介して同じデータセンターに接続する場合、動的ルートが CEN を介して他の VPC に伝播し、ルートフラッピングを引き起こす可能性があります。代わりに静的ルートを使用してください。

• シングルトンネルモードの VPN ゲートウェイ： 100.64.0.0/10 (そのサブネットとスーパーネットを含む) のルートを伝播しないでください。この問題は、「IPsec-VPN 接続をデュアルトンネルモードにアップグレードする」ことで回避できます。

ルート設定の推奨事項

• 1 つの VPN ゲートウェイ上のすべての IPsec-VPN 接続には、同じルーティング方式を使用してください。宛先ベースルート、ポリシーベースルート、BGP ルートを混在させないでください。

• BGP ルートを設定する場合、IPsec-VPN 接続の ルーティングモード を 宛先ルーティングモード に設定してください。

VPN ゲートウェイが BGP をサポートしているかどうかの確認

• デュアルトンネル IPsec-VPN 接続をサポートする新しく作成された VPN ゲートウェイは、デフォルトで BGP をサポートします。

• 既存の VPN ゲートウェイの場合： DescribeVpnGateway オペレーションを呼び出し、Tag フィールドに値が true の VpnEnableBgp タグが含まれていることを確認します。

• サポートされていないゲートウェイのアップグレードオプション：

  - デュアルトンネルモードの VPN ゲートウェイ： VPN ゲートウェイのアップグレード (標準タイプのみ)

  - シングルトンネルモードの VPN ゲートウェイ： デュアルトンネルモードへのアップグレード

アクティブ/スタンバイルートの設定

• レガシーのシングルトンネル VPN ゲートウェイでアクティブ/スタンバイを設定するには、「IPsec-VPN 接続をデュアルトンネルモードにアップグレードする」をご参照ください。デュアルトンネル接続は、重みの設定なしでデフォルトでアクティブ/スタンバイを提供します。

• それでもシングルトンネルモードでアクティブ/スタンバイリンクを設定する必要がある場合は、次の手順に従ってください：

  1. プライマリルートの重みは 100、スタンバイルートの重みは 0 です。宛先 CIDR ブロックは同じでなければなりませんが、ネクストホップは異なる必要があります。ポリシーベースルートの場合、送信元 CIDR ブロックも同じでなければなりません。

  2. IPsec-VPN 接続に ヘルスチェック を設定して、自動フェイルオーバーを有効にします。このオプションは、IPsec-VPN 接続のトンネル設定にあります。

  3. ルートの重みを変更するには、まずスタンバイルートを削除し、アクティブルートの重みを変更してから、スタンバイルートを再作成します。スタンバイルートの重みを変更する場合も同じプロセスが適用されます。

  2023 年 10 月 12 日以降にアップグレードされていない VPN ゲートウェイインスタンスで、アクティブ/スタンバイのポリシーベースルートを設定する必要がある場合は、各 CIDR ブロックにアクティブ/スタンバイリンクが指定されていることを確認してください。CIDR ブロックに 1 つのリンクしか設定されていない場合、他の CIDR ブロックのフェイルオーバーが失敗する可能性があります。この問題は、VPN ゲートウェイをアップグレードするか、「IPsec-VPN 接続をデュアルトンネルモードにアップグレードする」ことで回避できます。この問題は、2023 年 10 月 12 日以降に作成またはアップグレードされた VPN ゲートウェイインスタンスには影響しません。

• 設定後、ルートは次のルールに基づいて有効になります：

  アクティブルートの IPsec-VPN 接続	スタンバイルートの IPsec-VPN 接続	有効なルート
  アップ (ネゴシエーション成功かつヘルスチェック正常)	すべての状態	アクティブルート
  ダウン	アップ	スタンバイルート
  ダウン	ダウン	アクティブルート (デフォルト)

よくある質問

Q: Elastic Compute Service (ECS) が VPN ゲートウェイを介してオンプレミスのリソースにアクセスする場合、トラフィックはどのようにルートテーブルと照合されますか？

ECS が VPN を介してオンプレミスリソースと通信する場合、トラフィックは以下の照合順序で転送されます。

1. VPC ルートテーブル： システムはまず VPC ルートテーブルをクエリします。宛先 IP に一致するルートエントリが存在する場合 (ネクストホップが VPN ゲートウェイである場合)、トラフィックは VPN ゲートウェイに転送されます。

2. VPN ゲートウェイのルートテーブル： 次に、VPN ゲートウェイは自身のルートテーブル (宛先ルーティングまたはポリシーベースルーティング) に基づいて、トラフィックをどの IPsec 接続に転送するかを決定します。

Q: オンプレミスの IDC がクラウドの ECS に PING できない、または SSH 接続が失敗するのはなぜですか？

以下の順序でトラブルシューティングを行ってください：

1. VPN ルートの設定が正しいことを確認します (VPC ルートテーブルに VPN ゲートウェイを指すルートエントリが含まれており、VPN ゲートウェイのルートテーブルに対応する宛先ルートまたはポリシーベースルートが設定されている)。

2. クラウド ECS のセキュリティグループルールを確認します：

   • PING テスト (ICMP)： セキュリティグループのインバウンド方向で、オンプレミス IDC の CIDR ブロックからの ICMP プロトコルが許可されていることを確認します。

   • SSH 接続 (TCP ポート 22)： セキュリティグループのインバウンド方向で、オンプレミス IDC の CIDR ブロックからの TCP ポート 22 が許可されていることを確認します。

ルート設定が正常であるにもかかわらず接続が失敗する場合、セキュリティグループによるブロックが一般的な原因であるため、ルートの問題と誤診する前にまず確認する必要があります。

Q: VPC NAT ゲートウェイと IPsec-VPN を併用する場合、ECS のルートはどのように設定すればよいですか？

A: NAT ゲートウェイと VPN ゲートウェイを組み合わせたシナリオでは、ECS がオンプレミスのサービスに送信するトラフィックは、まず NAT ゲートウェイによって変換され、その後 VPN トンネルを介して送信される必要があります。設定手順は次のとおりです：

1. ルートテーブルコンソールでカスタムルートテーブルを作成し、ECS が存在する vSwitch に関連付けます。

2. カスタムルートテーブルにルートエントリを追加します：宛先 CIDR ブロックをオンプレミスの内部サービスアドレスに、ネクストホップを NAT ゲートウェイに設定します。

詳細については、「NAT ゲートウェイと VPN ゲートウェイ経由のプライベートネットワークアクセス」をご参照ください。

Q: トラフィックセレクターを 0.0.0.0/0 または大きな CIDR ブロック (例：10.0.0.0/8) に設定した場合の影響は何ですか？

トラフィックセレクターの範囲は、IKE ネゴシエーションをトリガーするトラフィックのタイプを決定しますが、実際にトンネルに入るトラフィックはルート決定によって制御されます。

• 0.0.0.0/0 を設定しても、オンプレミスのネットワーク接続に直接影響はありません。ただし、オンプレミスのルートテーブルで 0.0.0.0/0 ルートを VPN トンネルに向けると、すべてのトラフィック (インターネットアクセスを含む) がトンネルに入ろうとし、インターネットアクセスが失敗する可能性があります。

• ローカル CIDR ブロックを大きな範囲 (例：10.0.0.0/8) に設定できますが、ピアデバイスの暗号化 ACL も対応する集約 CIDR ブロックに変更されていることを確認してください。ピアの CIDR ブロックを集約できない場合は、0.0.0.0/0 を使用し、IPsec 接続の下に特定のルートエントリを追加して、詳細なトラフィック制御を実現し、SA ネゴシエーションの数を減らすことができます。

詳細については、「複数 CIDR 相互接続設定の推奨事項とよくある質問」をご参照ください。

チュートリアル

「strongSwan の設定」をご参照ください。