2026.09.27 インフラ・クラウド

Site-to-Site VPNとは？3クラウドのIKE既定値とstrongSwan接続手順

Site-to-Site VPNは、拠点のルーターとクラウドのVPNゲートウェイの間にIPsecトンネルを張り、2つのネットワークを1つの閉じた経路のように扱う接続方式です。設定画面は各社とも数項目で終わりますが、実際に詰まるのはトンネルが上がった後で、鍵の寿命、DHグループ、MTUの既定値がクラウドごとに違うことが断続的な切断や一部通信だけの遅延を生む原因です。この記事では、AWS・Azure・Google Cloudの公式ドキュメントからIKEの既定値を抜き出して突き合わせ、拠点側をstrongSwanで組む設定例、AWS CLIでの提案の絞り込み、AzureとAWSを直結するときのポリシーの揃え方を実装者の目線で示します。AWSに限った料金とTerraformでの構築はAWS VPNの2方式と料金実額の解説にまとめています。

まとめ：Site-to-Site VPNはトンネル確立後の寿命とMTUの不一致で落ちる

Site-to-Site VPNのトラブルは、つながらない問題よりも、つながった後に切れる問題のほうが原因を追いにくいものです。原因の多くは、両端で既定値のまま残した設定の食い違いにあります。

代表的なのはフェーズ2の寿命です。AWSの既定は3,600秒、AzureのルートベースVPNは27,000秒、Google Cloudは10,800秒で、同じIPsecでも最大7.5倍離れています。DHグループも、Azureの既定はグループ2（1024ビット）なのに対し、Google Cloudはグループ2を受け付けません。

実務でまず押さえるのは3点だけです。寿命は短い側に揃える。提案は強い暗号に絞って両端で一致させる。MSSは経路上で最も小さい値に合わせてクランプする。この3点を最初に決めておけば、構築後の切り分けの大半は不要になります。

Site-to-Site VPNの構成要素と拠点・クラウドをつなぐ接続形態

どのクラウドでも部品の名前が違うだけで、構造は同じです。

カスタマーゲートウェイとクラウド側VPNゲートウェイの役割分担

拠点側の終端は、AWSではカスタマーゲートウェイ、Azureではローカルネットワークゲートウェイ、Google Cloudではピア VPN ゲートウェイと呼ばれます。いずれも「拠点側ルーターのグローバルIPと、その奥にあるネットワーク」をクラウドに教えるための定義で、実体は拠点に置いたルーターやファイアウォール、あるいはLinuxサーバーです。

クラウド側の終端は、AWSの仮想プライベートゲートウェイまたはTransit Gateway、AzureのVPNゲートウェイ、Google CloudのHA VPNゲートウェイです。AWSは1接続につき必ず2本のトンネルを用意し、それぞれ別のアベイラビリティゾーンで終端します。拠点側で片方しか設定しないと、AWS側の保守がそのまま通信断になります。

暗号化の中身はIPsecのAH・ESP・IKEの仕組みそのもので、フェーズ1で鍵交換の通路（IKE SA）を作り、フェーズ2で実データ用の通路（IPsec SA）を作ります。以降の章で出てくる「寿命」はこの2つのSAそれぞれの有効期間です。

ルートベースとポリシーベースの経路選択の違いと各社が前者に寄せる理由

ポリシーベースは「送信元と宛先の組」ごとにトンネルへ流すかを決める方式、ルートベースはトンネルを仮想インターフェースとして扱い、経路表で流す方式です。AWSのトンネルオプションの設定ページは、AWSがルートベースのVPNだけを使い、ポリシーベースはTransit GatewayやECMPと両立しないため非対応だと明記しています。

AzureもポリシーベースはIKEv1のみ・DPD非対応という制約があり、Google CloudのHA VPNは動的ルーティング（BGP）しか選べません。新規構築でポリシーベースを選ぶ理由は、拠点の古い機器がそれしか話せない場合に限られます。

AWS・Azure・Google CloudのIKE既定値を並べて分かる不一致

各社の公式ドキュメントから、既定値を同じ表に並べます（2026-09-27時点）。

フェーズ2の寿命がAWS3,600秒・Azure27,000秒と7.5倍離れる問題

項目	AWS	Azure（ルートベース）	Google Cloud
フェーズ1の寿命	28,800秒	28,800秒	36,000秒
フェーズ2の寿命	3,600秒	27,000秒	10,800秒
フェーズ1のDH	2、14〜24	グループ2	14〜16、19〜21、31
DPD	40秒でClear	対応	対応
MTUの上限	1,446バイト	MSS 1,360にクランプ	1,460バイト

