【実務・中級編】サイト間VPN（Site-to-Site VPN）とIPsecトンネルの構築 – クラウド＆コンテナネットワーク実践ガイド

クラウドとオンプレミスを繋ぐ生命線：AWS Site-to-Site VPNとIPsecトンネル徹底解説

こんにちは。数々の修羅場をくぐり抜けてきたシニアSREの私です。

本番環境のWeb API設計やマイクロサービスのインフラをどれだけ美しく作っても、オンプレミスにあるレガシーな基幹系DBや社内認証基盤との間で「パケットが通らない」という事態が起きれば、その瞬間にシステム全体の価値はゼロになります。クラウドネイティブな世界に生きる私たちであっても、現実世界（オンプレミス）との境界線を繋ぐネットワークの基礎、特にAWS Site-to-Site VPNとIPsecトンネルの仕組みを腹落ちさせておくことは、シニアエンジニアとして必須の素養です。

今回は、教科書的な仕様の丸暗記ではなく、パケットが暗号化され、インターネットの荒海を渡り、AWSのVPCに到達するまでのリアルな挙動と、現場で必ず直面する「ハマりどころ」を交えて徹底解説します。

—

1. サイト間VPNの全体像とIPsecが担う役割

オンプレミス環境のルーターと、AWS側の仮想プライベートゲートウェイ（VGW）またはAWS Transit Gatewayとの間に、安全なトンネルを構築する技術がAWS Site-to-Site VPNです。

インターネットという「盗聴・改ざんが当たり前の危険な公衆網」をそのまま通る通信を、IPsec（Security Architecture for Internet Protocol）という強力なプロトコル群を使って、まるで専用線（AWS Direct Connect）であるかのように安全にカプセル化して通信します。

冗長化の基本：なぜ「2つのトンネル」が必須なのか？

AWSのSite-to-Site VPNを構築すると、必ず2つのトンネル（Tunnel 1 / Tunnel 2）が自動的に払い出されます。これはAWS側が物理的に異なるアベイラビリティゾーン（AZ）や終端装置を用意しているためです。

現場のインフラ設計で絶対にやってはいけないアンチパターンが、「コストや設定の手間を惜しんでTunnel 1しか使わない」という構成です。AWS側のメンテナンスや予期せぬハードウェア障害でトンネルが瞬断した際、Tunnel 2がスタンバイしていなければ、オンプレミスからのWeb API呼び出しは一瞬で全滅します。アクティブ・アクティブ、あるいはアクティブ・スタンバイとして両方のトンネルをルーティング設定に組み込むことが、プロとしての最低限の責務です。

—

2. 通信フローの裏側：IKEフェーズとIPsecパケットカプセル化

パケットがオンプレミスからAWSへ流れるとき、内部では以下のような厳密なハンドシェイクとカプセル化が行われています。

① IKE（Internet Key Exchange）フェーズによる鍵共有

まず、お互いのルーター（ピア）が正当な通信相手かを確認し、暗号化通信用の共通鍵を安全に作るためのセッションを張ります。

Phase 1 (ISAKMP SAの確立): メインモードまたはアグレッシブモードを使い、双方が信頼できる相手か認証（事前共有鍵（PSK）や証明書）を行い、暗号化された安全な管理チャネルを作ります。
Phase 2 (IPsec SAの確立): Phase 1で作った安全なチャネル上で、実際にデータ暗号化に使うセッションキーをネゴシエーションします。ここで「どのアルゴリズムを使うか」「ライフタイムはいくつにするか」の合意が取れます。

② ESP（Encapsulating Security Payload）によるパケット保護

ネゴシエーションが完了すると、いよいよ実際のデータ通信（ペイロード）が始まります。
オンプレミスのアプリケーションサーバーから送信されたパケット（例: 192.168.10.50 から 10.0.1.100 宛てのJSONデータ）は、オンプレミス側のVPNルーターで以下のように変換されます。

1. 元のIPパケット全体が暗号化される。
2. その外側に、AWS側のVPNパケットエンドポイント（外向きのグローバルIPアドレス）を宛先とする新しいIPヘッダーが付与される。
3. インターネット上を暗号化されたカプセル（ESPパケット）としてルーティングされる。
4. AWS側のVGW（またはTransit Gateway）に到着すると、カプセルが剥がされ、復号されてVPC内のプライベートサブネットへと流れていく。

—

3. 実務で必須のパラメーター選定と設定例

AWSとオンプレミスルーター（Cisco ISR、YSR、Yamaha RTX、VyOSなど）を接続する際、最も頭を悩ませるのがパラメーターの不一致によるトンネル断です。

AWSが推奨するAWS推奨VPNカスタマーゲートウェイ設定に基づく、モダンでセキュアな暗号化プロファイルの例を見てみましょう。

推奨暗号化プロファイル（IKEv2 / AES-256 / SHA-2）

—

4. 現場で役立つ設定・検証コード

それでは、実際に構築したVPNトンネルの疎通確認や、アプリケーション層（Web API）からの接続テストを行う際の実務的な手法をコードやコマンドを交えて紹介します。

A. オンプレミス側ルーター（例: Linux / VyOSライクなIPsec設定の概念）

AWSから提供される設定ファイルをベースに、厳密なパラメーターをルーターに流し込みます。

# /etc/ipsec.conf の設定例 (StrongSwanベース)
conn aws-vpn-tunnel1
    # 通信の有効化
    auto=start
    left=%defaultroute
    # オンプレミス側のローカルプライベートネットワーク
    leftsubnet=192.168.10.0/24
    # AWS側のVPNエンドポイント（パブリックIP）
    right=203.0.113.50
    # AWS側のVPC内プライベートネットワーク
    rightsubnet=10.0.0.0/16
    # 暗号化スイートの指定（AWSの推奨値に厳密に合わせる）
    ike=aes256-sha256-modp2048
    esp=aes256-sha256
    keyexchange=ikev2
    # 接続断を素早く検知するためのDPD設定
    dpddelay=10
    dpdtimeout=30
    dpdaction=restart

B. PythonによるWeb API接続テストスクリプト

VPN経由でAWSのVPC内にあるプライベートAPIサーバー（例: 10.0.1.100:8080）に対して、定期的にヘルスチェックのリクエストを投げる実用的なスクリプトです。ネットワークの瞬断やタイムアウトを検知するために、タイムアウト値のチューニングを行っています。

“`python
import sys
import requests
from requests.exceptions import RequestException

AWS側プライベートサブネットに配置されたAPIサーバーのエンドポイント
API_URL = “http://10.0.1.100:8080/api/v1/health”

def check_vpn_api_connection():
try:
print(f”Connecting to AWS private API via VPN: {API_URL}”)
# VPN越しの通信は遅延やパケットロスを考慮し、タイムアウトを3秒に設定
response = requests.get(API_URL, timeout=3.0)

# ステータスコードの検証
if response.status_code == 200:
print(“[SUCCESS] VPN tunnel is healthy. API Response:”, response.json())
sys.exit(0)
else:
print(f”[WARNING] API returned status code: {response.status_code}”)
sys.exit(1)

except RequestException as e:
print(