Panoramica dell'amministrazione dei spoke

Questa pagina fornisce una panoramica dal punto di vista di un amministratore spoke Virtual Private Cloud (VPC).

Se l'hub Network Connectivity Center (NCC) e lo spoke VPC si trovano nello stesso progetto, gli amministratori dello spoke VPC devono disporre di entrambi i seguenti binding Identity and Access Management (IAM) per il progetto:

Se l'hub NCC e lo spoke VPC si trovano in progetti diversi, le policy IAM devono avere i seguenti binding.

Puoi anche utilizzare ruoli personalizzati, a condizione che includano le stesse autorizzazioni dei ruoli predefiniti elencati in precedenza.

Quando una rete VPC e l'hub NCC si trovano in progetti diversi, un amministratore spoke VPC deve creare una proposta di spoke per richiedere l'aggiunta di una rete VPC all'hub. Un amministratore dell'hub esamina la proposta. Se l'amministratore dell'hub accetta la proposta, la rete VPC viene connessa all'hub. Un amministratore dell'hub può anche rifiutare le proposte degli spoke. Gli amministratori degli spoke possono controllare lo stato di una proposta di spoke VPC in qualsiasi momento.

Puoi proporre aggiornamenti a uno spoke VPC esistente per modificare l'insieme di intervalli di subnet esportati nelle tabelle delle route dell'hub.

Per saperne di più, consulta le sezioni seguenti.

Unicità della route subnet

Analogamente al peering di rete VPC, Google Cloud vieta i conflitti di intervalli di indirizzi IP delle subnet tra gli spoke VPC connessi a un hub NCC. Un intervallo di indirizzi IP della subnet è in conflitto con un altro intervallo di indirizzi IP della subnet quando si verifica una delle seguenti condizioni:

  • Un intervallo di indirizzi IP di subnet in una rete VPC corrisponde esattamente a un intervallo di indirizzi IP di subnet in un'altra rete VPC.
  • Un intervallo di indirizzi IP di subnet in una rete VPC rientra in un intervallo di indirizzi IP di subnet in un'altra rete VPC.
  • Un intervallo di indirizzi IP di subnet in una rete VPC contiene un intervallo di indirizzi IP di subnet in un'altra rete VPC.

Gli spoke VPC non possono esportare intervalli di indirizzi IP di subnet in conflitto nello stesso hub NCC. Puoi utilizzare il flag exclude-export-ranges in Google Cloud CLI o il campo excludeExportRanges nell'API per impedire la condivisione di un intervallo di indirizzi IP di subnet da uno spoke VPC a un hub NCC. Ad esempio, supponiamo di avere due reti VPC che vuoi connettere allo stesso hub NCC:

  • La prima rete VPC ha una subnet il cui intervallo di indirizzi IPv4 interno principale è 100.64.0.0/16, il che comporta un percorso di subnet per 100.64.0.0/16.
  • La seconda rete VPC ha una subnet con un intervallo di indirizzi IPv4 interno secondario di 100.64.0.0/24, il che comporta una route di subnet per 100.64.0.0/24.

Le due route di subnet hanno intervalli di indirizzi IP di subnet in conflitto perché 100.64.0.0/24 rientra in 100.64.0.0/16. Non puoi connettere entrambe le reti come spoke VPC allo stesso hub NCC, a meno che non risolvi il conflitto. Per risolvere il conflitto, puoi utilizzare una delle seguenti strategie:

  • Escludi l'intervallo di indirizzi IP 100.64.0.0/16 quando colleghi la prima rete VPC all'hub oppure escludi l'intervallo di indirizzi IP 100.64.0.0/24 quando colleghi la seconda rete VPC all'hub.
  • Escludi 100.64.0.0/16 o l'intero spazio RFC 6598, 100.64.0.0/10, quando colleghi ogni rete VPC.

Interazione con le route di subnet del peering di rete VPC

Le route delle subnet di peering sono quelle scambiate tra le reti VPC connesse tramite il peering di rete VPC. Anche se le route delle subnet di peering non vengono mai scambiate tra gli spoke VPC connessi a un hub NCC, devi comunque prenderle in considerazione. Dal punto di vista di ogni VPC spoke, tutte le route di subnet locali, le route di subnet di peering importate e le route di subnet NCC importate non possono essere in conflitto.

Per illustrare questo concetto, considera la seguente configurazione:

  • La rete VPC net-a è un VPC spoke connesso a un hub NCC.
  • La rete VPC net-b è uno spoke VPC connesso allo stesso hub NCC.
  • Le reti VPC net-b e net-c sono connesse tra loro tramite il peering di rete VPC.

Supponiamo che in net-c esista un intervallo di indirizzi IP di subnet locale per 100.64.0.0/24. In questo modo viene creata una route della subnet locale in net-c e una route della subnet di peering in net-b. Anche se la route della subnet di peering per l'intervallo di indirizzi IP 100.64.0.0/24 non viene esportata nell'hub NCC, la sua esistenza in net-b impedisce a net-b di importare una route NCC la cui destinazione corrisponde esattamente a 100.64.0.0/24, rientra in 100.64.0.0/24 o contiene 100.64.0.0/24. Di conseguenza, non possono esistere route di subnet locali per 100.64.0.0/24, 100.64.0.0/25 o 100.64.0.0/16 in net-a a meno che tu non configuri net-a in modo che non esporti l'intervallo in conflitto.

Tabelle di routing che mostrano le route delle subnet

Google Cloud mostra le route subnet NCC importate dagli spoke VPC in due tabelle di route:

Google Cloud aggiorna automaticamente la tabella di routing della rete VPC di ogni VPC spoke e la tabella di routing dell'hub NCC quando si verifica una delle seguenti condizioni:

Nelle tabelle di route della rete VPC, ogni route importata da altri spoke VPC viene visualizzata come una route di subnet NCC il cui hop successivo è l'hub NCC. I nomi di queste route della subnet NCC iniziano con il prefisso ncc-subnet-route-. Per visualizzare l'hop successivo effettivo per una route di subnet NCC importata, puoi visualizzare la tabella delle route hub NCC oppure visualizzare la tabella delle route di rete VPC dello spoke VPC che esporta la route di subnet nell'hub NCC.

Per saperne di più sulle route VPC, consulta la sezione Route nella documentazione VPC.

Passaggi successivi