Cloud VPN

解決する課題

オンプレミスのデータセンターやオフィス、あるいは他のクラウド環境と、Google Cloud の VPC ネットワークを、インターネット越しに暗号化して安全に相互接続したいというニーズに応えます。

• 拠点と VPC のプライベート IP 同士を暗号化したトンネルで接続したい
• 専用線（相互接続）を引くほどではないが安全なハイブリッド接続が必要
• 単一トンネルの障害でも通信を止めたくない、高い可用性を確保したい
• 拠点側のサブネット追加に追従して経路を動的に交換したい

主要概念と用語

• Cloud VPN ゲートウェイ: Google Cloud 側の VPN 終端点。HA VPN ゲートウェイは2つのインターフェース（それぞれ別の外部 IP）を持ち、冗長構成を前提とする
• ピア VPN ゲートウェイ: 拠点側（オンプレミスや他クラウド）の VPN 装置を表すリソース。物理ルーターやソフトウェア VPN を指す
• VPN トンネル: 2つのゲートウェイ間に張る IPsec の暗号化通路。HA VPN では複数本を張って冗長化する
• HA VPN（高可用 VPN）: 冗長なトンネル構成で高い可用性を目標とするモード。Cloud Router との BGP 連携が前提
• Classic VPN: 単一インターフェースの旧来モード。静的ルートまたはポリシーベース／動的ルートに対応するが、HA VPN より可用性目標が低い
• Cloud Router: BGP を話すマネージドルーター。VPN トンネル経由で拠点と動的に経路を交換する。HA VPN とは事実上セットで使う
• IKE と IPsec: 鍵交換（IKE バージョン1または2）で安全な経路を確立し、IPsec ESP で通信を暗号化・認証する
• 動的ルーティング vs 静的ルーティング: 動的は BGP で経路を自動学習、静的は対向サブネットを手動定義する方式

仕様・制限・クォータ

• HA VPN の可用性目標: 冗長なトンネルを推奨構成どおりに張った場合、ゲートウェイ単位で高い可用性 SLA が提供される。Classic VPN は SLA の水準が異なる
• 暗号化方式: IKEv1／IKEv2 に対応し、IPsec による暗号化・整合性チェックを行う。鍵は**事前共有鍵（PSK）**で双方を合わせる
• ルーティング: HA VPN は BGP による動的ルーティングが前提。Classic VPN では静的ルートやポリシーベースも選べる
• 冗長性の要件: HA VPN の SLA は、片側だけでなく両インターフェースにトンネルを構成し、ピア側も冗長にすることで満たされる
• スループット: トンネルあたりの帯域には上限の目安があり、必要帯域が大きい場合は複数トンネルへ分散するか、相互接続（Interconnect）を検討する
• クォータ: プロジェクト／リージョンごとにゲートウェイ数・トンネル数などの上限があり、引き上げ申請が可能
• MTU の考慮: IPsec のオーバーヘッドにより実効 MTU が小さくなるため、フラグメント化や MSS クランプの考慮が必要

内部の仕組み

Cloud VPN は、Google Cloud 側の VPN ゲートウェイと拠点側のピアゲートウェイの間に、インターネット経由で IPsec トンネルを確立します。まず IKE で双方が事前共有鍵を使って認証し合い、暗号化に使う鍵を交換します。確立後は、トンネルを流れる IP パケットが IPsec ESP で暗号化・認証され、外から中身が読めない状態で運ばれます。

• HA VPN ゲートウェイは2つのインターフェースを持ち、それぞれ別の外部 IP が割り当てられる。各インターフェースからトンネルを張ることで、片方の経路や対向装置の障害でも通信を継続できる
• 経路情報は Cloud Router の BGP で交換される。拠点側でサブネットを追加すると、その経路が BGP で広報され、VPC 側のルートテーブルに自動反映される（静的ルートの手動更新が不要）
• BGP セッションはトンネルごとに張られ、複数トンネルがある場合は ECMP（等コストマルチパス） で負荷分散やフェイルオーバーが行われる

設計パターン / ベストプラクティス

• HA VPN + Cloud Router（BGP） を標準構成とし、Classic VPN は新規では避ける
• 可用性を高めるなら、拠点側にも2台の VPN 装置を用意し、HA VPN の各インターフェースから別々の対向へトンネルを張る
• サブネットの増減に強くするため、静的ルートではなく BGP（動的ルーティング） を採用する
• 大きな帯域や安定した低遅延が要件なら、VPN ではなく Cloud Interconnect（専用線／パートナー） を検討し、VPN はバックアップ経路に回す
• 複数リージョンや複数拠点を束ねるなら、Network Connectivity Center でハブ＆スポーク的に管理する構成も選択肢になる
• フラグメント化によるパフォーマンス低下を避けるため、MSS クランプなどで実効 MTU に合わせる