AWSの値はトンネルオプション、Azureの値はVPNデバイスとIPsecパラメーターの一覧、Google Cloudの値は対応IKE暗号の一覧から取りました。

AWSのフェーズ2は900〜3,600秒の範囲でしか設定できません。AWS公式は、自分の設定値で鍵の更新を始めるため、交渉した値と異なると接続が途切れる場合があると注意書きを置いています。AWSと他社をつなぐなら、相手側のフェーズ2を3,600秒以下へ下げてください。

Azure既定のDHグループ2を残すと起きる暗号強度の低下と不成立

Azureの既定ポリシーはフェーズ1のDHグループ2、つまり1024ビットのMODPです。Microsoft自身が推奨アルゴリズムとしてAES256・SHA256と並べているのもDH2で、既定のまま拠点と結ぶと鍵交換の強度はそこで決まります。

Google Cloudの対応一覧にグループ2はありません。Azure同士やAzureと古いルーターなら既定で通っても、Google Cloudとは既定値どうしでは交わらない組み合わせです。

AWS側にも落とし穴があります。AWSのトンネル終端は、拠点側の提案順に関係なく、設定済みリストの低い値から評価すると公式に書かれています。既定リストにはSHA1とDHグループ2が含まれるため、強い暗号を先に提案したつもりでも弱い組み合わせで合意しうるのです。リストは明示的に絞ってください（手順は次章）。

MTU1446バイトとMSS1360バイトが混在する経路でのパケット分割

AWSのカスタマーゲートウェイのベストプラクティスは、MTUの上限を1,446バイト、MSSを1,406バイトとしたうえで、暗号方式ごとの推奨値を表にしています。AES-GCM-16でNAT-Tなしなら1,446と1,406、NAT-Tありなら1,438と1,398、AES-CBCとSHA2-512でNAT-Tありなら1,406と1,366まで下がります。

Google CloudはMTUの考慮事項でゲートウェイMTUを1,460バイトとし、ピア側を同じ値にするよう求めています。Azureはゲートウェイ上でMSSを1,360バイトへ双方向にクランプします。

症状は典型的です。pingやSSHのログインは通るのに、ファイル転送やHTTPSの大きな応答だけが止まる。この場合は暗号ではなくMTUを疑い、拠点側で経路上の最小値にMSSクランプを入れます。

strongSwan6系で拠点側ゲートウェイを作りAWSへ接続する手順

専用機器が無い検証環境や小規模拠点では、Linuxに入れたstrongSwanを拠点側ルーターにできます。2026-09-27時点のGitHubリリースでは6.1.0が最新です。以下は6.x系を前提にした例で、アドレスは文書用の予約範囲に置き換えています。

swanctl.confにAWSトンネル1本分の提案と寿命を書く設定例

AWSのトンネル1に接続する設定です。拠点側のグローバルIPを203.0.113.10、AWSのトンネル外側IPを198.51.100.1、VPCを10.0.0.0/16、拠点LANを192.168.10.0/24とします。

# /etc/swanctl/conf.d/aws-tun1.conf
connections {
  aws-tun1 {
    version = 2
    local_addrs  = 203.0.113.10
    remote_addrs = 198.51.100.1
    proposals = aes256gcm16-prfsha384-ecp384
    rekey_time = 28000s
    dpd_delay = 10s
    local  { auth = psk
             id = 203.0.113.10 }
    remote { auth = psk
             id = 198.51.100.1 }
    children {
      vpc {
        local_ts  = 0.0.0.0/0
        remote_ts = 0.0.0.0/0
        esp_proposals = aes256gcm16-ecp384
        rekey_time = 3300s
        if_id_in  = 1
        if_id_out = 1
        start_action = start
        dpd_action = restart
      }
    }
  }
}
secrets {
  ike-aws-tun1 {
    id-1 = 203.0.113.10
    id-2 = 198.51.100.1
    secret = "AWSが発行した事前共有キー"
  }
}

提案はAES256-GCM-16、PRFはSHA2-384、DHは20（ecp384）で、いずれもAWSの既定リストに含まれます。寿命はAWSのフェーズ1（28,800秒）とフェーズ2（3,600秒）より少し短くし、拠点側が先に鍵を更新するようにしています。start_action = startは、AWSの既定の起動動作がAdd（拠点側から交渉を始める）であることへの対応です。各項目の意味はswanctl.confのリファレンスで確認できます。

