複数の Google Cloud プロジェクト、ハイブリッド VPN はひとつ? まず決める
共有 VPC、ピアリング、接続ハブはそれぞれ別の所有権の問いに答えます。プロジェクトごとに VPN を導入する前に、ネットワークの境界を選びましょう。
複数の Google Cloud プロジェクトがハイブリッド接続を必要とするとき、反射的にプロジェクトごとに VPN を置きたくなりますが、それはほとんどの場合に誤った形です。プロジェクトの所有権とパケットのルーティングは関連しつつ別の問題であり、有用なアーキテクチャは必要な管理上の境界を保ちながら、想定したプレフィックスにオフィスやデータセンターへの意図的な経路をひとつ与えます。これらの確認は、手戻りを避ける順序で、実際にどのネットワークモデルを望むのかを決めます。どれも議論を早く終わらせることができ、そこが要点です。
プロジェクトの境界は、自動的に専用トンネルを必要とするわけではありません。
共有される対象がネットワークかどうかを確認する
接続性ではなく所有権についての問いから始めますが、中央のネットワーク所有権がこれらのワークロードを支えられるでしょうか。答えがはいで組織に適切な構成があれば、ホストプロジェクトが VPC、サブネット、接続性を所有し、サービスプロジェクトは自らのアプリケーション リソースを所有します。その共有ネットワーク内の一つの Cloud VPN 接続が、想定したワークロードのプレフィックスにサービスを提供できます ただし、ルーティングとセキュリティのポリシーに従うことが条件です 。
関連付けが何をするのかを正確に押さえます。サービスプロジェクトを関連付けても、その既存の独立した VPC がホストネットワークに統合されるわけではなく、すべてのリソースが自動的に移動するわけでもありません。ワークロードの関連付け、権限、アドレス空間、DNS はすべてアーキテクチャの一部であり、設定の結果ではありません。チームは通常切り替えの最中にその違いに気づくため、関連付けはまず権限の変更、次にルーティングの変更として読んでください。
中央の所有権が関係チームに受け入れられない場合は、ここで止め、残りはピアリングまたはハブの設計として扱います。独立したネットワークのライフサイクルを必要とするグループに Shared VPC を押しつけると、技術的な名前を持つ政治的な問題が生じます。
独立した VPC が独立したままでいられるかを確認する
ピアリングは別々の VPC を保つため、独自のアドレス計画と独自の変更管理を求めるチームを引きつけます。落とし穴は、ピアリングが推移的でないことで、A から B、B から C のピアリングはそれ自体では B を経由した A から C へのルーティングを作りません。三つのプロジェクトが一つのハイブリッド宛先に到達する必要があるなら、ピアリングの連鎖ではなく、意図的な交換計画が必要です。
ハイブリッド到達性の共有は、文書化されたカスタムルートの交換と、想定した Cloud Router のアナウンスにも依存します。ピアリングの状態がアクティブであることはピアリングが存在することを示すだけで、双方が重視するプレフィックスがこれまでエクスポートされたことを示すものではありません。ピアの両側でエクスポートされた範囲を、エクスポートを行う構成の中で確認し、ワークロードが実際に使うアドレスと比較します。そこでの不一致が、プレフィックスに到達できないままピアリングが健全に見える最も一般的な理由です。
何よりも先にアドレス計画を書きます。重複しない範囲、想定した各宛先へのルート、戻りのアナウンスという三つが、このモデルの生死を分ける成果物です。
ハブモデルがトポロジーに合うかを確認する
より大規模な、あるいは別の分割をした設計では、Google の Network Connectivity Center の概要 がハブとスポークのモデルを説明しています。図が示唆することではなく、現在のリリースが何を支えるか、つまりどの VPC とハイブリッドの組み合わせ、どのルートファミリー、どのポリシーを各スポーク種別が許すのかを読んでください。
アドレスファミリーを明示的に確認します。ほとんどのガイドの計画例は、これも含めて IPv4 を扱っており、あるスポーク種別に存在する機能が別の種別に変更なしで自動的に当てはまるわけではありません。環境がデュアルスタックなら、その問いはモデル選択に属し、後日の移行に属しません。
以下の表は三つのモデルの要約と、それぞれを決める問いです。
| Model | Network relationship | Planning question |
|---|---|---|
| Shared VPC | Service projects use subnets of a host project's VPC | Can central network ownership support these workloads? |
| VPC Network Peering | Independent VPCs exchange supported routes through explicit peers | Are direct peer and hybrid route exchanges sufficient? |
| Network Connectivity Center | Supported VPC and hybrid spokes join a managed hub | Does the required topology fit current routing and policy? |
ルーティングが与えないものを確認する
ルート交換は信頼を包括的に与えるものではありません。DNS 解決、ファイアウォールの許可、アプリケーションの認可はそれぞれの責任のままであり、ほとんどの組織ではそれぞれ別の所有者が構成します。到達性が認可を意味すると仮定する設計は、接続テストには通り、セキュリティレビューでは落ちます。
各モデルの DNS の筋書きも確認します。ゾーンと転送の取り決めは共有ネットワークとピアリングしたネットワークで異なるため、あるプロジェクトで解決するプライベート名が別のプロジェクトへルートをたどることはありません。
決定とその所有者を記録する
組織が共有ネットワークの所有者を求める場所では集中させ、ライフサイクルやポリシーが求める場所では VPC を分けたままにします。次に、サポートされる接続関係を選び、どれを選んだか、誰が共有ネットワークを所有するか、各プロジェクトが何をアナウンスできるかを書き留めます。
プロジェクトを数えてそれぞれに VPN を買うことは、その所有権の決定の代わりにはなりません。それは同じ決定を、請求書とルーティングテーブルを引き継ぐ人が後から下すものです。