Questa pagina fornisce una panoramica dal punto di vista di un amministratore spoke Virtual Private Cloud (VPC).
Se l'hub Network Connectivity Center 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:
Il ruolo Amministratore rete Compute (
roles/compute.networkAdmin).Il ruolo Amministratore spoke di Network Connectivity Center (
roles/networkconnectivity.spokeAdmin).
Se l'hub Network Connectivity Center e lo spoke VPC si trovano in progetti diversi, le norme IAM devono avere i seguenti binding.
Gli amministratori degli spoke VPC devono disporre di entrambi i seguenti binding IAM nel progetto che contiene la rete VPC (spoke):
Gli amministratori degli spoke VPC devono disporre anche dei seguenti binding IAM sull'hub Network Connectivity Center o sul progetto che contiene l'hub Network Connectivity Center:
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 Network Connectivity Center si trovano in progetti diversi, un amministratore spoke VPC deve creare una proposta di spoke per richiedere che una rete VPC si unisca 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 dello 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 hub.
Per saperne di più, consulta le sezioni seguenti.
- Proponi uno spoke VPC in un progetto diverso
- Controllare lo stato di un VPC spoke
- Visualizza la tabella route VPC
- Panoramica degli spoke VPC
- Modificare gli intervalli di indirizzi delle subnet esportate (Anteprima)
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 Network Connectivity Center. 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 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 rientra in un intervallo di indirizzi IP di una 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 Network Connectivity Center. 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 Network Connectivity Center. Ad esempio, supponiamo di avere due reti VPC che vuoi connettere allo stesso hub Network Connectivity Center:
- 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, 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 Network Connectivity Center, a meno che tu non risolva 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 di subnet di peering sono quelle scambiate tra le reti VPC connesse tramite peering di rete VPC. Anche se le route subnet di peering non vengono mai scambiate tra gli spoke VPC connessi a un hub Network Connectivity Center, devi comunque prenderle in considerazione. Dal punto di vista di ogni spoke VPC, tutte le route delle subnet locali, le route delle subnet in peering importate e le route delle subnet di Network Connectivity Center importate non possono essere in conflitto.
Per illustrare questo concetto, considera la seguente configurazione:
- La rete VPC
net-aè uno spoke VPC connesso a un hub Network Connectivity Center. - La rete VPC
net-bè uno spoke VPC connesso allo stesso hub Network Connectivity Center. - Le reti VPC
net-benet-csono 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 subnet locale in net-c e una route 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 Network Connectivity Center, la sua esistenza in net-b impedisce a net-b di importare una route 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 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 di Network Connectivity Center importate dagli spoke VPC in due tabelle di route:
- La tabella di routing dell'hub Network Connectivity Center.
- La tabella di routing 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 Network Connectivity Center quando si verifica una delle seguenti condizioni:
- Quando esegui un'attività del ciclo di vita di una 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 di routing della rete VPC, ogni route importata da altri spoke VPC viene visualizzata come route di subnet Network Connectivity Center il cui hop successivo è l'hub 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 hub di Network Connectivity Center oppure puoi visualizzare la tabella delle route di rete VPC dello spoke VPC che esporta la route di subnet nell'hub Network Connectivity Center.
Per saperne di più sulle route VPC, consulta la sezione Route nella documentazione di VPC.
Passaggi successivi
- Per creare hub e spoke, vedi Utilizzo di hub e spoke.
- Per creare uno spoke in un progetto diverso dall'hub, consulta Proponi uno spoke VPC in un progetto diverso.
- Per visualizzare un elenco dei 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 sull'API e sui comandi
gcloud, consulta API e riferimenti.