Site-to-Site VPN 図: IPsec トンネル、BGP ルーティング、冗長構成

データセンターは、1 年間問題なく動いてきた Site-to-Site VPN を通じて AWS 上のワークロードに接続しています。ある夜、AWS が定期メンテナンスでトンネルのエンドポイントを交換し、VPC へのすべての接続が切れます。ファイアウォールに設定されていたのはトンネル 1 だけでした。トンネル 2 は作成した日からずっと DOWN と表示されていました。

多くの図では、Site-to-Site VPN は 1 本の線で描かれます。実際には IPsec トンネルが 2 本、BGP セッションが 2 つ、そして MTU の予算があり、障害はその線が隠している部分から起きます。この記事では、IPsec の構成要素、AWS の例、静的ルーティングと BGP の比較、冗長化、MTU と MSS、監視、そして専用線のほうが向いている場面を扱います。

Site-to-Site VPN とリモートアクセス VPN の違い

Site-to-Site VPN は 2 つのネットワークを結びます。両端のゲートウェイがトンネルを保持し、その背後のホストに VPN ソフトウェアは不要です。リモートアクセス VPN は 1 台のデバイスを結びます。各ノート PC にクライアントを入れ、ユーザーがサインインします。本当の目的が社内アプリへのアクセスであれば、ゼロトラストアーキテクチャの ID 認識型プロキシのほうが、どちらよりも適していることがよくあります。

IPsec の構成要素

IKEv2（RFC 7296）はピアを認証し、鍵をネゴシエーションします。ESP（RFC 4303）は通信を暗号化します。

IKEv2 は通常、4 つのメッセージ（IKE_SA_INIT と IKE_AUTH）で IKE SA と最初の Child SA を確立します。IKEv1 は 2023 年に RFC 9395 で非推奨になりました。アルゴリズムについては、RFC 8247 が DH グループ 14 を実装必須とし、グループ 19 を推奨しています。グループ 2、5、23、24 は使うべきではなく、グループ 22 は使ってはいけません。

接続ごとに 2 本のトンネル: AWS の例

AWS Site-to-Site VPN は、カスタマーゲートウェイデバイスを AWS 側のゲートウェイにつなぎます。AWS のトンネルオプションのドキュメントによると、すべての接続には 2 本のトンネルがあり、それぞれ独自のパブリック IP を持ち、異なる Availability Zone で終端します。

AWS はパッチ適用やハードウェアの退役のためにトンネルのエンドポイントを、一度に 1 本ずつ交換します。そのため、1 本のトンネルしか使わないデバイスは、そのエンドポイントが交換されるたびに接続を失う可能性があります。AWS Health は、1 日に 1 時間を超えてトンネルが停止した場合、毎月通知を送ります。

各トンネルには 169.254.0.0/16 の範囲から内側の /30 が割り当てられます。AWS が最初の使用可能アドレス、お使いのデバイスが 2 番目を使い、その間で BGP が動作します。起動アクションを start に設定しない限り、IKE を開始するのはお使いのデバイスです（IKEv2 のみ）。AWS は、デバイスが送る順序に関係なく、許可リストの最小の値から提案を評価します。そのため、両側で IKEv1、SHA-1、DH グループ 2、5、22 から 24 を外してください。

2 本のトンネルが同一になるように、コードで定義してください。Terraform ではトンネル 1 は次のとおりです。

resource "aws_vpn_connection" "dc" {
  vpn_gateway_id      = aws_vpn_gateway.main.id
  customer_gateway_id = aws_customer_gateway.dc.id
  type                = "ipsec.1"
  static_routes_only  = false

  tunnel1_inside_cidr                  = "169.254.10.0/30"
  tunnel1_ike_versions                 = ["ikev2"]
  tunnel1_phase1_encryption_algorithms = ["AES256-GCM-16"]
  tunnel1_phase1_integrity_algorithms  = ["SHA2-384"]
  tunnel1_phase1_dh_group_numbers      = [20]
  tunnel1_phase2_encryption_algorithms = ["AES256-GCM-16"]
  tunnel1_phase2_dh_group_numbers      = [20]
  tunnel1_dpd_timeout_seconds          = 30
  tunnel1_dpd_timeout_action           = "restart"
  tunnel1_startup_action               = "start"
  # tunnel2_*: the same values with 169.254.10.4/30
}

静的ルーティングか BGP か