XFRMインターフェースとMSSクランプをLinux側で用意するコマンド

トラフィックセレクタを0.0.0.0/0にしたので、どの通信をトンネルへ流すかは経路表で決めます。if_idが1のXFRMインターフェースを作り、VPC宛ての経路をそこへ向けます。

ip link add ipsec1 type xfrm dev eth0 if_id 1
ip addr add 169.254.10.2/30 dev ipsec1
ip link set ipsec1 mtu 1446 up
ip route add 10.0.0.0/16 dev ipsec1
iptables -t mangle -A FORWARD -o ipsec1 -p tcp \
  --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1406
swanctl --load-all
swanctl --list-sas

169.254.10.2/30は、AWSがトンネル内側に割り当てた/30の2番目のアドレスに置き換えます。AWSは169.254.0.0/30〜169.254.5.0/30と169.254.169.252/30を予約済みとしており、自分で内側CIDRを指定するときはこれらを避けます。MTUとMSSの1,446と1,406はAES-GCMでNAT-Tを使わない場合の値で、拠点がNAT配下なら1,438と1,398に下げてください。

AWS CLIで提案を絞りVgwTelemetryで両端の状態を確かめる

AWS側の受け入れリストを、拠点側と同じ組み合わせに絞ります。modify-vpn-tunnel-optionsはトンネル1本ずつ指定するため、2本目も同じ内容で実行します。

aws ec2 modify-vpn-tunnel-options \
  --vpn-connection-id vpn-0123456789abcdef0 \
  --vpn-tunnel-outside-ip-address 198.51.100.1 \
  --tunnel-options 'IKEVersions=[{Value=ikev2}],Phase1EncryptionAlgorithms=[{Value=AES256-GCM-16}],Phase1IntegrityAlgorithms=[{Value=SHA2-384}],Phase1DHGroupNumbers=[{Value=20}],Phase2EncryptionAlgorithms=[{Value=AES256-GCM-16}],Phase2DHGroupNumbers=[{Value=20}],StartupAction=start'

aws ec2 describe-vpn-connections \
  --vpn-connection-ids vpn-0123456789abcdef0 \
  --query 'VpnConnections[0].VgwTelemetry[].[OutsideIpAddress,Status,AcceptedRouteCount]' \
  --output table

変更中はトンネルが一時的に切れるので、2本を同時に変えず、トンネルの変更は1本ずつ進めてください。describe-vpn-connectionsのVgwTelemetryには、トンネルごとの外側IP、UPかDOWNか、BGPで受け取った経路数が入ります。拠点側のswanctl --list-sasでESTABLISHEDとINSTALLEDが見えていて、AWS側がDOWNなら、経路かセキュリティグループの問題に絞れます。

AzureとAWSをSite-to-Site VPNで直結するときのIPsecポリシー

クラウド間を直接つなぐ場合、拠点側ルーターの役をもう一方のクラウドが担います。組み合わせとして多いAzureとAWSで、揃える値を確認します。

Azure CLIでAWS側と暗号・寿命を揃えるIPsecポリシーの設定

Azureの接続にカスタムポリシーを付け、DHグループ2の既定と27,000秒の寿命を上書きします。値は前章でAWS側に設定したものと同じ組み合わせです。

az network vpn-connection ipsec-policy add \
  --resource-group rg-hybrid \
  --connection-name to-aws-tun1 \
  --ike-encryption AES256 --ike-integrity SHA384 \
  --dh-group ECP384 \
  --ipsec-encryption GCMAES256 --ipsec-integrity GCMAES256 \
  --pfs-group ECP384 \
  --sa-lifetime 3600 --sa-max-size 102400000

Azure CLIのipsec-policyリファレンスにあるとおり、ポリシーは一部だけ指定できず、全項目をそろえて渡す必要があります。ECP384に対応するのは、AWSのDHグループ20です。--sa-lifetimeはフェーズ2の寿命で、AWSの上限3,600秒に合わせています。

BGPのASN重複とAPIPAの予約範囲で詰まるクラウド間接続の設定箇所

BGPで経路を交換する構成で確認するのは、Azure固有の2つの制約です。MicrosoftのAzureとAWSのBGP接続チュートリアルによれば、AWS側のトンネル内側CIDRは、Azureが予約する169.254.21.0〜169.254.22.255の範囲に置く必要があります。AWSが/30の1番目、Azureが2番目のアドレスを使います。

