VPN site-to-site tra AWS e Azure: scrivete prima la rotta di ritorno

Il tunnel salirà. Di solito succede, perché IKE ha bisogno solo di proposte corrispondenti e di un indirizzo peer raggiungibile. Ciò che fallisce dopo è il percorso di ritorno: il carico su AWS invia pacchetti in un tunnel, ma nulla sul lato Azure sa come rispondere a 10.10.0.0/16, oppure la rotta Azure esiste in una tabella che la subnet di carico non usa. Scrivete il piano delle rotte prima di toccare qualsiasi console, e il tunnel diventerà la parte meno interessante del lavoro.

Passo 1: congelate il piano degli indirizzi

Lavorate con valori concreti. Un carico su AWS si trova su 10.10.1.20 dentro 10.10.0.0/16 e richiede TCP 443 verso un servizio Azure su 10.20.1.30 dentro 10.20.0.0/16. I due intervalli non devono sovrapporsi, e il test di accettazione è la coppia di servizi, non il tunnel.

Annotate questi quattro fatti prima di ogni altra cosa, perché ogni passo successivo viene verificato rispetto a essi.

Passo 2: nominate il gateway che possiede ciascun estremo

AWS Site-to-Site VPN può terminare su un virtual private gateway o su un transit gateway, e sono proprietari di routing diversi. Azure offre il suo VPN Gateway gestito e, separatamente, appliance basate su VM che i clienti gestiscono da soli. Registrate quale coppia avete, perché il salto successivo cambia in ogni combinazione.

Per un gateway gestito, non copiate una rotta che punta a un presunto indirizzo di appliance privata. Per un’appliance, non date per scontato che la propagazione delle rotte nel cloud configuri il sistema operativo guest, perché non lo fa.

Sbagliare qui produce un piano che sembra completo e invia pacchetti a un indirizzo che non risponde mai.

Passo 3: scrivete la rotta che ogni carico usa davvero

Ogni confine qui sotto è una ricerca separata, e una rotta in uno di essi non è una rotta per il pacchetto. Compilate la tabella con i vostri valori prima che il tunnel vada in produzione.

Su AWS, la tabella delle rotte della subnet di carico è vostra da aggiornare anche dopo che BGP o il tunnel sono sani; la panoramica del routing lo considera parte della connessione. Su Azure, una tabella di rotte definite dall’utente è associata a una subnet invece che alla rete virtuale, quindi controllate la rotta effettiva sulla NIC del carico e non nel pannello VNet.

Un gateway Azure gestito può apprendere il prefisso remoto tramite la propagazione del gateway, e una UDR può annullare quella decisione. Aggiungete la UDR quando avete un motivo, non per riflesso. Se la aggiungete, puntatela al salto successivo che il gateway pubblica per il percorso VPN invece di inventare un indirizzo di appliance. Poi rileggete le rotte effettive sulla NIC, perché è lì che la decisione viene davvero presa.

Passo 4: riconciliate l’ambito

Per BGP, confrontate ciò che annuncia ogni lato con ciò che l’altro ha realmente appreso, prefisso per prefisso. Per il routing statico, confrontate gli intervalli remoti configurati con le rotte del carico scritte al passo 3.

Una relazione IKE d’accordo sulla crittografia non è prova che un lato abbia appreso 10.10.0.0/16 o 10.20.0.0/16. Due tunnel possono essere attivi mentre un lato annuncia un solo /24 invece del /16 pianificato. Controllate il prefisso nella tabella di routing, non nello stato del tunnel. La discrepanza emerge dopo come una subnet che funziona e una che non risponde mai.

Passo 5: provate il servizio dalla fonte reale

Consentite il flusso previsto nei gruppi di sicurezza e nelle ACL di rete di AWS, negli NSG di Azure e in qualsiasi filtro di appliance sul percorso. Poi aprite una connessione da 10.10.1.20 all’indirizzo e alla porta approvati del servizio e confermate che la risposta torna alla stessa fonte.

Sia i gruppi di sicurezza del cloud sia gli NSG sono stateful, quindi un pacchetto di ritorno negato è un sintomo di routing, non una regola che avete dimenticato di scrivere al contrario.

Un ping da qualsiasi gateway non risolve nulla. ICMP verso l’indirizzo di un gateway esercita il percorso del piano di controllo, non il servizio TCP inoltrato di cui il carico ha bisogno.

Rollback e registri

Registrate i proprietari delle rotte accanto agli identificatori del tunnel e conservate le tabelle delle rotte precedenti alla modifica. Se la modifica deve essere rimossa, eliminate le rotte del carico prima di smontare il tunnel, così nessuna subnet resta puntata a un salto successivo che non esiste più.

Uno spostamento successivo di subnet o un collegamento spoke ha allora un unico punto definito da aggiornare, invece di un tunnel funzionante che si prende la colpa di una rotta che non ha mai posseduto.