Aggiungere una sottorete locale a una VPN AWS: VGW o Transit Gateway

Una VPN Site-to-Site esistente trasporta 10.60.0.0/16, una nuova rete di servizio compare dietro lo stesso gateway locale come 10.70.0.0/16, e qualcuno chiede se serve un proxy. Di solito no: un percorso instradato può trasportare il prefisso, ma solo se tre cose coincidono, e quali tre dipende dall’architettura AWS che già gestite. Un gateway privato virtuale ha un limite di tabella di routing; un transit gateway ne aggiunge un secondo. Un annuncio corretto con una tabella sbagliata produce una sessione che sembra sana e non consegna nulla.

Pubblicate un prefisso che il gateway possa davvero consegnare

Il gateway locale ha bisogno di una rotta in avanti verso la nuova rete prima che qualsiasi annuncio abbia senso. Annunciare 10.70.0.0/16 via BGP dice ad AWS dove inviare i pacchetti per quell’intervallo; non crea il percorso di inoltro locale che rende l’intervallo raggiungibile all’altro capo. Verificate che il gateway abbia una rotta per il prefisso che punta al dispositivo che lo detiene, e che il dispositivo sia configurato per rispondere per quegli indirizzi. La politica di esportazione e i limiti di prefisso accettati sono il vincolo successivo, perché un prefisso che la sessione filtra non arriva mai ad AWS.

Mantenete aggregati e rotte più specifiche in modo deliberato. I percorsi sovrapposti che arrivano da due direzioni sono una decisione di progettazione, non un dettaglio da scoprire dopo.

Percorso uno: il limite del gateway privato virtuale

Con un gateway privato virtuale, la documentazione di routing di AWS VPN descrive due modalità di distribuzione, rotte statiche e annunci BGP, ed entrambe dipendono dalla tabella di routing della sottorete che l’applicazione usa davvero. La propagazione è comoda quando controllate l’intero intervallo, e una rotta esplicita è più facile da ragionare quando volete la destinazione elencata accanto al target. In ogni caso la verifica è la stessa: la tabella della sottorete applicativa specifica contiene un percorso funzionante verso il target VPN per il nuovo prefisso, e vince contro qualcosa di più specifico?

Una sessione BGP sana dimostra che il canale esiste. Non dice nulla sul fatto che una certa tabella di sottorete abbia consumato la rotta.

Percorso due: il transit gateway aggiunge una tabella

Un transit gateway divide quella singola domanda in due. La sottorete della VPC deve inviare la destinazione all’attacco del transit gateway, e poi la tabella di routing del transit gateway deve selezionare l’attacco VPN per lo stesso prefisso. Le scelte di associazione e propagazione determinano quali reti collegate ricevono la rotta, quindi un prefisso può essere annunciato correttamente dalla VPN e comunque non raggiungere mai la VPC la cui tabella non è mai stata associata alla tabella di routing corretta.

Il guasto comune è una rotta che esiste in una tabella e non nell’altra, con ogni team convinto che il proprio lato sia corretto. Quando confrontate le due architetture, questo limite in più è tutta la differenza: più posti da controllare e un controllo più preciso su chi riceve la rotta.

Anche la propagazione delle rotte non concede il prefisso a ogni attacco. Lo distribuisce alle tabelle configurate per riceverlo.

Il percorso di ritorno è una decisione di politica a sé

Il traffico in arrivo è solo metà dello scambio. La nuova rete locale ha bisogno di una rotta di ritorno verso i prefissi di origine AWS attraverso il gateway corretto, e la politica di sicurezza su entrambe le estremità deve consentire quella coppia di origine e destinazione. Se il tunnel negozia un ambito di protezione con selettori di traffico, il nuovo prefisso deve esserne dentro, altrimenti il pacchetto viene scartato prima che venga consultata qualsiasi tabella di routing.

La sovrapposizione degli indirizzi è l’altra trappola. Intervalli disgiunti e con proprietà esplicita mantengono questo semplice; intervalli sovrapposti significano traduzione o riprogettazione, e nessuno dei due è una variante interscambiabile della stessa ricetta.

Provate con un’origine nella nuova rete e una destinazione nella sottorete dell’applicazione, poi ripetete nella direzione opposta. Un test unidirezionale dimostra una sola direzione.

Quando il proxy è davvero il limite migliore

Un proxy si guadagna il suo posto quando il requisito è un’interfaccia di servizio ristretta, quando l’applicazione si aspetta già quell’architettura, o quando il percorso di rete non può essere reso capace di trasportare il prefisso senza una traduzione che non volete. Non è la soluzione di ripiego per una voce di tabella di routing che nessuno ha controllato.

Decidete in questo ordine: inoltro locale, annuncio, limite della tabella, politica di ritorno. Correggete il primo che fallisce, e solo allora chiedete se il percorso instradato sia davvero la risposta giusta.