もう1つは冗長構成です。アクティブ/パッシブのAzure VPNゲートウェイはカスタムのAPIPAアドレスを1つしか持てないため、AWSの2本のトンネルを両方使うにはアクティブ/アクティブが必要です。チュートリアルの完成形は、Azure側にローカルネットワークゲートウェイ4つと接続4つ、AWS側にカスタマーゲートウェイ2つとトンネル計4本という構成になります。ASNは両端で異なる値にします。

Site-to-Site VPNを採用する条件と専用線・閉域網へ切り替える判断

最後に、この方式で止めてよい場面と、別の手段へ移るべき場面を言い切ります。

帯域1.25Gbpsと可用性99.9%台で足りる業務ならVPNで止める

AWSの標準トンネルは1本1.25Gbps、Google CloudのClassic VPNのSLAは99.9%、HA VPNでも構成によって99.99%または99.9%です。拠点から業務システムを使う、夜間にバックアップを送る、といった用途ならこの範囲に収まり、専用線の月額や調達期間をかける理由はありません。

インターネット回線の品質に左右されることは受け入れる前提です。遅延の揺れが業務を止める用途、たとえば基幹DBへの同期書き込みや音声の中継には向きません。

拠点増加時に専用線・閉域網を検討すべき帯域・遅延・運用負荷の3つの兆候

次のどれかに当てはまったら、VPNの本数を増やす前に別手段を比べてください。

大容量トンネルやECMPで複数本を束ねても、ピーク時の帯域が足りない
通信の遅延に上限を約束する必要がある（SLAを顧客と結んでいる）
鍵の寿命やMTUの不一致による切断を、拠点ごとに追いかける運用が回らなくなった

AWSならDirect Connectの専用線接続、AzureならExpressRouteのSKU選定が次の候補で、Site-to-Site VPNはその予備経路として残す構成が一般的です。AWS単体で月額がどう動くかはAWS VPNの料金実額で試算できます。複数クラウドと拠点をまたぐ経路設計やIKE設定の突き合わせを外部に任せたい場合は、一創のAWS・Google Cloud・Azureインフラ構築で要件整理から支援しています。

よくある質問

Site-to-Site VPNの構築と運用でよく受ける質問をまとめました。

Site-to-Site VPNとリモートアクセスVPNの違いは何ですか？

Site-to-Site VPNはネットワーク同士をつなぎ、拠点の端末はVPNを意識せずに相手側へ通信します。リモートアクセスVPNは端末ごとにクライアントソフトで接続します。AWSではClient VPNが後者に当たり、端末単位の課金と認証の設計が別途必要です。拠点がまとまっていればSite-to-Site、在宅など端末が散らばるならリモートアクセスが基本です。

トンネルが1時間ごとに数秒切れるのはなぜですか？

フェーズ2の鍵更新のタイミングで起きているなら、両端の寿命の食い違いを疑います。AWSのフェーズ2既定は3,600秒で、相手が27,000秒のAzure既定や独自値のままだと、更新の主導権が揃わず瞬断が出ることがあります。両端の寿命を短い側に揃え、拠点側の寿命をやや短くして先に更新させるのが確実です。

拠点側ルーターがNAT配下でも接続できますか？

できます。IKEv2はNATを検出するとUDP 4500番へ切り替えてESPをカプセル化します（NAT-T）。ただしヘッダが増える分、AWSの推奨MTUはAES-GCMで1,446から1,438バイトへ下がり、MSSも1,398バイトにする必要があります。AWSの大容量トンネルは固定IPを持つカスタマーゲートウェイに限られる点にも注意してください。

BGPと静的ルーティングはどちらを選ぶべきですか？

拠点が複数ある、または将来増えるならBGPです。AWSでは静的ルーティングだとECMPで帯域を積み増せず、Google CloudのHA VPNはBGPしか選べません。静的でよいのは、拠点が1つでネットワークの追加予定がなく、ルーターがBGPを話せない場合に限られます。

トンネルの状態を監視するには何を見ればよいですか？

AWSではCloudWatchのTunnelStateメトリクスと、describe-vpn-connectionsのVgwTelemetryで各トンネルのUPとDOWNが取れます。IKEの交渉やDPDの記録はSite-to-Site VPNログをCloudWatch Logsへ出すと追えます。2本のうち片方だけDOWNが続く状態は冗長が失われているので、通信が通っていても警報の対象にしてください。