AWS Site-to-Site VPNのIPsecトンネル冗長化とBGPマルチパス制御：パケットが描く極限のレジリエンスとルーティングの美学
ネットワークプロトコルやLinuxカーネルの底流で蠢くパケットの挙動を愛してやまないインフラエンジニアにとって、AWSとオンプレミス環境を繋ぐ「AWS Site-to-Site VPN」は、単なるトンネルの接続手段ではない。それは、暗号化、ルーティング、そして高可用性の境界線上で繰り広げられる、洗練されたプロトコルの交響曲だ。
教科書的な「冗長化のためにトンネルを2本張ります」という説明で満足する時代は終わった。本稿では、カスタマーゲートウェイ（CGW）と仮想プライベートゲートウェイ（VGW）の間に築かれるIPsecトンネルのデュアル構成、そしてBGP（Border Gateway Protocol）を用いた自動パスフェイルオーバーの深層を、パケットレベルの挙動とカーネルパラメータの最適化という極限の視点から解き明かしていく。
—
1. デュアルIPsecトンネルとBGPセッションの内部挙動
AWS Site-to-Site VPNは、標準で各接続につき2つの独立したIPsecトンネルを提供する。これは単なる「バックアップがある」という安心感の演出ではなく、物理的なAWSの可用性ゾーン（AZ）の境界をまたいだ冗長性を担保するためのアーキテクチャ上の必然である。
パケットがたどる運命：ISAKMPからESPカプセル化まで
オンプレミスのCGWからAWSのVGWへ向けてパケットが送出される際、以下のレイヤーが精巧に組み合わされる。
1. IKE (Internet Key Exchange) フェーズ:
UDPポート500（NAT-Tの場合は4500）を使用し、IKEv2によるセキュリティアソシエーション（SA）の確立が行われる。ここでDiffie-Hellman（DH）グループによる鍵共有と、AES-GCMなどの暗号アルゴリズムのネゴシエーションが完了する。
2. ESP (Encapsulating Security Payload) カプセル化:
IPsecトンネルモードにおいて、元のIPパケットはESPヘッダーで包まれ、さらに新しい外側のIPヘッダーが付与される。これにより、パケットのペイロードだけでなく元のIPヘッダー全体が暗号化され、中間経路での盗聴や改ざんが無効化される。
ここで重要なのは、2つのトンネルはそれぞれ異なるAWS側の終端パブリックIPアドレスを持つという点だ。AWS側で一方のゲートウェイアプライアンスに障害が発生した場合、BGPがその異常を検知し、瞬時にトラフィックをもう一方のトンネルへとバイパスさせる必要がある。
—
2. BGPマルチパス制御とミリ秒単位のフェイルオーバー
静的ルーティングを用いたVPNでは、死活監視（Dead Peer Detection: DPD）のタイムアウトを待つ必要があり、フェイルオーバーに数十秒の空白が生じる。しかし、BGP（特に eBGP）を組み合わせることで、このレイテンシーを劇的に削ぎ落とすことができる。
BGPキープアライブとホールドタイマーの極限チューニング
デフォルトのBGP設定では、キープアライブ（Keepalive）が60秒、ホールドタイム（Hold Timer）が180秒に設定されている。これではミッションクリティカルなワークロードにおいてフェイルオーバーが遅すぎる。AWS側およびオンプレミス側のルーター（例: Cisco IOS, FRRouting, pfSense等）では、以下のようにタイマーを切り詰めるのが常道だ。
# BGPタイマーの推奨アグレッシブ設定例 (FRRouting / Ciscoライクな記法)
router bgp 65001
! AWS側のVGWのASNに対してネイバーを張る
neighbor 169.254.255.1 remote-as 64512
neighbor 169.254.255.1 bbgp timers 3 9
! キープアライブを3秒、ホールドタイムを9秒に設定し、障害検知を高速化この設定により、パケットの往来が途絶えてからわずか9秒足らずでBGPセッションがダウン判定を下し、ルーティングテーブルから該当パスが即座にパージされる。Linuxカーネルのルーティングキャッシュと結びつくことで、トラフィックは瞬時にもう一方のトンネルへと流し込まれるのだ。
—
3. ネットワークスタックとカーネルパラメータの最適化
VPNトンネルを通過するトラフィックは、暗号化とカプセル化のオーバーヘッド（ESPヘッダーによるMTUの圧迫）を受ける。ここでTCPセグメントサイズやカーネルのバッファチューニングを怠ると、帯域幅が十分に広くてもスループットが頭打ちになる現象（いわゆる「見えないボトルネック」）に直面する。
MTUとMSSの最適化（Path MTU Discoveryの罠）
IPsecトンネルを通るパケットは、通常のイーサネットフレーム（1500バイト）に収まらない。ESPカプセル化によるオーバーヘッドを考慮すると、VPNインターフェース上のMTUは通常 1387 バイト（AWSの推奨値）に制限される必要がある。
もしオンプレミス側のホストがこれを無視して1500バイトのパケットをDF（Don’t Fragment）フラグ付きで送り出すと、ICMP Type 3 Code 4（Fragmentation Needed）が途中でドロップされた場合にブラックホールルーター問題が発生する。
これを防ぐため、Linuxカーネルの iptables または nftables を用いて、TCPのMSS（Maximum Segment Size）を強制的にクランプ（調整）する。
# iptablesを用いたMSSクランピングの設定例
# VPNトンネルを通過するTCPパケットのMSSをAWS推奨値（1300〜1350程度、トンネル仕様に依存）に強制書き換え
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1350LinuxカーネルのTCPバッファチューニング
高スループットなVPN環境では、BDP（Bandwidth-Delay Product）に見合ったカーネルバッファの拡張が不可欠である。/etc/sysctl.conf に以下のパラメータを記述し、カーネルのネットワークメモリ管理を極限まで引き上げる。
# カーネルのネットワークメモリ・バッファチューニング
# 最大TCP受信バッファ
net.core.rmem_max = 16777216
# 最大TCP送信バッファ
net.core.wmem_max = 16777216
# 自動チューニング用のTCPメモリサイズ範囲 (最小, デフォルト, 最大)
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# パケット処理のバックログキューを拡大し、バーストトラフィック時のドロップを防ぐ
net.core.netdev_max_backlog = 10000—
4. セキュリティと耐障害性のベストプラクティス
暗号化強度の担保と、予期せぬルーティングループの排除は、インフラアーキテクトの腕の見せ所である。
推奨されるIPsec暗号アルゴリズム（Modern Cryptography）
古いレガシーな暗号スイート（3DESやSHA-1など）は、現代のコンプライアンス要件やセキュリティ基準において完全に失格である。AWS Site-to-Site VPNでは、以下のモダンなパラメータを強要すべきである。
- IKE Phase 1 (ISAKMP):
- Encryption:
AES-256-GCM-16またはAES-256 - Authentication:
SHA-2(特にSHA-256以上) - Diffie-Hellman Group:
Group 14以上 (推奨:Group 19または20の楕円曲線暗号) - IKE Phase 2 (IPsec ESP):
- Encryption:
AES-256-GCM-16 - Perfect Forward Secrecy (PFS): 有効化 (DH Group 14以上)
BGPプレフィックスフィルタリングによる安全性の確保
マルチパス制御を行う際、オンプレミス側から不要なルートをAWS側に広告しない、あるいはその逆のセキュリティ対策が必須である。AWS側へは、自社が管理する正当なプライベートCIDRのみをBGPで広報（Advertise）するように、CGW側で厳格なプレフィックスリスト（Prefix List）を設定する。
# 例: FRRoutingでのプレフィックスフィルタリング設定
ip prefix-list AWS-OUT permit 10.100.0.0/16 le 24
! 上記以外のネットワーク（例: デフォルトルートや他組織のIP）の広報を完全にブロック
ip prefix-list AWS-OUT deny any
router bgp 65001
neighbor 169.254.255.1 prefix-list AWS-OUT out—
5. 結びにかえて
AWS Site-to-Site VPNのIPsecトンネル冗長化とBGPマルチパス制御は、単に「設定ファイルをコピペして繋ぐ」だけの作業ではない。パケットがカプセル化され、暗号化のベールを纏い、BGPの鼓動に合わせて動的に経路を変えていくその一連のプロセスは、インフラストラクチャにおける最も美しく、かつシビアなエンジニアリングの結晶である。
カーネルの隅々までチューニングが行き届いたネットワークは、障害の予兆すら感じさせずにトラフィックを流し続ける。その裏側にある理論と実装を完全に掌握したとき、あなたのクラウドインフラは真の「揺るぎなき要塞」へと昇華するのだ。
コメント