静的ルーティングでは、接続にプレフィックスを列挙し、フェイルオーバーはお使いのデバイスのヘルスチェックに任せます。BGP では、各トンネルが eBGP セッションを持ち、トンネルが停止するとセッションが切れた時点でそのルートが取り消されます。AWS は、デバイスが対応しているなら BGP を推奨しており、ECMP には BGP が必須です。ルールは 4 つあります。

1. 異なるプライベート ASN を使います。 AWS 側のデフォルトは 64512 です。サイトには独自のプライベート ASN を割り当ててください。範囲は 64512 から 65534、または 4200000000 から 4294967294 です（RFC 6996）。
2. サマリーを広告します。 Virtual private gateway がお使いのデバイスから受け付けるルートは最大 100 件で、固定の上限です。
3. CIDR を重複させないでください。 VPC のローカルルートは、より詳細なものも含め、どの VPN ルートよりも優先されます。サイト間でアドレス空間を計画するか、片側で NAT を使ってください。
4. タイブレークの順序を把握します。 同じプレフィックスに対し、virtual private gateway は Direct Connect、静的 VPN ルート、BGP ルートの順に優先し、次に最短の AS パス、最後に最小の MED を選びます。

ECMP がない場合、AWS は戻りの通信を一度に 1 本のトンネルだけに流し、MED で印を付けます。AWS のルート優先度のガイダンスは、非対称ルーティングを許可し、AS パスを同じ長さに保つことです。ステートフルファイアウォールが対応できない場合は、トンネル 2 の AS パスをプリペンドしてローカルプリファレンスを下げてください。ただし AWS の出口パスが変わると、フローが切れることがあります。AWS の設定例では、RFC 4271 が示す 90 秒ではなく、キープアライブ 10 秒、ホールドタイム 30 秒を使っています。

冗長構成

2 本のトンネルがカバーするのは AWS 側の障害です。お使いのデバイス、ISP、サイトは依然として共有されたままです。

デバイスが 2 台の場合、それぞれが独自の VPN 接続を持ち、どちらも同じプレフィックスを広告します。ECMP は各フローをハッシュで 1 本のトンネルに割り当てるため、4 本のトンネルで合計約 5 Gbps になりますが、1 本の TCP 接続は依然として 1.25 Gbps が上限で、ステートフルファイアウォールでは対称性のために送信元 NAT が必要になることがあります。サイトが多い場合は、Transit gateway がハブアンドスポークネットワークのハブになります。

MTU と MSS クランプ

トンネルを通る各パケットには、新しい IP ヘッダーと ESP のオーバーヘッドが付きます。AWS がサポートするのは、MTU が最大 1,446 バイト、TCP MSS が最大 1,406 バイトで、Path MTU Discovery もジャンボフレームもありません。正確な値は使用するアルゴリズムによって決まります。AWS のカスタマーゲートウェイのベストプラクティスに基づく値は次のとおりです。

トンネルの MTU を設定し、TCP SYN パケットの MSS を両方向でクランプしてください。各側が自分の値を通知するためです。Linux ゲートウェイでは次のようにします。

ip link set dev vti1 mtu 1446
iptables -t mangle -A FORWARD -o vti1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1406
iptables -t mangle -A FORWARD -i vti1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1406

値が間違っている場合の典型的な症状は、ping と SSH は動くのにファイルコピーが止まることです。AWS のデバイス要件のページでは 1,399 バイトが提案されており、これでも動作しますが、数バイト無駄になります。

トンネルの監視

• トンネルの状態。 CloudWatch はトンネルごとに TunnelState を公開します。BGP 接続では、1 はセッションが確立していることを意味します。どちらかのトンネルが 1 を下回ったらアラームを出してください。TunnelDataIn と TunnelDataOut で、どのトンネルが通信を運んでいるかが分かります。
• ログ。 Site-to-Site VPN のログには、IKE の状態、DPD イベント、BGP のステータス、ルートの変更が記録されます。
• お使いの側。 トンネルごとに BGP の状態と受信したプレフィックスを監視してください。セッションが確立していてもプレフィックスが 0 なら、障害であることに変わりはありません。

トンネルが上がらないときは、IKE SA、IPsec SA、AWS 内側アドレスへの ping、BGP の順に、レイヤーごとに確認してください。

Direct Connect に移行する場面

