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

制限事項

• デュアルトンネル VPN ゲートウェイ：

  • 宛先ベースのルートでは、宛先 CIDR ブロックとして 0.0.0.0/0 はサポートされていません。ポリシーベースのルートでは、宛先 CIDR ブロックとして 0.0.0.0/0 がサポートされています。

• シングルトンネル VPN ゲートウェイ (提供終了)：

  • 宛先ベースのルートとポリシーベースのルート：どちらも宛先 CIDR ブロックとして 0.0.0.0/0 はサポートされていません。

  • 宛先ベースのルートとポリシーベースのルート：どちらも、宛先 CIDR ブロックとして 100.64.0.0/10 (100.64.0.0/10 自体、そのサブネット、およびスーパーネットを含む) と重複する CIDR ブロックはサポートされていません。

• ルートの競合に関するプロンプトが表示された場合は、「ルートの重複エラーの処理」をご参照ください。

エンドツーエンドの概要

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 へのアクティブ/スタンバイアクセスを行う場合、Border Router (VBR) と 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 接続には、同じルーティング方式を使用してください。宛先ベース、ポリシーベース、BGP ルートを混在させないでください。

• BGP 動的ルートを設定する場合、IPsec 接続の ルーティングモード には 宛先ルーティングモード を使用することを推奨します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

よくある質問

Q：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 のルートはどのように設定しますか？

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

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

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

詳細については、「VPC 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 の設定」をご参照ください。