スポーク管理の概要

このページでは、Virtual Private Cloud（VPC）スポーク管理者の視点からスポーク管理の概要について説明します。

Network Connectivity Center ハブと VPC スポークが同じプロジェクトにある場合、VPC スポーク管理者には、そのプロジェクトに対して次の両方の Identity and Access Management（IAM）バインディングが必要になります。

Network Connectivity Center ハブと VPC スポークが異なるプロジェクトにある場合、IAM ポリシーに次のバインディングが必要です。

前述の事前定義ロールと同じ権限がカスタムロールに含まれている場合は、カスタムロールを使用することもできます。

VPC ネットワークと Network Connectivity Center ハブが異なるプロジェクトにある場合、VPC スポーク管理者はスポークの提案を作成して、VPC ネットワークがハブに参加するようにリクエストする必要があります。提案はハブ管理者が確認します。ハブ管理者が提案を承認すると、VPC ネットワークがハブに接続されます。ハブ管理者は、スポークの提案を拒否することもできます。スポーク管理者は、VPC スポークの提案のステータスを常に確認できます。

詳しくは、以下のセクションをご覧ください。

サブネット ルートの一意性

VPC ネットワーク ピアリングと同様に、Google Cloud では Network Connectivity Center ハブに接続された VPC スポーク間でサブネット IP アドレス範囲の競合が禁止されています。次のいずれかに該当する場合、サブネット IP アドレス範囲は別のサブネット IP アドレス範囲と競合します。

  • ある VPC ネットワーク内のサブネット IP アドレス範囲が、別の VPC ネットワークのサブネット IP アドレス範囲と完全に一致している。
  • ある VPC ネットワークのサブネット IP アドレス範囲が、別の VPC ネットワーク内のサブネット IP アドレス範囲内に収まる。
  • ある VPC ネットワークのサブネット IP アドレス範囲に、別の VPC ネットワークのサブネット IP アドレス範囲が含まれている。

VPC スポークは、競合するサブネット IP アドレス範囲を同じ Network Connectivity Center ハブにエクスポートできません。Google Cloud CLI の exclude-export-ranges フラグまたは API の excludeExportRanges フィールドを使用すると、共有されたサブネット IP アドレス範囲の VPC スポークから Network Connectivity Center ハブへのエクスポートを防ぐことができます。たとえば、同じ Network Connectivity Center ハブに接続する 2 つの VPC ネットワークがあるとします。

  • 最初の VPC ネットワークには、プライマリ内部 IPv4 アドレス範囲が 100.64.0.0/16 のサブネットがあり、これは 100.64.0.0/16 のサブネット ルートになります。
  • 2 番目の VPC ネットワークには、セカンダリ内部 IPv4 アドレス範囲が 100.64.0.0/24 のサブネットがあり、これは 100.64.0.0/24 のサブネット ルートになります。

100.64.0.0/24 は 100.64.0.0/16 に収まるため、2 つのサブネット ルートのサブネット IP アドレス範囲が競合します。競合を解決しない限り、両方のネットワークを VPC スポークとして同じ Network Connectivity Center ハブに接続することはできません。競合を解決するには、次のいずれかの方法を使用できます。

  • 最初の VPC ネットワークをハブに接続するときに 100.64.0.0/16 IP アドレス範囲を除外するか、2 番目の VPC ネットワークをハブに接続するときに 100.64.0.0/24 IP アドレス範囲を除外します。
  • 各 VPC ネットワークを接続するときに、100.64.0.0/16 または RFC 6598 スペース全体（100.64.0.0/10）を除外します。

VPC ネットワーク ピアリングのサブネット ルートの操作

ピアリング サブネット ルートは、VPC ネットワーク ピアリングを使用して接続された VPC ネットワーク間で交換されるルートです。Network Connectivity Center ハブに接続された VPC スポーク間でピアリング サブネット ルートが交換されることはありませんが、ピアリング サブネット ルートを考慮する必要があります。各 VPC スポークの観点からは、すべてのローカル サブネット ルート、インポートされたピアリング サブネット ルート、インポートされた Network Connectivity Center のサブネット ルートの競合は許可されていません。

このコンセプトを理解するために、次の構成について考えてみましょう。

  • VPC ネットワーク net-a は、Network Connectivity Center ハブに接続された VPC スポークです。
  • VPC ネットワーク net-b は、同じ Network Connectivity Center ハブに接続された VPC スポークです。
  • VPC ネットワーク net-b と net-c は、VPC ネットワーク ピアリングを使用して相互に接続されています。

100.64.0.0/24 のローカル サブネット IP アドレス範囲が net-c に存在するとします。これにより、net-c にローカル サブネット ルートが作成され、net-b にピアリング サブネット ルートが作成されます。100.64.0.0/24 IP アドレス範囲のピアリング サブネット ルートは Network Connectivity Center ハブにエクスポートされませんが、net-b に存在するため、net-b は、100.64.0.0/24 と完全に一致する宛先、100.64.0.0/24 内に収まる宛先、または 100.64.0.0/24 を含む宛先を持つ Network Connectivity Center ルートをインポートできません。したがって、競合する範囲をエクスポートしないように net-a を構成しない限り、100.64.0.0/24、100.64.0.0/25、100.64.0.0/16 のローカル サブネット ルートは net-a に存在できません。

サブネット ルートを示すルートテーブル

Google Cloud では、VPC スポークからインポートされた Network Connectivity Center のサブネット ルートが 2 つのルートテーブルに表示されます。

次のいずれかの条件を満たすと、Google Cloud は各 VPC スポークの VPC ネットワーク ルートテーブルと Network Connectivity Center ハブ ルートテーブルを自動的に更新します。

VPC ネットワーク ルートテーブルでは、他の VPC スポークからインポートされた各ルートは、ネクストホップが Network Connectivity Center ハブの Network Connectivity Center サブネット ルートとして表示されます。これらの Network Connectivity Center のサブネット ルートの名前は、ncc-subnet-route- 接頭辞で始まります。インポートされた Network Connectivity Center サブネット ルートの実際のネクストホップを確認するには、Network Connectivity Center ハブのルートテーブルを表示するか、サブネット ルートを Network Connectivity Center ハブにエクスポートする VPC スポークの VPC ネットワーク ルートテーブルを表示します。

VPC ルートの詳細については、VPC ドキュメントのルートをご覧ください。

次のステップ