VPN Site-to-Site ridondata tra GCP, AWS e data center on-premise

Un semplice progetto di integrazione tra un applicativo SaaS presente in GCP e vari servizi esposti dai più disparati angoli della rete estesa del cliente (AWS, SD-WAN, Altri SaaS, ha presentato parecchie difficoltà e ha richiesto un'importante sessione di troubleshooting che ha coinvolto molti fornitori e i nostri gruppi di Cloud Engineer e Sicurezza.

Il contesto

L'infrastruttura in esame rappresenta un collegamento VPN site to site tra ambienti cloud distinti, GCP e AWS, con destinazioni finali multiple che includono il data center on-premise centro stella delle interconnessioni di rete e un datacenter remoto ove risiede applicativo in SaaS che deve essere raggiunto e i primi enti territoriali collegati tramite una sd-wan dedicata. Considerando la direzione da GCP verso le destinazioni finali, il traffico transita da GCP Milano e GCP Torino (entrambi devono poter raggiungere servizi specifici) attraverso molteplici connessioni AWS VPN, configurate in ridondanza e alta disponibilità (HA) tramite protocollo BGP. Queste connessioni terminano a Milano, lato AWS, da cui il traffico viene instradato, dopo un'ispezione da parte di un NGFW (Next-Generation Firewall) all'interno della VPC SICUREZZA e in seguito ad ulteriori diversi passaggi interni, verso le destinazioni finali. L'architettura è intrinsecamente complessa e articolata, rendendone la comprensione iniziale potenzialmente difficoltosa.
Raffiguriamo, di seguito, ad alto livello, l’infrastruttura del caso in esame in cui la numerazione considera il traffico da GCP (1) verso destinazioni finali DataCenter (5) , Ente locale 1(6a) e Ente locale 2 (6b).

 

Il problema

In particolare, tutti i tentativi di stabilire una connessione TCP (o, più precisamente, di avviare una sessione TCP on top della quale far transitare traffico HTTP/HTTPS) dalle macchine situate sia in GCP Torino che in GCP Milano si traducevano in un connection timeout. 

Questi errori si verificavano in modo costante e sistematico ad ogni tentativo. Inizialmente, la presenza di traffico in ingresso attraverso le VPN AWS aveva portato a ipotizzare che il problema fosse esclusivamente legato al traffico di ritorno (il quale era effettivamente presente, ma non era l'unica causa).
 

Gli obiettivi

L'obiettivo primario era identificare con precisione la causa o le cause della mancata raggiungibilità da GCP verso gli IP di destinazione e garantire la raggiungibilità end-to-end degli IP, garantendo quindi un flusso corretto del traffico sia in andata che nel ritorno.

La soluzione

Il processo di troubleshooting si è articolato principalmente in due fasi. Vediamole.

• Verifica dei log del NGFW: sono stati analizzati i log del traffico che attraversava il NGFW per determinare se i pacchetti fossero giunti fino a quel punto e, in secondo luogo, se le policies configurate consentissero effettivamente il transito del traffico stesso.
• Test del percorso di ritorno dei pacchetti AWS: lo strumento AWS Network Reachability Analyzer si è rivelato di grande utilità per simulare e testare la raggiungibilità da AWS verso GCP. Sono stati impostati come IP_SRC e IP_DST gli stessi indirizzi (invertiti) utilizzati dal fornitore nei test che evidenziavano il problema.
  NOTA: Questo strumento NON tiene conto di eventuali blocchi imposti da NGFW o, in generale, da dispositivi di ispezione attiva del traffico. È fondamentale tenere presente questa limitazione indipendentemente dall'esito del test.

Verifiche contemporanee, condotte a diversi livelli sia sul NGFW che lato AWS, hanno evidenziato quanto segue:

• Dai log del traffico che attraversava il NGFW, sono stati riscontrati pacchetti inviati da GCP negati a causa dell'assenza di una policy che consentisse quello specifico traffico.
• Lo strumento AWS Reachability Analyzer, simulando il traffico di ritorno dal TGW attachment di tipo DirectConnect (quello che conduce verso le destinazioni testate da GCP) verso l'IP sorgente utilizzato dal fornitore, ha dato come esito del test: "NotReachable", con la motivazione che "non è possibile trasmettere il pacchetto poiché la rotta verso il prossimo TGW Attachment, per la destinazione di ritorno, contiene una rotta per lo stesso CIDR con priorità maggiore".

Il messaggio esatto riportato da Reachability Analyzer è stato: "ExplanationCode": "TGW_RTB_HIGHER_PRIORITY_ROUTE" (Riferimento AWS).

In origine, la configurazione specifica di quella particolare tabella di routing del TGW prevedeva, per la destinazione il range IP del fornitore, instradamento contemporaneamente verso due risorse di tipo AWS VPN, per un totale di quattro tunnel BGP distinti attivi e quattro possibili "strade" attraverso cui transitare. Cosa significa esattamente TGW_RTB_HIGHER_PRIORITY_ROUTE e come opera il Transit Gateway in questo contesto?

Questo codice (TGW_RTB_HIGHER_PRIORITY_ROUTE) viene generato quando nella Transit Gateway Route Table esistono più rotte valide per la stessa destinazione, ma una di esse ha una priorità più elevata secondo la logica interna del TGW. 

In caso di rotte BGP duplicate, il TGW seleziona una sola "active route" tra quelle annunciate, mentre le altre rimangono "non active" (shadow routes).
Il Reachability Analyzer, durante l'analisi del traffico, evidenzia questa situazione proprio con TGW_RTB_HIGHER_PRIORITY_ROUTE perché la rotta che ci si aspettava venisse utilizzata non è quella effettivamente selezionata (ne esiste una con "priorità superiore").

In definitiva, il problema nasce qui dal fatto che due AWS VPN diverse annunciavano le stesse reti all’interno della route table del Transit Gateway (TGW) associata all’ultimo tratto del percorso di ritorno. Poiché la TGW riceveva due rotte equivalenti, ne selezionava solo una come attiva. Di conseguenza, il Reachability Analyzer segnalava la presenza di una “higher-priority route”.

Soluzione adottata

Una volta determinata la duplice natura del problema, si è provveduto a:

• Configurare le opportune policy sul NGFW per consentire il traffico in ingresso verso le destinazioni finali.
• Propagare una sola delle due VPN AWS equivalenti nella TGW RT associata alla VPC SICUREZZA (l'ultimo tratto del traffico di ritorno prima di entrare nella VPN). Questa operazione è stata eseguita sia per le VPN provenienti da GCP Milano che per quelle provenienti da GCP Torino.

I risultati

Dopo l'applicazione delle modifiche:

• Il traffico inviato dal fornitore attraverso la specifica VPN AWS (la cui corrispondente lato GCP è impostata come prioritaria) raggiunge correttamente la destinazione sia da GCP Milano che da GCP Torino.
• Lo stesso traffico riesce a tornare indietro dalla destinazione attraverso la medesima VPN di provenienza e, in particolare, attraverso lo stesso tunnel, grazie all'implementazione del protocollo ECMP (Equal Cost Multi Path) su entrambi i lati (TGW AWS e Cloud Router lato GCP), oltre al BGP (per tutte le VPN AWS esistenti).
• Non sono stati più riscontrati connection timeout.

Le raccomandazioni conclusive

Questo caso ha evidenziato alcune lezioni importanti, oltre a non dare mai per scontata la presenza di policy sui NGFW che consentano effettivamente il traffico. Le elenchiamo e ne diamo spiegazione in modo sintetico.

Gestione delle propagazioni nel Transit Gateway

È fondamentale evitare di propagare simultaneamente più VPN che annunciano gli stessi prefissi verso la stessa route table. Ciò può generare comportamenti non deterministici del routing e anomalie come quelle rilevate dal Reachability Analyzer.

Ruolo della simmetria del traffico

In presenza di firewall stateful o NGFW, la coerenza tra percorso di andata e ritorno è essenziale. Percorsi asimmetrici possono causare il blocco del traffico legittimo.

Gestione della ridondanza

L'utilizzo di una sola VPN attiva con due tunnel e di una seconda in standby (ulteriori due tunnel) rappresenta la soluzione più stabile per garantire alta disponibilità senza introdurre ambiguità di routing.

Importanza della validazione periodica

Strumenti come AWS Reachability Analyzer, VPC Flow Logs e i logs BGP del Cloud Router GCP dovrebbero essere utilizzati regolarmente per verificare la correttezza del percorso e la coerenza delle rotte propagate.

Queste competenze di natura tecnica, unite a un metodo di lavoro strutturato e orientato ai punti centrali del problema, sono ciò che rende Miriade un alleato competente e strategico per affrontare anche le sfide complesse: affidabile, attento e sempre orientato a costruire soluzioni stabili, scalabili e pensate su misura per gli obiettivi dei clienti.