運用・監視

• Cloud Monitoring でトンネルの状態（確立／切断）、送受信バイト数、トンネルあたりの稼働状況を監視する
• BGP セッションの状態（確立／未確立、学習経路数）を Cloud Router 側で確認し、経路が想定どおり交換されているかをチェックする
• トンネルが切れる場合は、事前共有鍵の不一致・IKE バージョン／暗号スイートの相違・ファイアウォールでの UDP 500／4500 と ESP の遮断を疑う
• トンネル数・経路数が想定外に増減したらアラートを設定し、片側トンネル障害を早期に検知する
• 拠点側装置のメンテナンス時にも通信を維持できるよう、フェイルオーバーの実挙動を定期的に試験する

コスト

課金は「VPN トンネルの稼働時間（トンネル単位の時間課金）」と「トンネルを通過した下り（外向き）通信量」が基本です。HA VPN では冗長のためトンネル本数が増える分、トンネル課金も増える点に注意します。

セキュリティ

• 通信は IPsec ESP で暗号化・整合性保護されるため、インターネット経由でも盗聴・改ざんに強い
• 事前共有鍵（PSK）は十分に長くランダムにし、Secret Manager 等で安全に管理する。鍵の使い回しや弱い鍵は避ける
• IKE は可能なら IKEv2 を選び、強度の高い暗号スイートで合意する
• VPC 側のファイアウォールルールで、トンネル経由で到達できる範囲を最小権限に絞る
• 拠点側でも UDP 500／4500（IKE／NAT-T）と ESP のみを許可し、不要なポートは開けない
• 監査の観点では、トンネル確立・切断や設定変更を Cloud Audit Logs で追跡する

Well-Architected の観点

• 信頼性（Reliability）: HA VPN の冗長トンネルと BGP による自動フェイルオーバーで、単一障害点を排除する。拠点側の冗長化も含めて初めて高可用となる
• セキュリティ（Security）: IPsec による暗号化、強い事前共有鍵、最小権限のファイアウォール、監査ログで多層に保護する
• コスト最適化: 冗長度と帯域要件に見合ったトンネル本数に抑え、大容量・常時接続なら専用線との費用対効果を比較する
• 運用性: トンネルと BGP の状態を監視し、フェイルオーバーを定期試験して、障害時の挙動を事前に把握しておく

試験で問われるポイント

関連サービス・比較

VPN は手軽だが帯域・遅延がインターネット依存です。安定帯域・低遅延が必要なら専用線型の Cloud Interconnect を比較検討します。AWS では Cloud VPN が Site-to-Site VPN、Cloud Interconnect が Direct Connect に対応します。

ハンズオン / CLI例

# 1. HA VPN ゲートウェイを作成（指定 VPC・リージョン）
gcloud compute vpn-gateways create ha-vpn-gw \
  --network=my-vpc --region=asia-northeast1

# 2. 拠点側（ピア）ゲートウェイを登録（対向の外部 IP）
gcloud compute external-vpn-gateways create peer-gw \
  --interfaces=0=203.0.113.10

# 3. Cloud Router を作成（BGP の ASN を指定）
gcloud compute routers create vpn-router \
  --network=my-vpc --region=asia-northeast1 --asn=65001

# 4. VPN トンネルを作成（インターフェース0、IKEv2、事前共有鍵）
gcloud compute vpn-tunnels create tunnel-0 \
  --peer-external-gateway=peer-gw \
  --peer-external-gateway-interface=0 \
  --region=asia-northeast1 \
  --ike-version=2 \
  --shared-secret=REPLACE_WITH_STRONG_PSK \
  --router=vpn-router \
  --vpn-gateway=ha-vpn-gw \
  --interface=0

# 5. BGP セッション（Cloud Router のインターフェースとピア）を構成
gcloud compute routers add-interface vpn-router \
  --interface-name=if-tunnel-0 \
  --vpn-tunnel=tunnel-0 --region=asia-northeast1
gcloud compute routers add-bgp-peer vpn-router \
  --peer-name=bgp-peer-0 \
  --interface=if-tunnel-0 \
  --peer-asn=65002 --region=asia-northeast1