WEB問題集
正解：A
この問題の鍵は、「動的なルート交換（exchange routes dynamically）」という要件にあります。
1. なぜ A が正しいのか？
-
Cloud Router と BGP: Google Cloud において、オンプレミス環境と動的にルート情報を交換するためには、Cloud Router を使用し、BGP（Border Gateway Protocol） セッションを確立する必要があります。
-
HA VPN の要件: HA VPN（High Availability VPN）は、仕様として動的ルーティング（BGP）のみをサポートしています。静的ルートを使用することはできません。
Network Connectivity Center (NCC) のハブ＆スポーク トポロジを使用して、組織の VPC アーキテクチャを実装しています。
-
オンプレミスのルートを受信するための NCC ハイブリッド スポークが1つあります。
-
NCC スポークとして追加する必要がある VPC スポークが1つあります。
組織のクラウド環境で使用できるルーティング可能な IP スペースには制限があります (192.168.0.0/20)。NCC スポーク VPC は、us-east4 リージョンの Cloud Interconnect を介してオンプレミスに接続されています。オンプレミスの IP 範囲は 172.16.0.0/16 です。
複数の Google Cloud リージョン (us-west1、europe-central1、asia-southeast1) からオンプレミスのリソースにアクセスできるようにし、かつ使用する IP アドレスを最小限に抑える必要があります。何を行うべきですか？
正解：A
この問題のポイントは、「IP アドレスの節約」と「複数リージョンからの効率的なハイブリッド接続」の両立です。
1. なぜ A が正しいのか？
-
Private NAT の活用: クラウド側の IP アドレス空間 (192.168.0.0/20) が限られているため、各リージョンの個々のインスタンスに貴重な IP を割り当てるのではなく、NAT サブネット（/24など）に集約してオンプレミスと通信させるのが最も効率的です。
-
Export Include Policy: NCC の VPC スポークでは、デフォルトですべてのサブネットがハブに共有されます。特定の NAT サブネットだけをオンプレミス（ハイブリッドスポーク側）に伝えたい場合、
export include policyを使用して、広報するルートを明示的に絞り込むのが正解です。 -
グローバル動的ルーティング: Cloud Interconnect は us-east4 にありますが、他リージョン（us-west1 など）からその Interconnect を利用してオンプレミスと通信するためには、VPC ネットワークの動的ルーティング モードを「グローバル」にする必要があります。
クラウド環境の複数の VPC にまたがって複数の VM があり、インターネットエンドポイントへのアクセスが必要です。セキュリティポリシーにより、これらの VM にパブリック IP アドレスを割り当てることはできません。そのため、Cloud NAT を使用して送信インターネットアクセスを提供する計画を立てています。
VPC 内の各リージョンには複数のサブネットがあります。特定のサブネットのみが Cloud NAT を通じてインターネットにアクセスできるようにし、かつ他の管理者による意図しない設定ミスを回避し、Google の推奨プラクティスに準拠させる必要があります。何をすべきですか？
正解：B
この問題の最も重要なフレーズは、**「他の管理者による意図しない設定ミスを回避（avoid any unintentional configuration issues caused by other administrators）」**という点です。
1. なぜ B が正しいのか？
-
組織ポリシー (Organizational Policy) の力: ファイアウォールルールや個別の Cloud NAT 設定は、プロジェクトレベルの権限を持つ管理者によって変更されてしまう可能性があります。一方、組織ポリシー（特に
constraints/compute.restrictCloudNATUsage）を使用すると、組織レベルで「どのサブネットが Cloud NAT を使用できるか」を中央集権的に制限できます。これにより、個別のプロジェクト管理者が誤って禁止されたサブネットに対して NAT を有効にすることを防げます。 -
ガバナンス: 「Google 推奨プラクティス」において、大規模な環境でのガードレール設定には組織ポリシーの使用が推奨されます。
組織の Google Cloud 内に、異なるプロジェクトに属する5つの VPC があり、これらには高スループットの接続が必要です。各 VPC の IP アドレス使用状況を監査したところ、2つの VPC で以下の重複するサブネットが使用されていることが判明しました：240.0.0.0/16 と 240.128.0.0/24。
クラス E サブネット (240.0.0.0/4) は VPC 間接続を必要としませんが、それ以外のすべてのサブネットは互いに接続できる必要があります。これらの要件を満たすルーティング ソリューションをデプロイする必要があります。何をすべきですか？
正解：B
この問題のポイントは、「重複する IP アドレスがある状況で、いかに効率的かつスケーラブルに VPC 間を接続するか」です。
1. なぜ B が正しいのか？
-
スケーラビリティ: 5つの VPC を「フルメッシュ」で接続する場合、VPC ピアリングだと $n(n-1)/2$、つまり 10 本の接続を手動で管理する必要があります。Network Connectivity Center (NCC) を使えば、ハブに各 VPC をスポークとして繋ぐだけで全対全（メッシュ）の接続が容易に実現できます。
-
重複 IP の制御 (Exclude Filter): NCC の VPC スポークでは、特定のルートをハブに広報しないようにする export exclude filter が使えます。問題文にある「接続不要なクラス E 重複サブネット (
240.0.0.0/4)」を除外設定にすることで、IP 重複によるルーティングの競合（エラー）を回避しつつ、他の必要なサブネット同士の通信を確立できます。
オンプレミスネットワークへの HA VPN を確立しようとしていますが、接続が正常に確立されません。あなたは Google Cloud のネットワーク環境と、VPN デバイスとして機能するオンプレミスのファイアウォールの両方に対して完全な管理権限を持っています。
Google Cloud コンソールには「Negotiation failure（ネゴシエーション失敗）」および「BGP is down（BGPダウン）」と表示されています。Cloud Logging でログを確認したところ、以下のエントリが頻繁に記録されていました。
-
log name:
…/logs/cloud.googleapis.com%2Fipsec_events -
textPayload:
received NO_PROPOSAL_CHOSEN notify, no CHILD_SA built
Cloud Logging のエントリに基づいて、VPN の失敗をトラブルシューティングし、是正措置を講じる必要があります。何をすべきですか？
正解：B
この問題の決定的なヒントは、ログに含まれる NO_PROPOSAL_CHOSEN および no CHILD_SA built というメッセージです。
1. なぜ B が正しいのか？
-
NO_PROPOSAL_CHOSEN の意味: これは、IKE ネゴシエーションにおいて、提案された暗号化アルゴリズムやハッシュアルゴリズム（Proposal）が、相手側の設定と一致しなかったことを示します。
-
Phase 2 (CHILD_SA): IPsec において、
CHILD_SA（または単に SA）は Phase 2 で構築されるデータ通信用のトンネルを指します。ログに「no CHILD_SA built」とあるため、Phase 1（認証）は成功している可能性が高いですが、その後の Phase 2（暗号化スイートの合意）で失敗していることがわかります。 -
是正措置: オンプレミス側の Phase 2 設定（暗号化、整合性アルゴリズムなど）が Google Cloud のサポートしている仕様と合致しているか確認する必要があります。