Panoramica dell'amministrazione dello spoke

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

Se l'hub di Network Connectivity Center e lo spoke VPC si trovano nello stesso progetto, gli amministratori dello spoke VPC devono avere entrambe le seguenti associazioni Identity and Access Management (IAM) per quel progetto:

Se l'hub di Network Connectivity Center e lo spoke VPC si trovano in progetti diversi, i criteri IAM devono avere le seguenti associazioni.

Gli amministratori dello spoke VPC devono avere entrambe le seguenti associazioni IAM nel progetto che contiene la rete VPC (spoke):
- Il ruolo Amministratore rete Compute (roles/compute.networkAdmin).
- Il ruolo di amministratore spoke di Network Connectivity Center (roles/networkconnectivity.spokeAdmin).
Gli amministratori di spoke VPC devono inoltre avere entrambe le seguenti associazioni IAM sull'hub di Network Connectivity Center o sul progetto che contiene l'hub di Network Connectivity Center:
- Il ruolo Utente gruppo Network Connectivity Center (roles/networkconnectivity.groupUser).
- Il ruolo Hub e Visualizzatore spoke di Network Connectivity Center (roles/networkconnectivity.hubViewer).

Puoi anche utilizzare i ruoli personalizzati, purché includano le stesse autorizzazioni dei ruoli predefiniti elencati in precedenza.

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

Per ulteriori informazioni, consulta le sezioni seguenti.

Unicità della route subnet

Analogamente al peering di rete VPC, Google Cloud vieta i conflitti di intervalli di indirizzi IP di subnet tra spoke VPC connessi a un hub di Network Connectivity Center. Un intervallo di indirizzi IP di una subnet è in conflitto con un altro intervallo di indirizzi IP di 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 una 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 di Network Connectivity Center. Puoi utilizzare il flag exclude-export-ranges in Google Cloud CLI o nel campo excludeExportRanges nell'API per impedire che un intervallo di indirizzi IP di una subnet venga condiviso da uno spoke VPC in un hub di Network Connectivity Center. Ad esempio, supponiamo che tu voglia connettere due reti VPC allo stesso hub di Network Connectivity Center:

La prima rete VPC ha una subnet il cui intervallo di indirizzi IPv4 interni principali è 100.64.0.0/16, il che genera una route di subnet per 100.64.0.0/16.
La seconda rete VPC ha una subnet con un intervallo di indirizzi IPv4 interni secondari pari a 100.64.0.0/24, che genera 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 di Network Connectivity Center 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 di peering di rete VPC

Le route di subnet di peering sono quelle che vengono scambiate tra reti VPC connesse tramite peering di rete VPC. Anche se le route di subnet di peering non vengono mai scambiate tra spoke VPC connessi a un hub di Network Connectivity Center, devi comunque prendere in considerazione le route di subnet di peering. Dal punto di vista di ogni spoke VPC, tutte le route di subnet locali, le route di subnet di peering importate e le route di subnet di Network Connectivity Center importate non possono entrare in conflitto.

Per illustrare questo concetto, considera la seguente configurazione:

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

Supponiamo che esista un intervallo di indirizzi IP di una subnet locale per 100.64.0.0/24 in net-c. Questo crea una route di subnet locale in net-c e una route di 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 di Network Connectivity Center, la sua esistenza in net-b impedisce a net-b di importare una route di Network Connectivity Center 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 non configuri net-a in modo da non esportare l'intervallo in conflitto.

Tabelle di route che mostrano route di subnet

Google Cloud mostra le route di subnet di Network Connectivity Center importate dagli spoke VPC in due tabelle di route:

La tabella delle route dell'hub di Network Connectivity Center.
La tabella delle route di rete VPC per ogni rete VPC (spoke).

Google Cloud aggiorna automaticamente la tabella di route di rete VPC di ogni spoke VPC e la tabella di route dell'hub di Network Connectivity Center quando è soddisfatta una delle seguenti condizioni:

Quando esegui un'attività del ciclo di vita delle route di subnet, ad esempio l'aggiunta o l'eliminazione di una subnet.
Quando gli spoke VPC vengono aggiunti o rimossi dall'hub.

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

Per ulteriori informazioni sulle route VPC, consulta Route nella documentazione di VPC.

Passaggi successivi

Per creare hub e spoke, consulta Utilizzare hub e spoke.
Per creare uno spoke in un progetto diverso dall'hub, consulta Proporre uno spoke VPC in un progetto diverso.
Per visualizzare un elenco dei partner le cui soluzioni sono integrate con Network Connectivity Center, consulta la pagina Partner di Network Connectivity Center.
Per trovare soluzioni ai problemi comuni, consulta la pagina Risoluzione dei problemi.
Per maggiori dettagli sull'API e sui comandi gcloud, consulta API e riferimenti.