Google Cloud Networking 101: La TLDR Completa

Da un po' sto valutando se tentare la certificazione Google Cloud Professional Network Engineer. Non mi sono ancora deciso, ma nel frattempo ho continuato a studiare: in parte perché il programma d'esame è un buon modo per colmare le lacune, in parte perché lavoro abbastanza con il networking GCP da trovare utile avere una mappa mentale completa di tutto il sistema, indipendentemente dal fatto che mi presenti mai all'esame.

Questi sono i miei appunti. C'è molto materiale disponibile sul networking GCP, ma non sono riuscito a trovare nulla che offra un'introduzione completa e chiara coprendo tutti i pezzi importanti in un unico posto, senza essere né una panoramica superficiale né un libro di 700 pagine. Così l'ho scritto io. Lo pubblico perché potrebbe essere utile a qualcun altro.

Una cosa vale la pena dire subito: il networking GCP segue un modello mentale diverso da quello a cui la maggior parte delle persone è abituata. I tre concetti che ti faranno inciampare se non li interiorizzi per primi: i VPC sono globali (non regionali come in AWS), l'intero stack è completamente software-defined senza router o switch fisici da nessuna parte, e il traffico inter-regionale all'interno di un VPC rimane sul backbone di Google senza mai toccare la rete pubblica. Quest'ultimo punto è piuttosto interessante. Detto questo, iniziamo.

I Mattoni Fondamentali: VPC, Subnet, IP, Routing e Firewall