トラフィックが常時ギガビット規模で、レイテンシーが重要な場合、またはインターネットへの送信料金がポート料金を上回る場合に移行してください。2026 年 9 月から、10 Gbps と 100 Gbps の専用接続では、ティア内のデータ転送アウトを含む定額料金を利用できます。VPN はバックアップとして残してください。Virtual private gateway は Direct Connect のルートを優先するため、回線が故障したときだけトラフィックがトンネルを使います。この計画についてはディザスタリカバリアーキテクチャ図で扱っています。

Site-to-Site VPN 図

図の読み方は次のとおりです。

• 左はデータセンター: AS 65010 の 10.20.0.0/16 です。LAN は VPC 宛ての通信を、カスタマーゲートウェイデバイスであるエッジファイアウォールに送ります。
• 2 本のトンネルは virtual private gateway の 2 つのエンドポイントに届き、それぞれ内側の /30 と BGP セッションを持ちます。どちらも稼働中で、戻りのトンネルは AWS が選びます。
• 右は VPC: 10.50.0.0/16 で、2 つの Availability Zone にプライベートサブネットがあり、10.20.0.0/16 への伝播されたルートがあります。
• Markdown ブロックには、両方のトンネルで一致させる必要がある設定が書かれています。
• 下部のノートは、2 本のトンネルがカバーするもの（エンドポイントの交換）と、カバーしないもの（ファイアウォール 1 台、ISP 1 社）を示しています。

Site-to-Site VPN 図を分かりやすく描くには

• 両端にラベルを付けます。 CIDR、ASN、パブリック IP を書いてください。VPN の問い合わせの多くは、このどれかから始まります。
• 両方のトンネルを描きます。 内側の /30 と BGP ピアを添え、どちらが優先され、それはなぜかを書いてください。
• 共通の設定は 1 つのボックスにまとめます。 IKE バージョン、アルゴリズム、DH グループ、有効期間、MTU と MSS です。
• 単一障害点を示します。 たとえばデバイス 1 台や ISP 1 社です。
• 省くものは、事前共有鍵、ISP の内部構成、ホスト一覧です。

オフィス側についてはネットワークトポロジー図、サブネットとルートテーブルについては AWS VPC 図を参照してください。

Archboard で作る

1. Google または GitHub でサインインし、ダイアグラムを作成します。
2. データセンター用に、基本パックのフレームを追加し、CIDR と ASN を名前にします。その中に、ネットワークパックのサブネットを追加し、サーバーノード 2 つとファイアウォールを置きます。
3. ネットワークパックの VPC を追加します。その中に、virtual private gateway 用のフレームを追加してルーターノードを 2 つ置き、プライベートなサブネットノード 2 つのそれぞれに、クラウドパックのコンピューティングノードを置きます。
4. ファイアウォールからエンドポイントへ、両端に矢印を付けてトンネルを描き、内側の /30 と BGP ピアをラベルにします。LAN からファイアウォールへ、ゲートウェイからサブネットへエッジを追加します。
5. トンネルの間に、基本パックの Markdown ブロックを追加して共通設定を書き、テキストのノートも加えます。

VPN を Terraform で定義している場合は、無料の Terraform to diagram ツールで最初のたたき台を作れます。ネットワーク図も参照してください。

この例で使うダイアグラムノードは 14 個で、Free プランの範囲に収まります。

よくある質問

Site-to-Site VPN 図には何を描くべきですか？ 両方のネットワークとその CIDR、各ゲートウェイのパブリック IP と ASN、各トンネルの内側アドレス、ルーティング、そして両側で一致させる必要がある設定です。

AWS Site-to-Site VPN にトンネルが 2 本あるのはなぜですか？ 各接続には、異なる Availability Zone のエンドポイントへ向かうトンネルが 2 本あります。AWS はそれらを 1 本ずつメンテナンスするため、両方を設定しておけば、通信は止まらずに移動します。

IPsec では静的ルーティングと BGP のどちらを使うべきですか？ デバイスが対応しているなら BGP です。障害が起きたトンネルのルートを自動で取り消し、ECMP にも必要です。静的ルーティングは BGP に対応しないデバイス向けです。

AWS VPN の MTU と MSS はいくつにすべきですか？ AES-GCM で NAT トラバーサルなしの場合は、最大で 1,446 バイトと 1,406 バイトです。CBC 暗号と NAT-T では、AWS の表にあるより小さい値が必要です。

VPN の代わりに Direct Connect を使うのはいつですか？ トラフィックが常時ギガビット規模のとき、レイテンシーを予測可能にしたいとき、または最大 99.99% の SLA が必要なときです。VPN は暗号化されたバックアップとして残してください。

無料で始める — 1 シート、クレジットカード不要。