Questa pagina è stata tradotta dall'API Cloud Translation.

Panoramica dell'amministrazione dei spoke

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

Se l'hub e lo spoke VPC di Network Connectivity Center si trovano nello stesso progetto, gli amministratori dello spoke VPC devono disporre di entrambe le seguenti associazioni IAM nel 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 disporre di 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 dello spoke di Network Connectivity Center (roles/networkconnectivity.spokeAdmin).
Gli amministratori degli spoke VPC devono disporre anche di entrambe le seguenti associazioni IAM nell'hub Network Connectivity Center o nel progetto che contiene l'hub Network Connectivity Center:
- Il ruolo Utente gruppo Network Connectivity Center (roles/networkconnectivity.groupUser).
- Il ruolo Visualizzatore hub e spoke di Network Connectivity Center (roles/networkconnectivity.hubViewer).

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 di Network Connectivity Center si trovano in progetti diversi, un amministratore dello spoke VPC deve creare una proposta di spoke per richiedere l'unione 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 collegata all'hub. Un amministratore dell'hub può anche rifiutare le proposte dei raggi. Gli amministratori dello spoke possono controllare lo stato di una proposta di spoke VPC in qualsiasi momento.

Per ulteriori informazioni, consulta le sezioni seguenti.

Unicità della route della subnet

Come per il peering di rete VPC, Google Cloud vieta i conflitti di intervalli di indirizzi IP delle subnet tra gli 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 una subnet quando è vera una delle seguenti condizioni:

Un intervallo di indirizzi IP di una subnet in una rete VPC corrisponde esattamente a un intervallo di indirizzi IP di una subnet in un'altra rete VPC.
Un intervallo di indirizzi IP di una subnet in una rete VPC si inserisce in un intervallo di indirizzi IP di una 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 una subnet in un'altra rete VPC.

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

La prima rete VPC ha una subnet il cui intervallo di indirizzi IPv4 interno principale è 100.64.0.0/16, con una route della 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, che genera una route della subnet per 100.64.0.0/24.

Le due route di subnet hanno intervalli di indirizzi IP 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 o 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 di 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 collegati a un hub di Network Connectivity Center, devi comunque prendere in considerazione le route delle subnet di peering. Dal punto di vista di ogni spoke VPC, tutti i route delle subnet locali, i route delle subnet di peering importati e i route delle subnet di Network Connectivity Center importati 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 in net-c esista un intervallo di indirizzi IP di una subnet locale per 100.64.0.0/24. In questo modo viene creata una route per la subnet locale in net-c e una route per la subnet del peering in net-b. Anche se la route di 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, in net-a non possono esistere route di subnet locale per 100.64.0.0/24, 100.64.0.0/25 o 100.64.0.0/16 a meno che non configuri net-a in modo da non esportare l'intervallo in conflitto.

Tabelle route che mostrano le route delle subnet

Google Cloud mostra i route delle subnet di Network Connectivity Center importati dagli spoke VPC in due tabelle di route:

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

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

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

Nelle tabelle delle route della rete VPC, ogni route importata da altri spoke VPC viene visualizzata come route della subnet di Network Connectivity Center il cui hop successivo è l'hub di Network Connectivity Center. Questi percorsi delle sottoreti 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 o visualizzare la tabella delle route della rete VPC dello spoke VPC che esporta la route della subnet nell'hub di Network Connectivity Center.

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

Passaggi successivi

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