Cloud Logging e metriche dei componenti di rete

Il monitoraggio in Google Cloud poggia su Cloud Logging e Cloud Monitoring, che raccolgono log e metriche per i componenti di rete. Cloud VPN espone metriche di stato dei tunnel e throughput; Cloud Router registra lo stato delle sessioni BGP e delle route annunciate/apprese; Cloud NAT produce log di traduzioni ed errori (utili per intercettare port exhaustion); Cloud DNS offre query logging per le zone; Cloud NGFW e Firewall Rules Logging tracciano le connessioni che colpiscono le regole. Firewall Insights non è un log ma un modulo analitico che segnala regole shadowed, troppo permissive o inutilizzate. La scelta corretta all’esame dipende dal segnale che serve: metriche per soglie e alerting, log per l’analisi forense della singola connessione.

VPC Flow Logs e Packet Mirroring

VPC Flow Logs cattura un campione dei flussi IP da e verso le VM, abilitato a livello di subnet. Fornisce metadati (5-tuple, byte, pacchetti, RTT, annotazioni geo/servizio) per monitoraggio, analisi dei costi di traffico, sicurezza e forense. Essendo campionato e configurabile (sampling rate, aggregazione, campi), non garantisce ogni pacchetto e non include il payload.

Packet Mirroring, al contrario, clona l’intero traffico (header + payload) delle istanze indicate e lo invia a un collector dietro un internal passthrough Network Load Balancer. È la scelta per IDS/IPS e deep packet inspection quando serve il contenuto completo, non un campione; consuma banda aggiuntiva e va ristretto con i filtri.

Network Intelligence Center

NIC riunisce gli strumenti diagnostici, ciascuno con uno scopo distinto:

  • Network Topology: visualizza topologia e flussi con metriche di traffico, per capire chi parla con chi.
  • Connectivity Tests: analizza la configurazione (route, firewall rules, forwarding) per diagnosticare la raggiungibilità end-to-end tra due endpoint, anche senza inviare traffico reale; indica se un pacchetto verrebbe bloccato e da quale regola o route.
  • Performance Dashboard: mostra packet loss e latenza tra zone/regioni, separando i problemi della rete Google dal design applicativo.
  • Firewall Insights e Network Analyzer: individuano misconfigurazioni (regole ridondanti, IP exhaustion imminente, route in conflitto, health check falliti, load balancer sottoutilizzati).

Regola d’esame: per “perché A non raggiunge B” si parte da Connectivity Tests; per “la latenza è di Google o mia” dal Performance Dashboard.

Troubleshooting: BGP, VPN, Interconnect e load balancing

Per HA VPN e Cloud Interconnect il primo controllo è lo stato del peering BGP sul Cloud Router: sessione established, ASN corretti, route annunciate/apprese coerenti. In global dynamic routing mode il Cloud Router propaga le route apprese a tutte le region della VPC; in regional mode solo alla propria region. Il failover active/passive si governa con le priorità BGP (MED): la route con priorità migliore viene preferita.

Sui load balancer, per rimuovere un backend senza troncare le sessioni si usa connection draining (drain): le nuove connessioni non vengono più instradate mentre quelle in corso terminano. Per spostare traffico in modo graduale si agisce su peso e redirect a livello di backend service o URL map dell’Application Load Balancer, ricordando che il passthrough Network LB preserva l’IP client e non termina TLS.

Trappole tipiche d’esame

  • Serve il payload completo per un IDS → Packet Mirroring, non VPC Flow Logs: i Flow Logs sono campionati e contengono solo metadati; Packet Mirroring clona header e payload verso un collector dietro internal passthrough NLB.
  • “Perché la VM A non raggiunge B?” → Connectivity Tests, non i Flow Logs: valuta route e firewall rules e indica il punto di blocco anche senza traffico reale, mentre i Flow Logs mostrano solo ciò che è già transitato.
  • Latenza alta, colpa di Google o della config? → Performance Dashboard: misura packet loss e latenza della rete Google tra zone/region, isolando il problema di rete da quello applicativo.
  • Cloud NAT perde connessioni in egress → NAT logs per port exhaustion: la soluzione è aumentare le porte per VM o usare l’allocazione dinamica; Cloud NAT è solo egress e non filtra l’ingress, quindi non è un problema di firewall.
  • Failover HA VPN non deterministico → priorità BGP (MED) sul Cloud Router: il comportamento active/passive dipende dalle route priority annunciate, non da route statiche o regole firewall.
  • Rimuovere un backend senza tagliare le sessioni → connection draining sull’Application LB: il drain fa terminare le connessioni attive e blocca le nuove; toglierlo di colpo interrompe le richieste in corso.