Tutto il networking in GCP è costruito su un manciata di primitive. Prenditi il tempo per capirle bene prima di andare avanti, perché il resto della piattaforma non è altro che combinazioni sempre più complesse di questi concetti :(.

VPC e Subnet

Un VPC è una rete privata globale. Quando ne crei uno, scegli tra la modalità automatica — dove GCP crea automaticamente una subnet in ogni regione — e la modalità personalizzata, in cui controlli ogni subnet esplicitamente. Usa la modalità personalizzata per qualsiasi ambiente di produzione. La modalità automatica crea subnet che non hai richiesto con intervalli predefiniti che spesso confliggono con reti on-premises o altri VPC a cui potresti voler connettere in seguito. Il tempo che risparmi iniziando con la modalità automatica lo pagherai con gli interessi quando provi a configurare il peering e scopri che i tuoi range si sovrappongono.

Le subnet sono risorse regionali e hanno un range CIDR primario, più range secondari opzionali. Quei range secondari sono il modo in cui GKE ottiene lo spazio IP per i pod e i servizi (ne parleremo in dettaglio più avanti). Una cosa importante da sapere subito: puoi espandere un range di subnet dopo la creazione, ma non puoi ridurlo. Non è un problema finché non lo diventa improvvisamente, quindi scegli i tuoi range fin dall'inizio. Correggere una sovrapposizione di CIDR a posteriori è una delle cose più dolorose che puoi fare a te stesso in GCP, perché blocca il VPC peering e tende a emergere esattamente nel momento sbagliato.

GCP ti permette anche di portare il tuo IP (BYOIP) se hai spazio di indirizzi pubblici portabili. È utile per migrare carichi di lavoro che hanno dipendenze esterne su specifici indirizzi IP. Per la gestione degli IP interni su molti VPC e ambienti, hai davvero bisogno di un tool IPAM adeguato. Un foglio di calcolo funziona anch'esso, purché venga effettivamente mantenuto. Il punto è avere un'unica fonte di verità per le allocazioni prima di iniziare a costruire.

Altra cosa da pianificare: GCP impone quote sia a livello di progetto che di VPC: route, regole firewall, subnet, regole di forwarding, hanno tutte dei limiti. Questi limiti sono abbastanza alti da non raggiungerli nella maggior parte dei casi, ma se stai costruendo qualcosa che scala orizzontalmente o che si estende su molti ambienti, progetta con margini adeguati.

Routing

Le route in GCP si dividono in due categorie. Le route statiche sono configurate manualmente: specifichi un prefisso di destinazione e un next hop, che può essere un'istanza VM, un internal load balancer, un gateway VPN o un VLAN attachment Interconnect. Le route statiche sono semplici e prevedibili ma richiedono manutenzione manuale man mano che la topologia evolve. Il routing dinamico usa BGP tramite Cloud Router per apprendere e pubblicizzare le route automaticamente, ed è ciò che vuoi per qualsiasi scenario di connettività ibrida verso on-premises o altri cloud.

Una modalità importante da capire: il routing dinamico globale vs. regionale. In modalità regionale, Cloud Router propaga le route apprese via BGP solo alle VM della propria regione. In modalità globale, quelle route si propagano in tutte le regioni del VPC. Per la maggior parte degli scenari ibridi vuoi la modalità globale, altrimenti i prefissi on-premises sono raggiungibili solo dalle VM nella stessa regione del Cloud Router, il che quasi mai è ciò che vuoi davvero.

GCP offre anche policy di routing tramite tag e priorità. Assegni network tag alle VM e delimiti le route statiche a quei tag, il che significa che diverse VM nella stessa subnet possono seguire policy di routing diverse. Combinato con le priorità delle route (vince il numero più basso), questo ti dà un controllo granulare del traffico senza dover creare subnet separate per ogni classe di traffico.

Un pattern da conoscere: l'Internal Load Balancer come next hop. Invece di puntare una route statica personalizzata verso una VM specifica, la punti verso un ILB. Il traffico per quella destinazione viene distribuito su un pool di backend, con l'ILB che gestisce l'health checking e il failover automaticamente. Questo è il modo standard per gestire appliance firewall HA in GCP, e torneremo su questo argomento quando parleremo di ispezione dei pacchetti.

Quando usi VPC peering, puoi anche controllare quali route vengono scambiate tra le reti. L'importazione e l'esportazione di route personalizzate tramite VPC peering ti permette di essere selettivo su ciò che ciascun lato pubblica, piuttosto che condividere tutto alla cieca: utile quando vuoi connettività controllata tra VPC senza una fusione completa delle tabelle di routing.

Firewall

I firewall GCP sono stateful, distribuiti e collegati al VPC — non alle singole VM. Ogni regola specifica un target, una direzione, un protocollo e un range di porte, e una priorità. Capire come questi elementi interagiscono è importante per definire correttamente la propria postura di sicurezza.

Il targeting è il meccanismo con cui la regola decide a quali VM si applica. Puoi targetizzare in base ai network tag (semplici stringhe che assegni alle VM) o ai service account. Per i carichi di lavoro in produzione, preferisci il targeting tramite service account — i tag possono essere impostati da chiunque abbia accesso amministratore alla VM, il che li rende più facili da usare in modo improprio o da configurare erroneamente. I service account non possono essere assegnati arbitrariamente, il che rende il targeting più affidabile.

Le regole di ingress ed egress sono separate. I default sono: consenti tutto l'egress, nega tutto l'ingress. Ogni regola ha una priorità e quando più regole corrispondono allo stesso traffico, quella con il numero di priorità più basso vince. È semplice ma facile da confondere quando si eseguono debug di comportamenti allow o deny inattesi. Controlla sempre quali altre regole potrebbero corrispondere prima di assumere che una regola specifica sia il problema.

I log delle regole firewall possono essere abilitati per singola regola, fornendo una voce Cloud Logging per ogni connessione corrispondente. Sono abbastanza utili per il debug e l'audit di sicurezza, ma aggiungono costi ad alto volume di traffico. Abilitali selettivamente, non globalmente.

Collegare le Risorse all'Interno di GCP

Una volta comprese le primitive, il passo successivo è capire come strutturare la connettività tra più progetti, team o ambienti all'interno di GCP. La risposta quasi sempre prevede una combinazione di VPC peering e Shared VPC, e scegliere tra i due è una delle prime decisioni architetturali che prenderai.

VPC Singolo vs. VPC Multipli

La prima domanda è se hai davvero bisogno di più VPC. Un singolo VPC è notevolmente più semplice da gestire e ragionare. I VPC multipli hanno senso quando hai bisogno di confini di rete rigidi — ad esempio, tra prod e non-prod, tra business unit con requisiti di compliance diversi, o tra sistemi che non dovrebbero avere alcun percorso tra loro anche se IAM fosse configurato erroneamente. Se non hai un requisito di isolamento chiaro che guida la decisione, inizia con un VPC e suddividi solo se necessario.

VPC Peering

Il VPC peering collega due VPC (stesso progetto, progetti diversi, persino organizzazioni diverse) in modo che possano comunicare usando IP interni. Il traffico rimane sulla rete di Google e non tocca mai la rete pubblica. È un concetto semplice con un vincolo critico: il peering è non-transitivo.

Se il VPC A fa peering con il VPC B, e il VPC B fa peering con il VPC C, allora A e C non possono comunicare attraverso B. Non c'è propagazione delle route attraverso il link di peering. Devi fare peering direttamente tra A e C se vuoi che comunichino. Questo rende le topologie hub-and-spoke basate solo su VPC peering molto dolorose in scala, poiché ogni spoke deve fare peering con ogni altro spoke con cui deve comunicare, il che cresce come O(n²). Shared VPC è spesso la risposta migliore per queste topologie.

Shared VPC

Lo Shared VPC centralizza la proprietà della rete. Un host project possiede il VPC (le sue subnet, route, regole firewall) e i service project vi si collegano, distribuendo le proprie risorse nelle subnet condivise. La gestione della rete è centralizzata; i team possiedono le proprie risorse di calcolo nei loro progetti. Questo è il modello giusto per la maggior parte degli scenari multi-team o multi-ambiente. Il costo è una configurazione iniziale più complessa e un IAM più articolato: l'host project deve concedere ai service project il ruolo compute.networkUser per permettere loro di usare le subnet condivise. Dimenticarsi di questo causerà fallimenti nella creazione di cluster o VM con errori non sempre immediatamente comprensibili.

Puoi anche condividere subnet usando le cartelle, il che ti permette di applicare le policy di condivisione a livello di cartella nella gerarchia della tua organizzazione, anziché progetto per progetto. Utile per le grandi aziende dove gestire manualmente le singole concessioni per progetto non scala!

Connessione ai Servizi Gestiti GCP

Non tutto ciò con cui interagisci è una VM che controlli. GCP ha un ampio ecosistema di servizi gestiti — Cloud SQL, Pub/Sub, GCS, BigQuery e altri — e ciascuno si connette al tuo VPC in modo diverso.

Private Google Access risolve un problema specifico: le VM con solo IP interni (senza indirizzo esterno) hanno bisogno di un modo per raggiungere le API di Google senza passare per la rete pubblica. Lo abiliti per subnet, e da quel momento le VM in quella subnet possono raggiungere le API di Google tramite routing interno. Per le VM on-premises che si connettono tramite VPN o Interconnect, la configurazione è leggermente diversa: instrada il traffico verso private.googleapis.com o restricted.googleapis.com tramite route personalizzate, in modo che il traffico API rimanga fuori dalla rete pubblica end-to-end.

Per i servizi gestiti come Cloud SQL, il meccanismo dietro all'IP privato è Private Service Connect o VPC peering in un VPC gestito da Google: Google esegue il backend del servizio gestito nel proprio VPC e lo fa fare peering nel tuo. Per i servizi SaaS, PaaS e IaaS in generale, il modello di connessione varia per servizio: alcuni usano Private Service Connect, altri usano Private Service Access, altri usano internet direttamente. Vale la pena verificare quale modello si applica a ciascun servizio prima di progettare le regole firewall e di routing intorno ad esso.

Networking GKE

Il networking GKE è il networking VPC con livelli aggiuntivi sopra.

La cosa più importante da ricordare sul networking GKE è che devi pianificare il suo indirizzamento IP in anticipo come parte del tuo piano IP VPC più ampio. Un cluster VPC-native consuma IP da tre range separati: il range primario della subnet del nodo (IP VM per i nodi), un range secondario per gli IP dei pod (uno per pod) e un altro range secondario per gli IP dei servizi (uno per ogni Kubernetes Service). Questi range devono essere abbastanza grandi per la dimensione prevista del cluster più margine di crescita, e non possono sovrapporsi con nulla a cui potresti voler fare peering o connettere in seguito. Puoi espandere i range IP di GKE in seguito, ma è operativamente scomodo, quindi è meglio farlo bene la prima volta.

I cluster VPC-native con alias IP range sono la modalità di networking raccomandata da tempo. Gli IP dei pod provengono da alias IP range collegati all'interfaccia di rete del nodo, il che significa che sono nativamente instradabili all'interno del VPC senza route statiche per ogni pod. La vecchia modalità di networking basata su route creava una route statica per nodo, che raggiungeva le quote di route VPC in scala ed è considerata legacy. Evitala per i nuovi cluster.

Eseguire GKE in uno Shared VPC significa che le subnet dei nodi e i range secondari vivono nell'host project, mentre il cluster stesso vive in un service project. Il service account GKE nel service project ha bisogno di specifiche autorizzazioni IAM nell'host project per gestire le regole firewall e usare le subnet condivise; la mancanza di queste autorizzazioni è la causa più comune di fallimenti confusi nella creazione di cluster in configurazioni Shared VPC.

Sul lato sicurezza, Kubernetes NetworkPolicy ti permette di controllare il traffico pod-to-pod all'interno del cluster. GKE lo implementa tramite Calico o Cilium a seconda della configurazione del cluster. Per default, tutti i pod possono comunicare con tutti gli altri pod, senza isolamento. Abilitare le network policy è un'impostazione esplicita a livello di cluster, ed è qualcosa che dovresti fare per qualsiasi cluster in produzione. Non assumere che il firewall VPC copra questo aspetto: opera a un livello diverso.

Per l'accesso al cluster, la decisione chiave è nodi pubblici vs. privati e endpoint del control plane. I cluster privati danno ai nodi solo IP interni senza indirizzi esterni. Il control plane (API server) può essere reso privato, accessibile solo dall'interno del VPC. Questa è la postura corretta per la produzione: non vuoi che il tuo API server Kubernetes sia raggiungibile da internet. Quando hai bisogno di accesso esterno all'API server (da un runner CI/CD o dal tuo laptop), le authorized network ti permettono di mettere in whitelist specifici CIDR che possono raggiungere l'endpoint del control plane, mantenendo piccola la superficie di attacco.

Raggiungere il Mondo Esterno: Load Balancing, NAT e CDN

I tuoi carichi di lavoro devono essere raggiungibili da internet, e devono raggiungere internet a loro volta. Il toolkit di GCP offre molto, quindi diamo un'occhiata.

Load Balancing

La famiglia di load balancer di GCP è ampia e i nomi non sono sempre intuitivi. I principali si distinguono per globale vs. regionale, esterno vs. interno, e L7 (HTTP/S) vs. L4 (TCP/UDP). Non sono intercambiabili, quindi è importante scegliere quello giusto.

La base di tutto è il backend service, che definisce come un load balancer distribuisce il traffico tra i suoi backend, inclusa la modalità di bilanciamento (basata sull'utilizzo o sul rate), il scaling della capacità e le impostazioni di session affinity. I Network Endpoint Group (NEG) sono il modo in cui connetti un load balancer a backend moderni, ad esempio il load balancing container-native in GKE (che ti dà distribuzione del traffico a livello di pod, bypassando completamente kube-proxy), Cloud Run, App Engine, o persino endpoint esterni a GCP. Se stai usando GKE e ti interessa una distribuzione accurata del traffico, il load balancing container-native con NEG è ciò che vuoi.

Una cosa che confonde molte persone: le regole firewall per gli health check. I load balancer GCP eseguono probe sui tuoi backend dai range 130.211.0.0/22 e 35.191.0.0/16. Se dimentichi di consentire questi nelle tue regole firewall, i backend appaiono non in salute e il traffico non fluisce. Scrivitelo da qualche parte! Ne avrai bisogno quando i backend inizieranno a fallire gli health check e non capirai il perché.

Per il traffico web esposto su internet, l'external HTTP(S) Load Balancer è lo strumento di scelta. È globale (anycast), termina TLS, supporta HTTP/2, instrada le richieste tramite URL map e si integra direttamente con Cloud Armor e Cloud CDN. I backend possono essere in qualsiasi regione e il LB instrada verso quello più vicino e in salute. Per il traffico TCP non-HTTP che ha ancora bisogno di reach globale o terminazione TLS, i TCP e SSL proxy load balancer esterni coprono il gap. Per carichi di lavoro L4 ad alto throughput e bassa latenza dove gestisci tu stesso TLS e vuoi la preservazione dell'IP client, il Network Load Balancer è regionale e passa il traffico a livello di rete senza overhead di proxy.

Per il traffico che rimane all'interno del tuo VPC, gli HTTP(S) e TCP proxy load balancer interni sono gli equivalenti. L'internal HTTP(S) LB è particolarmente versatile perché può anche fungere da next hop nelle route statiche personalizzate — che è il pattern standard per le appliance firewall HA (il traffico viene instradato attraverso l'ILB, che distribuisce tra le appliance del pool e gestisce il failover automaticamente). Il protocol forwarding è un'opzione più semplice quando hai bisogno di forwardare traffico grezzo verso una VM specifica senza l'overhead di una configurazione completa di backend service. Utile per le network appliance che devono ricevere traffico direttamente.

Per gestire i picchi di traffico, i managed instance group GCP possono autoscalare in base all'utilizzo della CPU, all'utilizzo del LB, o a metriche personalizzate di Cloud Monitoring. Le impostazioni di max CPU e max utilization sul backend service controllano quando GCP inizia a distribuire il traffico su backend o regioni aggiuntive. Calibra queste impostazioni per il tuo carico di lavoro altrimenti vedrai una distribuzione non uniforme sotto carico reale.

Cloud Armor

Cloud Armor è il layer WAF e di protezione DDoS di GCP, collegato agli external HTTP(S) load balancer. Definisci security policy — insiemi denominati di regole valutate in ordine di priorità, ciascuna che corrisponde a condizioni come IP sorgente, origine geografica, o attributi della richiesta, e che consente o nega la richiesta. Le regole WAF sono precostruite per pattern di attacco comuni (SQLi, XSS e altro) basate su set di regole ModSecurity, con livelli di sensibilità regolabili per regola. Le policy si collegano a livello di backend service, quindi puoi applicare policy diverse a backend diversi dietro lo stesso load balancer (una policy più restrittiva per la tua API admin, una più permissiva per i tuoi asset statici pubblici, ad esempio).

Cloud CDN

Cloud CDN è abilitato per backend service sugli external HTTP(S) LB. Controlli la cache mode (se rispettare gli header cache dell'origine, cachare solo contenuto statico, o forzare il caching di tutto), la composizione della key della cache (quali componenti della richiesta determinano l'identità della cache — utile per A/B testing o contenuto specifico per lingua) e l'invalidazione della cache (per URL o prefisso URL, senza invalidazione per tag). Gli URL firmati ti permettono di limitare l'accesso a richieste con firma crittografica e scadenza temporale (l'approccio corretto per la consegna di contenuto protetto). La CDN può anche attingere da origini personalizzate al di fuori di GCP, non solo da backend GCP.

Una cosa a cui fare attenzione: cosa stai effettivamente cachando. Cachare accidentalmente risposte autenticate perché un backend ha inviato header cache permissivi è un problema reale e non è piacevole da debuggare in produzione.

Cloud NAT

Cloud NAT risolve il problema del traffico internet in uscita per le VM senza IP esterni — devono raggiungere API esterne, scaricare pacchetti, chiamare servizi di terze parti — senza esporre nessuna connettività in entrata. Non è una VM né un'appliance, è un servizio completamente distribuito software-defined senza un singolo punto di failure, il che significa che non devi preoccuparti di esso come collo di bottiglia come faresti con un tradizionale NAT gateway.

Lo colleghi a un Cloud Router nella regione pertinente e scegli quali subnet copre. Gli IP NAT possono essere allocati automaticamente o specificati manualmente (utile quando hai bisogno di IP di egresso stabili per allowlist esterne). L'allocazione delle porte controlla quante connessioni concorrenti una VM può fare verso la stessa destinazione esterna, e esaurire le porte NAT è un problema reale per i carichi di lavoro che aprono molte connessioni verso lo stesso endpoint. Monitora la metrica nat_allocation_failed. I timeout TCP, UDP e ICMP sono configurabili, il che è importante se hai connessioni di lunga durata che vengono silenziosamente interrotte. I vincoli Organization Policy ti permettono di applicare standard di configurazione Cloud NAT su larga scala, limitando le regioni in cui può essere distribuito, imponendo l'allocazione manuale degli IP e così via.

Connettività Ibrida: On-Premises e Multi-Cloud

Connettere GCP all'infrastruttura on-premises o ad altri cloud è dove il networking GCP diventa piuttosto complesso e l'overhead operativo diventa reale. La prima cosa da chiarire è perché lo stai facendo, perché non è sempre la scelta migliore.

I comuni driver delle reti ibride sono: requisiti normativi che mantengono certi dati on-premises, sistemi legacy che non possono migrare, strategie di migrazione graduali, o ridondanza multi-cloud. I tuoi obiettivi generali — target di latenza, requisiti di banda, budget di costo, comportamento di failover — dovrebbero guidare la selezione della tecnologia. Non iniziare con "quale prodotto dovrei usare" prima di aver risposto a queste domande.

Le Opzioni di Connettività

Al livello più alto, Dedicated Interconnect ti offre un cross-connect fisico tra la tua rete e quella di Google in una struttura di colocation — circuiti da 10G o 100G, bassa latenza, banda prevedibile e un SLA solido. Effettui il provisioning di VLAN attachment per connettere il circuito fisico ai tuoi VPC tramite Cloud Router. Per la produzione vuoi almeno due circuiti in diverse aree metropolitane; un singolo circuito è un singolo punto di failure. Partner Interconnect è l'alternativa quando non puoi effettuare la colocation direttamente con Google — vai tramite un carrier partner che gestisce il circuito fisico, e tu effettui ancora il provisioning dei VLAN attachment sul lato GCP. La banda inizia più bassa (50 Mbps) ed è la scelta giusta quando i tuoi volumi di traffico non giustificano un circuito dedicato o quando Dedicated Interconnect non è disponibile nella tua location.

Direct Peering e Carrier Peering ti permettono di stabilire sessioni BGP direttamente con la rete di Google in una location di peering, utili per ottimizzare il routing del traffico diretto a internet. Sono meno comunemente necessari per la tipica connettività ibrida enterprise perché non ti danno accesso alle risorse VPC nel modo in cui lo fa Interconnect o VPN.

Per la maggior parte degli scenari che non richiedono le garanzie di banda o latenza di Interconnect, HA VPN è la scelta giusta. Due interfacce VPN, ciascuna con il proprio IP esterno, ciascuna che esegue una sessione BGP tramite Cloud Router, connesse a due gateway peer on-premises; quando configurata correttamente, offre il 99,99% di SLA e failover automatico senza intervento manuale. Classic VPN è l'alternativa legacy: singolo tunnel, routing statico o policy-based, SLA al 99,9%. Funziona ancora, ma i nuovi deployment dovrebbero usare HA VPN per default. Il throughput VPN raggiunge al massimo circa 3 Gbps per tunnel; se hai bisogno di più, usa più tunnel o passa a Interconnect.

La banda e i vincoli di ciascuna opzione sono importanti: Interconnect offre maggiore throughput e minore latenza, VPN è operativamente più semplice e non richiede la colocation. Scegli in base alle tue effettive esigenze!

Topologie e Failover

Per topologie multi-cloud (GCP + AWS, GCP + Azure), le opzioni di connessione sono gli stessi prodotti VPN e Interconnect, puntati semplicemente verso l'equivalente dell'altro cloud. Il pattern di topologia (completamente meshed, hub-and-spoke, o isolato con un layer di servizi condivisi) dipende da quanto traffico attraversa i confini cloud e da quali sono i tuoi requisiti di latenza. Non esiste una risposta universalmente corretta.

Il failover e il disaster recovery a livello di rete significa più tunnel VPN o circuiti Interconnect con failover BGP configurato, Cloud Router che pubblicizza route da più regioni, e policy di routing basate su health check che possono drenare il traffico da una regione che sta fallendo prima che vada completamente offline. La modalità di routing del tuo VPC (regionale vs. globale) influenza direttamente se un Cloud Router in una regione può pubblicizzare route apprese alle VM in altre regioni — per la maggior parte degli scenari DR, vuoi la modalità global routing.

La gestione degli indirizzi IP tra on-premises e cloud è uno di quei problemi che causano dolore reale se trascurati. Mantieni un'unica fonte di verità per tutte le allocazioni CIDR (on-premises, per-VPC, per-regione) e tratta la sovrapposizione tra di esse come una condizione di errore grave durante la progettazione, non qualcosa da aggirare in seguito.

Cloud Router

Cloud Router è il BGP speaker sul lato GCP di qualsiasi connessione ibrida. È un servizio completamente gestito, non una VM, il che significa che non gestisci la sua disponibilità... ma devi capire la sua configurazione BGP.

Le sessioni BGP vengono stabilite su indirizzi link-local (range 169.254.x.x) attraverso tunnel VPN o VLAN attachment. Configuri Cloud Router con un ASN privato e usi valori MED (Multi-Exit Discriminator) e priorità di route BGP per influenzare quale percorso preferisce il traffico quando hai più connessioni. La pubblicità della default route tramite BGP permette a Cloud Router di annunciare una default route all'on-premises, utile quando vuoi centralizzare l'egress internet attraverso GCP per ispezione o logging. Le custom route advertisement ti permettono di controllare esattamente quali prefissi Cloud Router annuncia, anziché pubblicizzare l'intero VPC. Utile per la summarizzazione e per mantenere privati i prefissi interni.

Per la connettività ibrida critica, distribuisci Cloud Router in più regioni con più sessioni BGP. Usa i valori MED per esprimere la preferenza di percorso attivo/backup. Il servizio Cloud Router stesso è gestito e ad alta disponibilità; ciò per cui stai costruendo la ridondanza è la connettività fisica sottostante (tunnel o circuiti).

Sicurezza: Perimetri, Controlli e Best Practice

La sicurezza del networking GCP ha più livelli che operano a diversi livelli di astrazione. Le regole firewall sono la baseline: controllano il traffico a livello di rete. I VPC Service Controls operano a un livello più alto, controllando l'accesso alle API GCP indipendentemente da quale rete proviene la richiesta. Capire entrambi i livelli e come interagiscono è importante.

VPC Service Controls

Il VPC SC è una delle funzionalità di sicurezza più potenti su GCP e anche una delle più complesse da distribuire correttamente. L'idea centrale è questa: anche se un principal ha il permesso IAM di leggere un bucket GCS, VPC SC può bloccare quella richiesta se proviene al di fuori di un perimetro di sicurezza definito. È un defense-in-depth sopra IAM, non una sostituzione. La principale minaccia che affronta è l'esfiltrazione di dati tramite chiamate API legittime: un attaccante o un servizio mal configurato che usa credenziali reali per esfiltrare dati attraverso le API GCP.

Un service perimeter definisce un confine attorno a un insieme di progetti GCP e i servizi GCP al loro interno. Le richieste che attraversano quel confine sono bloccate per default. Gli access level definiscono le condizioni in cui attraversare il confine è consentito — range IP sorgente, livello di fiducia del dispositivo, identità dell'utente e altro ancora. Colleghi gli access level alle policy di ingress ed egress del perimetro per creare eccezioni controllate.

Configurarne uno implica: abilitare le API Access Context Manager e Cloud Resource Manager, creare una access policy per la tua organizzazione, definire gli access level e poi creare e popolare il perimetro. Non è concettualmente complicato, ma il diavolo è nei dettagli di cosa si trova all'interno del perimetro e cosa deve attraversarlo.

VPC Accessible Services aggiunge una restrizione ulteriore: limita quali API GCP sono accessibili dall'interno del perimetro, impedendo alle VM interne di chiamare servizi esterni e chiudendo un vettore di esfiltrazione interno. Attenzione a questo: dimenticare di includere Cloud Logging o Cloud Monitoring nell'elenco dei servizi consentiti interromperà silenziosamente l'osservabilità.

Quando hai due perimetri separati che hanno una buona ragione per scambiarsi dati, un perimeter bridge crea una connessione controllata tra di essi. È più restrittivo della fusione dei perimetri: solo le risorse esplicitamente collegate tramite bridge possono comunicare attraverso di esso, quindi mantieni l'isolamento che volevi abilitando flussi di dati specifici.

L'audit logging è non negoziabile. Ogni violazione di VPC SC genera una voce di log in Cloud Audit Logs. Durante il rollout è così che scopri cosa hai mancato; nelle operazioni continuative è come rilevi pattern di accesso anomali.

La guida operativa più importante per VPC SC: usa sempre la modalità dry-run prima di applicare le regole. In dry-run, le violazioni vengono registrate ma non bloccate. Il workflow è: crea il perimetro in modalità dry-run, poi monitora i log delle violazioni su tutti i tuoi pattern di accesso, poi adegua gli access level e la configurazione del perimetro in base a ciò che trovi, poi testa di nuovo, poi applica, poi testa il perimetro applicato, poi fai pulizia. È noioso, ma saltare questo passaggio e andare direttamente all'applicazione in un ambiente esistente causerà incidenti in produzione ogni volta.

Un'ultima cosa su VPC SC: ha interazioni specifiche con Shared VPC e VPC Peering che richiedono una progettazione attenta. Gli host project e i service project in uno Shared VPC devono trovarsi nello stesso perimetro, o hai bisogno di bridge tra perimetri che attraversano il confine. I progetti con VPC peering richiedono ugualmente una buona collocazione del perimetro — la documentazione su queste interazioni vale la pena leggerla attentamente prima di finalizzare il design del perimetro.

Firewall, NGFW e IAM

Al livello firewall, GCP ti offre regole firewall distribuite native e anche la possibilità di eseguire appliance NGFW di terze parti come VM. Le regole firewall native GCP sono veloci da distribuire, gestite centralmente e sufficienti per la maggior parte dei carichi di lavoro. Le appliance NGFW (Palo Alto, Fortinet e altri che girano come VM con più NIC) offrono ispezione più profonda (consapevolezza L7, ispezione TLS, IDS/IPS) ma aggiungono significativa complessità operativa. Usa le regole native come baseline e aggiungi appliance NGFW dove la tua postura di compliance o il modello di minaccia richiede davvero un'ispezione più profonda.

Firewall Insights vale la pena eseguirlo periodicamente sugli ambienti di produzione. Fa emergere regole eccessivamente permissive, regole oscurate (dove una regola con priorità più alta corrisponde sempre per prima, rendendo un'altra regola di fatto inattiva) e regole che non hanno corrisposto a nessun traffico di recente. I ruleset firewall tendono ad accumulare cruft nel tempo; Insights ti offre un modo basato sui dati per ripulirli.

Lo IAM di Shared VPC merita particolare attenzione perché sbagliarlo causa fallimenti confusi. Il ruolo compute.networkUser a livello di host project è ciò che permette alle risorse del service project di usare le subnet condivise. Il ruolo compute.securityAdmin controlla chi può gestire le regole firewall nell'host project. Quando si diagnosticano fallimenti IAM in Shared VPC, guarda il protoPayload in Cloud Logging per compute.googleapis.com: gli errori di permesso negato emergono lì con dettagli sufficienti per identificare esattamente cosa manca.

DNS e Ispezione dei Pacchetti

Cloud DNS

Cloud DNS è molto più di un semplice nameserver. È un componente architetturale di prima classe con diverse modalità che influenzano il funzionamento della risoluzione dei nomi nell'intero ambiente.

Le zone pubbliche servono il DNS esposto su internet; le zone private sono visibili solo a specifici VPC. La gestione di zone e record è standard (A, AAAA, CNAME, MX, TXT) con modifiche che si propagano in pochi secondi. Se stai migrando da un altro provider DNS, il workflow è: esporta il tuo file di zona, importalo in Cloud DNS, verifica tutti i record (presta particolare attenzione a MX, SPF e DKIM), poi coordina il cambio del record NS con il tuo registrar. Testa prima di fare il cutover!

DNSSEC è supportato per le zone pubbliche e aggiunge la verifica della autenticità crittografica alle risposte DNS, proteggendo contro il cache poisoning e lo spoofing. Vale la pena abilitarlo per le zone pubbliche, ma richiede il coordinamento con il tuo registrar per pubblicare il record DS e aggiunge complessità operativa continuativa nella gestione delle chiavi.

Le forwarding zone e le DNS server policy ti danno controllo su dove vanno le query. Le forwarding zone inviano le query per specifici domini a resolver esterni — tipicamente i tuoi server DNS on-premises. Le policy dei server ti permettono di configurare quale server DNS usano le tue VM per default. Insieme, ti permettono di costruire configurazioni DNS ibride flessibili senza necessariamente distribuire un'infrastruttura DNS bidirezionale completa.

Per una piena integrazione DNS ibrida, il pattern bidirezionale standard funziona così: i resolver on-premises inoltrano le query per i domini interni GCP agli indirizzi IP dei forwarder in entrata di Cloud DNS, e le forwarding zone di Cloud DNS inviano le query per i domini on-premises ai resolver on-premises. Il risultato è che le VM in GCP possono risolvere i nomi on-premises, e gli host on-premises possono risolvere i nomi interni GCP — risoluzione dei nomi senza soluzione di continuità attraverso il confine ibrido.

Split-horizon DNS è il pattern in cui lo stesso nome di dominio si risolve diversamente a seconda di dove proviene la query. Una zona pubblica restituisce IP pubblici; una zona privata (visibile solo alle risorse VPC) restituisce IP interni per lo stesso FQDN. Questo è l'approccio corretto per i servizi che devono essere raggiungibili sia da internet che internamente, senza dover usare nomi di dominio diversi per ogni contesto.

Il DNS peering permette a un VPC di delegare la risoluzione per una zona al Cloud DNS di un altro VPC. Nelle topologie hub-and-spoke, un VPC centrale spesso possiede il DNS, e i VPC spoke usano il DNS peering per risolvere i nomi dall'hub senza aver bisogno di VPC peering completo o Shared VPC solo per la risoluzione dei nomi. Il logging DNS privato registra le query DNS dalle VM nel tuo VPC: utile per l'audit di sicurezza e per il debug di problemi di risoluzione altrimenti molto difficili da tracciare.

Ispezione dei Pacchetti

Il packet mirroring clona il traffico da VM o subnet specifiche e lo invia a un collector (un'altra VM o un Internal Load Balancer) senza influenzare il percorso del traffico stesso. Questo è il modo in cui integri tool IDS/IPS e analizzatori di traffico in GCP senza metterli inline. Configuri una policy di mirroring specificando sorgenti e destinazione, e usi filtri di sorgente e traffico per essere selettivo su ciò che viene specchiato: filtrando per VM, subnet, protocollo o range CIDR. Specchiare tutto in un ambiente ad alto throughput è costoso; sii deliberato su ciò che hai effettivamente bisogno di catturare.

Il packet mirroring funziona anche tra più VPC, con il traffico di mirroring incapsulato e tunnelato tra di essi, quindi la tua infrastruttura collector non deve vivere nello stesso VPC delle sorgenti.

Per ispezionare il traffico inter-VPC usando VM multi-NIC, il pattern è distribuire appliance NGFW come VM con più interfacce di rete (una per VPC) e usare route statiche personalizzate per convogliare il traffico attraverso di esse. Il traffico entra da un NIC, viene ispezionato ed esce da un altro. Per l'alta disponibilità, usi un Internal Load Balancer come next hop in quelle route statiche: il traffico colpisce l'ILB, l'ILB lo distribuisce sul pool di appliance, e l'health checking dell'ILB instrada automaticamente intorno alle istanze fallite. Questo è il pattern production-grade per eseguire prodotti NGFW di terze parti in GCP.

Operare la Rete: Osservabilità, Troubleshooting e Manutenzione

Progettare e costruire la rete riceve tutta l'attenzione architetturale, ma operarla è il lavoro continuativo. GCP offre un toolset solido che la maggior parte delle persone dovrebbe usare.

Osservabilità

I VPC Flow Log sono record campionati per subnet dei flow di rete. Controlli il tasso di campionamento dall'1% al 100%. A bassi tassi di campionamento offrono una solida panoramica dei pattern di traffico a un costo modesto; a tassi più alti ottieni dati più completi per analisi dettagliate o indagini di sicurezza. Abilitali ampiamente a un basso tasso di campionamento e aumenta selettivamente quando hai bisogno di dettaglio.

I log delle regole firewall ti dicono per connessione cosa ha corrisposto e quale decisione è stata presa. Combinati con Firewall Insights, che analizza il tuo ruleset completo e fa emergere regole eccessivamente permissive, regole oscurate e regole che non hanno corrisposto a traffico da molto tempo, hai un quadro solido sia di ciò che sta accadendo che della sensatezza della tua configurazione di regole. Esegui Insights periodicamente: i ruleset firewall tendono ad accumulare cruft.

Per il monitoraggio più ampio, Cloud Monitoring ti offre metriche per tutto ciò che è rilevante per le operazioni di rete: stato e throughput del tunnel VPN, stato della connessione Cloud Interconnect e bit error rate, stato della sessione BGP di Cloud Router e conteggio delle route, conteggi di richieste e latenza e health dei backend del load balancer, rate di allow e deny di Cloud Armor, e utilizzo delle porte e fallimenti di allocazione di Cloud NAT. Dovresti avere alert su tunnel VPN giù, degradazione dell'health dei backend, sessione BGP giù, e esaurimento delle porte NAT come minimo. Questi sono i fallimenti che si propagano a cascata se non li intercetti in anticipo. La revisione dei log per i componenti di rete (VPN, Cloud Router, VPC Service Controls, Cloud NAT) dovrebbe alimentare quegli alert tramite metriche basate su log anziché tramite revisione manuale.

Troubleshooting

Quando qualcosa non riesce a connettersi, i Connectivity Test del Network Intelligence Center dovrebbero essere la tua prima tappa. Specifichi una sorgente e una destinazione, e simula il percorso del pacchetto — dicendoti se il traffico sarebbe consentito o bloccato, e se bloccato, esattamente quale regola firewall o route è la causa. Questo risparmia ore di tracciamento manuale attraverso liste di regole firewall e tabelle di routing. La vista Topology ti offre una mappa visiva dei tuoi VPC e delle loro connessioni, particolarmente utile quando hai ereditato una rete costruita da qualcun altro.

Per il troubleshooting VPN, inizia con lo stato del tunnel tramite gcloud compute vpn-tunnels describe. Le modalità di fallimento comuni sono i fallimenti di negoziazione IKE (PSK errata o parametri di versione/algoritmo IKE non corrispondenti), problemi di routing dove la sessione BGP è attiva ma le route non si propagano (di solito un ASN mal configurato o un filtro di prefisso inatteso), e problemi di MTU dove l'overhead IPsec riduce l'MTU effettivo e causa problemi di frammentazione con i pacchetti grandi. Testa l'MTU esplicitamente: esegui ping con una dimensione di pacchetto fissa e il bit don't-fragment impostato.

Per i problemi BGP di Cloud Router, gcloud compute routers get-status mostra lo stato della sessione e il set completo di route apprese e pubblicizzate. I problemi comuni sono la mancata corrispondenza dell'ASN tra i peer, la mancata corrispondenza dei parametri timer, conflitti di IP link-local sugli indirizzi della sessione BGP e custom route advertisement mal configurate che causano la mancata pubblicazione dei prefissi.

Per drenare il traffico da un backend del load balancer, imposta il suo weight di capacità a 0 sul backend service anziché eliminarlo. Il load balancer dremerà le connessioni esistenti con grazia e smetterà di inviarne di nuove. Eliminare un backend instance group mentre è sotto carico non è una buona idea.

Testare la latenza e il throughput vale la pena farlo come baseline così hai qualcosa con cui confrontarti quando le performance degradano. Usa iperf3 per il throughput tra VM, ping per l'RTT ICMP come proxy per la latenza di rete. Per percorsi ad alta banda e alta latenza come le connessioni intercontinentali, la window size TCP è spesso il fattore limitante: esegui iperf3 con impostazioni esplicite della window size per ottenere numeri accurati. La Performance Dashboard nel Network Intelligence Center ti offre heatmap di latenza tra le regioni GCP e può confermare se una latenza anomala che stai osservando è una deviazione reale o rientra nella varianza normale.

Conclusione

Il networking Google Cloud è profondo. Questo post copre deliberatamente molto terreno, ma ogni sezione qui è solo una superficie: ciascuna ha libri ed esami di certificazione dedicati. L'obiettivo era darti una mappa mentale solida di come i pezzi si incastrano e dove andare quando hai bisogno di approfondire.

Se non porterai via nient'altro: pianifica il tuo spazio IP prima di costruire qualsiasi cosa, perché correggere i conflitti CIDR a posteriori è un'agonia. Shared VPC è il default corretto per gli ambienti multi-team. VPC Service Controls non è opzionale per i carichi di lavoro regolamentati, e devi usare la modalità dry-run prima di applicare le regole. Cloud Router e BGP sono la spina dorsale della connettività ibrida — comprendi la modalità di routing e le leve MED prima di averne bisogno durante un incidente. E fai del Network Intelligence Center il tuo primo strumento di debug: i Connectivity Test da soli ti faranno risparmiare più ore di debug di quasi qualsiasi altra cosa nella piattaforma!

Spero che questo post ti sia stato utile. Se hai domande o feedback, non esitare a farmelo sapere!