Questo tutorial descrive come utilizzare il peering di rete VPC per eseguire il deployment di un'architettura hub e spoke.
Questo tutorial è rivolto agli ingegneri di rete cloud e ai professionisti delle operazioni che vogliono implementare un'architettura hub e spoke nel proprio ambiente Google Cloud utilizzando appliance centralizzate composte da macchine virtuali Compute Engine. In questo tutorial, eseguirai il deployment di queste macchine virtuali come gateway NAT, ma puoi utilizzare lo stesso approccio per altre funzioni, come i firewall di nuova generazione. Questo tutorial presuppone che tu abbia familiarità con le reti VPC e Compute Engine.
Architettura
In questa architettura, un insieme di reti VPC spoke comunica con l'esterno tramite una rete VPC hub in cui il traffico viene instradato attraverso un pool centralizzato di appliance, in questo caso gateway NAT (Network Address Translation). Le route pertinenti vengono esportate dalla rete VPC dell'hub nelle reti VPC spoke. I gateway NAT sono configurati come backend di un bilanciatore del carico interno con una nuova route predefinita, che dispone di un bilanciatore del carico di rete passthrough interno di Cloud Load Balancing come hop successivo.
Puoi ottenere lo stesso tipo di distribuzione del carico e disponibilità elevata utilizzando più route con routing a più percorsi a costo uguale (ECMP). Tuttavia, l'utilizzo del bilanciatore del carico di rete passthrough interno presenta i seguenti vantaggi:
- Il traffico viene inoltrato a istanze in stato integro solo quando utilizzi i controlli di integrità. Con ECMP, il traffico viene inoltrato a tutte le istanze attive a cui punta la route. L'utilizzo di un bilanciatore del carico di rete passthrough interno elimina la possibilità di route inutilizzate. Inoltre, non è necessario pulire le route quando le istanze vengono terminate o riavviate.
- Si verifica un failover potenzialmente più rapido perché puoi ottimizzare i timer dei controlli di integrità. Se utilizzi gruppi di istanze gestite e riparazione automatica, puoi comunque personalizzare i timer del controllo di integrità, ma vengono utilizzati per ricreare l'istanza, non per instradare il traffico.
Google offre inoltre Cloud NAT come servizio gestito, fornendo alta disponibilità senza gestione e intervento da parte degli utenti. Tuttavia, Cloud NAT non è supportato in questo caso d'uso perché la configurazione NAT non viene importata in una rete in peering.
Il seguente diagramma mostra la topologia creata in questo tutorial.
La topologia è composta da una rete VPC hub e due reti VPC spoke in peering con la rete VPC hub mediante peering di rete VPC. La rete VPC dell'hub ha due istanze del gateway NAT dietro un bilanciatore del carico di rete passthrough interno.
Una route predefinita statica (0/0 NAT-GW-ILB
) punta al bilanciatore del carico di rete passthrough interno come hop successivo. Questa route statica predefinita viene esportata tramite peering di rete VPC tramite route personalizzate.
Obiettivi
- Crea più reti VPC ed esegui il peering utilizzando un'architettura hub e spoke.
- Crea e configura gateway NAT nella rete VPC dell'hub.
- Imposta e configura il bilanciatore del carico di rete passthrough interno come hop successivo.
- Verifica la connettività dalle reti VPC spoke alla rete internet pubblica.
Costi
In questo documento vengono utilizzati i seguenti componenti fatturabili di Google Cloud:
Per generare una stima dei costi in base all'utilizzo previsto,
utilizza il Calcolatore prezzi.
Una volta completate le attività descritte in questo documento, puoi evitare la fatturazione continua eliminando le risorse che hai creato. Per ulteriori informazioni, consulta la pagina Pulizia.
Prima di iniziare
- Accedi al tuo account Google Cloud. Se non conosci Google Cloud, crea un account per valutare le prestazioni dei nostri prodotti in scenari reali. I nuovi clienti ricevono anche 300 $di crediti gratuiti per l'esecuzione, il test e il deployment dei carichi di lavoro.
-
Nella pagina del selettore di progetti della console Google Cloud, seleziona o crea un progetto Google Cloud.
-
Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.
-
Attiva l'API Compute Engine.
-
Nella pagina del selettore di progetti della console Google Cloud, seleziona o crea un progetto Google Cloud.
-
Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.
-
Attiva l'API Compute Engine.
-
Nella console Google Cloud, attiva Cloud Shell.
Nella parte inferiore della console Google Cloud viene avviata una sessione di Cloud Shell che mostra un prompt della riga di comando. Cloud Shell è un ambiente shell con Google Cloud CLI già installato e con valori già impostati per il progetto attuale. L'inizializzazione della sessione può richiedere alcuni secondi.
In questo tutorial eseguirai tutti i comandi da Cloud Shell.
Configurazione dell'ambiente
In Cloud Shell, assicurati di lavorare nel progetto Google Cloud che hai creato o selezionato. Sostituisci
project-id
con il tuo progetto Google Cloud.gcloud config set project project-id export PROJECT_ID=`gcloud config list --format="value(core.project)"`
Imposta la regione e la zona di computing predefinite.
gcloud config set compute/region us-central1 gcloud config set compute/zone us-central1-c export REGION=us-central1 export ZONE=us-central1-c
In questo tutorial, la regione è
us-central1
e la zona èus-central1-c
.
Creazione di reti e subnet VPC
In Cloud Shell, crea la rete VPC e la subnet dell'hub:
gcloud compute networks create hub-vpc --subnet-mode custom gcloud compute networks subnets create hub-subnet1 \ --network hub-vpc --range 10.0.0.0/24
Crea le reti VPC spoke, chiamate
spoke1-vpc
espoke2-vpc
, con una subnet ciascuna:gcloud compute networks create spoke1-vpc --subnet-mode custom gcloud compute networks create spoke2-vpc --subnet-mode custom gcloud compute networks subnets create spoke1-subnet1 \ --network spoke1-vpc --range 192.168.1.0/24 gcloud compute networks subnets create spoke2-subnet1 \ --network spoke2-vpc --range 192.168.2.0/24
Creare regole firewall nella rete VPC dell'hub e nelle reti VPC dello spoke. Queste regole consentono il traffico interno (TCP/80 e 443, UDP/53 e ICMP) dagli intervalli RFC 1918 specificati:
gcloud compute firewall-rules create hub-vpc-web-ping-dns \ --network hub-vpc --allow tcp:80,tcp:443,icmp,udp:53 \ --source-ranges 10.0.0.0/24,192.168.1.0/24,192.168.2.0/24 gcloud compute firewall-rules create spoke1-vpc-web-ping-dns \ --network spoke1-vpc --allow tcp:80,tcp:443,icmp,udp:53 \ --source-ranges 10.0.0.0/24,192.168.1.0/24 gcloud compute firewall-rules create spoke2-vpc-web-ping-dns \ --network spoke2-vpc --allow tcp:80,tcp:443,icmp,udp:53 \ --source-ranges 10.0.0.0/24,192.168.2.0/24
Crea le regole firewall nella rete VPC dell'hub e nelle reti VPC spoke per consentire a IAP per SSH di accedere a tutte le tue macchine virtuali:
gcloud compute firewall-rules create hub-vpc-iap \ --network hub-vpc --allow tcp:22 \ --source-ranges 35.235.240.0/20 gcloud compute firewall-rules create spoke1-vpc-iap \ --network spoke1-vpc --allow tcp:22 \ --source-ranges 35.235.240.0/20 gcloud compute firewall-rules create spoke2-vpc-iap \ --network spoke2-vpc --allow tcp:22 \ --source-ranges 35.235.240.0/20
Questo tutorial utilizza Identity-Aware Proxy (IAP) per SSH. Per maggiori informazioni, consulta Connessione a istanze che non hanno indirizzi IP esterni.
Crea una regola firewall per consentire i controlli di integrità per i gruppi di istanze con riparazione automatica nella rete VPC dell'hub:
gcloud compute firewall-rules create hub-vpc-health-checks \ --network hub-vpc --allow tcp:443 --target-tags nat-gw \ --source-ranges 130.211.0.0/22,35.191.0.0/16
Creazione delle istanze e delle route richieste
In Cloud Shell, crea il modello di istanza per il gateway NAT che ha uno script di avvio che configura il gateway NAT:
gcloud compute instance-templates create \ hub-nat-gw-ilbnhop-template \ --network hub-vpc \ --subnet hub-subnet1 \ --machine-type n1-standard-2 --can-ip-forward \ --tags nat-gw --scopes default,compute-rw \ --metadata startup-script='#! /bin/bash apt-get update # Enable IP forwarding: echo 1 > /proc/sys/net/ipv4/ip_forward echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/20-example.conf # Read VM network configuration: md_vm="http://metadata.google.internal/computeMetadata/v1/instance/" md_net="$md_vm/network-interfaces" nic0_gw="$(curl $md_net/0/gateway -H "Metadata-Flavor:Google")" nic0_mask="$(curl $md_net/0/subnetmask -H "Metadata-Flavor:Google")" nic0_addr="$(curl $md_net/0/ip -H "Metadata-Flavor:Google")" nic0_id="$(ip addr show | grep $nic0_addr | tail -c 5)" # Use a web server to pass the health check for this example. # In production, use a more complete test. sudo apt-get update sudo apt-get install apache2 -y sudo a2ensite default-ssl sudo a2enmod ssl echo "Example web page to pass health check" | \ tee /var/www/html/index.html sudo systemctl restart apache2 # Enable IP masquerading iptables -t nat -A POSTROUTING -o $nic0_id -j MASQUERADE'
Questo tutorial utilizza
n1-standard-2
come tipo di istanza, ma puoi utilizzare qualsiasi altro numero o dimensione di gateway che preferisci. Assicurati di considerare fattori come la larghezza di banda in uscita massima per VM.Crea un controllo di integrità HTTP:
gcloud compute health-checks create http nat-gw-ilbnhop-health-check \ --region us-central1 \ --port 80
Crea un gruppo di istanze a livello di regione con due istanze distribuite in una singola regione:
gcloud compute instance-groups managed create \ hub-nat-gw-ilbnhop-mig \ --region us-central1 --size=2 \ --template=hub-nat-gw-ilbnhop-template \ --health-check nat-gw-ilbnhop-health-check \ --initial-delay 15
In questo tutorial, il ritardo iniziale è impostato su 15 secondi. In un deployment in produzione, personalizza questa impostazione in base ai tuoi requisiti. Questo tutorial non utilizza i criteri di scalabilità automatica.
Crea un servizio di backend e aggiungi il gruppo di istanze:
gcloud compute backend-services create hub-nat-gw-ilbnhop-backend \ --load-balancing-scheme=internal \ --protocol=tcp \ --health-checks=nat-gw-ilbnhop-health-check gcloud compute backend-services add-backend \ hub-nat-gw-ilbnhop-backend \ --instance-group=hub-nat-gw-ilbnhop-mig \ --instance-group-region=us-central1
Crea una regola di forwarding:
gcloud compute forwarding-rules create \ hub-nat-gw-ilbnhop \ --load-balancing-scheme=internal \ --network=hub-vpc \ --subnet=hub-subnet1 \ --address=10.0.0.10 \ --ip-protocol=TCP \ --ports=all \ --backend-service=hub-nat-gw-ilbnhop-backend \ --backend-service-region=us-central1 \ --service-label=hub-nat-gw-ilbnhop
Anche se la regola di forwarding è definita solo con TCP, quando utilizzi il bilanciatore del carico di rete passthrough interno come hop successivo, la regola di forwarding inoltra tutto il traffico a tutte le porte sulle VM di backend. Il bilanciatore del carico di rete passthrough interno è un bilanciatore del carico a livello di regione.
Crea una nuova route con la regola di forwarding come hop successivo:
gcloud compute routes create hub-nat-gw-ilbnhop \ --network=hub-vpc \ --destination-range=0.0.0.0/0 \ --next-hop-ilb=hub-nat-gw-ilbnhop \ --next-hop-ilb-region=us-central1 \ --priority=800
Puoi specificare i tag di rete in modo che la route dell'hop successivo venga applicata solo alle istanze client configurate con il tag, ma i tag non vengono esportati o importati tramite peering di rete VPC.
Elimina la route predefinita dal VPC dell'hub:
export hub_default_route=$(gcloud compute routes list \ --format="value(name)" --filter="network:hub-vpc AND \ nextHopGateway:default-internet-gateway" | head -n 1) gcloud compute routes delete $hub_default_route -q
Crea una nuova route con tag per consentire il traffico solo dai gateway NAT:
gcloud compute routes create hub-default-tagged \ --network hub-vpc --destination-range 0.0.0.0/0 \ --next-hop-gateway default-internet-gateway \ --priority 700 --tags nat-gw
Elimina le route predefinite verso internet dal VPC di ogni spoke:
export spoke1_default_route=$(gcloud compute routes list \ --format="value(name)" --filter="network:spoke1-vpc AND \ nextHopGateway:default-internet-gateway") gcloud compute routes delete $spoke1_default_route -q export spoke2_default_route=$(gcloud compute routes list \ --format="value(name)" \ --filter="network:spoke2-vpc AND nextHopGateway:default-internet-gateway") gcloud compute routes delete $spoke2_default_route -q
In caso di conflitto tra le route locali e quelle importate, quelle locali hanno sempre la precedenza. Per maggiori informazioni, consulta Ordine di routing.
Crea le VM client:
gcloud compute instances create spoke1-client \ --subnet=spoke1-subnet1 --no-address \ --metadata startup-script='#! /bin/bash apt-get update apt-get install dnsutils -y' gcloud compute instances create spoke2-client \ --subnet=spoke2-subnet1 --no-address \ --metadata startup-script='#! /bin/bash apt-get update apt-get install dnsutils -y'
Creazione delle connessioni di peering di rete VPC
Il peering di rete VPC è bidirezionale, quindi deve essere definito su entrambe le estremità. Una rete VPC può essere in peering con più reti VPC, ma si applicano dei limiti. Per raggiungere la route predefinita tramite peering di rete VPC, utilizza la funzionalità importazione ed esportazione di route personalizzate tramite peering di rete VPC.
Per questo tutorial, creerai tutte le reti VPC nello stesso progetto Google Cloud.
In Cloud Shell, crea le connessioni VPC dalla rete VPC dell'hub alle reti VPC dello spoke con il flag di esportazione delle route abilitato:
gcloud compute networks peerings create hub-to-spoke1 \ --network hub-vpc --peer-network spoke1-vpc \ --peer-project $PROJECT_ID \ --export-custom-routes gcloud compute networks peerings create hub-to-spoke2 \ --network hub-vpc --peer-network spoke2-vpc \ --peer-project $PROJECT_ID \ --export-custom-routes
Crea una connessione di peering di rete VPC dalla rete VPC
spoke1
alla rete VPC dell'hub con il flag di importazione della route abilitato:gcloud compute networks peerings create spoke1-to-hub \ --network spoke1-vpc --peer-network hub-vpc \ --peer-project $PROJECT_ID \ --import-custom-routes
Crea una connessione di peering di rete VPC dalla rete VPC
spoke2
alla rete VPC dell'hub con il flag di importazione della route abilitato:gcloud compute networks peerings create spoke2-to-hub \ --network spoke2-vpc --peer-network hub-vpc \ --peer-project $PROJECT_ID \ --import-custom-routes
Verifica della propagazione e della connettività delle route
In Cloud Shell, verifica che le route statiche siano state create correttamente come parte degli script di avvio.
gcloud compute routes list --filter="network:hub-vpc"
Assicurati che le route
hub-default-tagged
ehub-nat-gw-ilbanhop
siano presenti nell'output:NAME NETWORK DEST_RANGE NEXT_HOP PRIORITY default-route-13a4b635b5eab48c hub-vpc 10.0.0.0/24 hub-vpc 1000 hub-default-tagged hub-vpc 0.0.0.0/0 default-internet-gateway 700 hub-nat-gw-ilbanhop hub-vpc 0.0.0.0/0 10.0.0.10 800 peering-route-3274f1257a9842a0 hub-vpc 192.168.2.0/24 hub-to-spoke2 1000 peering-route-798c5777f13094bc hub-vpc 192.168.1.0/24 hub-to-spoke1 1000
Verifica la tabella di routing
spoke1-vpc
per assicurarti che la route predefinita sia stata importata correttamente:gcloud compute routes list --filter="network:spoke1-vpc"
Assicurati che esista una route che inizi con
peering-route
con0.0.0.0/0
come valoreDEST_RANGE
nell'output:NAME NETWORK DEST_RANGE NEXT_HOP PRIORITY default-route-75f6ea8f5fc54813 spoke1-vpc 192.168.1.0/24 spoke1-vpc 1000 peering-route-6c7f130b860bfd39 spoke1-vpc 10.0.0.0/24 spoke1-to-hub 1000 peering-route-9d44d362f98afbd8 spoke1-vpc 0.0.0.0/0 spoke1-to-hub 800
Connettiti a uno dei client utilizzando SSH tramite IAP:
gcloud compute ssh spoke1-client --tunnel-through-iap
Verifica la connettività testando il DNS pubblico di Google tramite il gateway NAT:
sudo hping3 -S -p 80 -c 3 dns.google
Poiché il bilanciatore del carico di rete passthrough interno supporta i protocolli TCP e UDP, non puoi verificare la connettività internet con un ping basato su ICMP, perciò devi usare uno strumento come hping3.
L'output è simile al seguente:
HPING dns.google (eth0 8.8.4.4): S set, 40 headers + 0 data bytes len=44 ip=8.8.4.4 ttl=126 DF id=0 sport=80 flags=SA seq=0 win=65535 rtt=4.6 ms len=44 ip=8.8.4.4 ttl=126 DF id=0 sport=80 flags=SA seq=1 win=65535 rtt=4.4 ms len=44 ip=8.8.4.4 ttl=126 DF id=0 sport=80 flags=SA seq=2 win=65535 rtt=4.3 ms --- dns.google hping statistic --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 4.3/4.4/4.6 ms
Verifica l'indirizzo IP pubblico che utilizzi per comunicare con internet:
curl ifconfig.co
L'output visualizza un indirizzo IP pubblico di una delle istanze del gateway NAT. Se esegui di nuovo il comando, l'output potrebbe mostrare un indirizzo IP pubblico diverso perché le connessioni vengono distribuite utilizzando l'affinità sessione di bilanciamento del carico interno configurata (per impostazione predefinita IP client, protocollo e porta).
Il peering di rete VPC è non transitivo, quindi non esiste connettività tra le reti VPC spoke tramite il peering di rete VPC.
Considerazioni relative a un ambiente di produzione
La configurazione creata in questo tutorial fornisce due gateway NAT in un'unica regione. Tuttavia, il bilanciamento del carico ECMP non è perfetto e un singolo flusso non è distribuito tra più link, ovvero ciò che è richiesto quando si utilizzano dispositivi stateful come i firewall di nuova generazione.
Per eseguire il deployment di questa configurazione nell'ambiente di produzione, considera i seguenti punti:
- Questa configurazione è ideale per i link in uscita temporanei o non stateful. Se la dimensione del pool di gateway NAT cambia, le connessioni TCP potrebbero essere bilanciate, il che potrebbe comportare la reimpostazione di una connessione stabilita.
- I nodi non vengono aggiornati automaticamente, pertanto se un'installazione Debian predefinita presenta una vulnerabilità di sicurezza, devi aggiornare l'immagine manualmente.
- Se le VM si trovano in più regioni, devi configurare i gateway NAT in ogni regione.
- La larghezza di banda per gateway può variare in base al tipo di hardware. Assicurati di considerare fattori come la larghezza di banda massima in uscita per VM. In caso di errore del gateway, il traffico viene distribuito ai gateway rimanenti. Poiché i flussi in esecuzione non vengono riprogrammati, il traffico non si reimposta immediatamente quando il gateway torna online. Pertanto, assicurati di lasciare un carico di carico sufficiente durante le dimensioni.
- Per ricevere avvisi relativi a risultati imprevisti, utilizza Cloud Monitoring per monitorare i gruppi di istanze gestite e il traffico di rete.
Esegui la pulizia
Il modo più semplice per eliminare la fatturazione è eliminare il progetto Google Cloud che hai creato per il tutorial. In alternativa, puoi eliminare le singole risorse.
Elimina il progetto
- Nella console Google Cloud, vai alla pagina Gestisci risorse.
- Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
- Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.
Elimina le singole risorse
Se vuoi mantenere il progetto Google Cloud, puoi eliminare le risorse che hai creato per questo tutorial.
Elimina le connessioni di peering di rete VPC:
gcloud compute networks peerings delete spoke2-to-hub \ --network spoke2-vpc -q gcloud compute networks peerings delete spoke1-to-hub \ --network spoke1-vpc -q gcloud compute networks peerings delete hub-to-spoke1 \ --network hub-vpc -q gcloud compute networks peerings delete hub-to-spoke2 \ --network hub-vpc -q
Elimina le istanze, le risorse, i modelli e le route del bilanciatore del carico:
gcloud compute instances delete spoke1-client \ --zone=us-central1-c -q gcloud compute instances delete spoke2-client \ --zone=us-central1-c -q gcloud compute routes delete hub-nat-gw-ilbnhop -q gcloud compute forwarding-rules delete hub-nat-gw-ilbnhop -q gcloud compute backend-services delete -q hub-nat-gw-ilbnhop-backend -q gcloud compute instance-groups managed delete hub-nat-gw-ilbnhop-mig \ --region us-central1 -q gcloud compute health-checks delete nat-gw-ilbnhop-health-check -q gcloud compute instance-templates delete hub-nat-gw-ilbnhop-template -q gcloud compute routes delete hub-default-tagged -q
Elimina le regole firewall, le subnet e le reti VPC:
gcloud compute firewall-rules delete spoke2-vpc-iap -q gcloud compute firewall-rules delete spoke2-vpc-web-ping-dns -q gcloud compute firewall-rules delete spoke1-vpc-iap -q gcloud compute firewall-rules delete spoke1-vpc-web-ping-dns -q gcloud compute firewall-rules delete hub-vpc-iap -q gcloud compute firewall-rules delete hub-vpc-web-ping-dns -q gcloud compute firewall-rules delete hub-vpc-health-checks -q gcloud compute networks subnets delete spoke1-subnet1 \ --region us-central1 -q gcloud compute networks subnets delete spoke2-subnet1 \ --region us-central1 -q gcloud compute networks subnets delete hub-subnet1 \ --region us-central1 -q gcloud compute networks delete spoke1-vpc -q gcloud compute networks delete spoke2-vpc -q gcloud compute networks delete hub-vpc -q
Passaggi successivi
- Scopri di più sulle best practice e sulle architetture di riferimento per la progettazione di VPC.
- Consulta la documentazione relativa al peering di rete VPC e ai bilanciatori di carico di rete passthrough interni come hop successivi.
- Scopri di più sulle configurazioni speciali per le istanze VM.