Estensione del sito VPN: seguire la rotta di ritorno oltre il gateway

Il traffico di una filiale termina su un gateway la cui LAN non contiene l’applicazione che dovevate raggiungere. Il server si trova in un secondo data center, oltre un collegamento interno che la VPN non ha mai configurato. Aggiungere un altro prefisso al gateway vicino non fa nulla per quel caso, perché il gateway remoto è un punto terminale di cifratura e non l’ultimo router. Il percorso richiede una rotta in avanti, un’ammissione al confine di sicurezza remoto e una decisione di ritorno nella rete della destinazione stessa.

Il gateway remoto è un punto terminale di cifratura

L’IPsec da gateway a gateway protegge il traffico tra due dispositivi di sicurezza, e gli indirizzi interni attraversano quel segmento cifrati. Oltre il gateway remoto subentra l’instradamento ordinario, compresa qualsiasi politica esistente tra data center. Il segmento protetto copre quindi una parte del viaggio e non il resto. Presumere il contrario è il modo in cui un progetto finisce con un tunnel sano e un’applicazione irraggiungibile.

Disegnate il percorso in tre parti: filiale verso gateway vicino, vicino verso remoto, remoto verso l’applicazione. Ogni parte ha il proprio responsabile e il proprio modo di guasto.

Leggete entrambe le direzioni della politica del tunnel

Una politica del tunnel viene di solito scritta dal punto di vista del lato locale, ed è da questa abitudine che nascono le configurazioni parziali. Entrambi i peer devono elencare l’origine della filiale e la destinazione come appariranno dentro il tunnel, compresa qualsiasi traduzione prevista dal progetto. Aggiornare solo l’estremità vicina produce un disallineamento di fase due che sembra un guasto di instradamento. Confrontate i due insiemi di politiche prima di toccare qualsiasi rotta.

Scrivete origine e destinazione come indirizzi anziché come nomi di sito. L’ambiguità qui riemerge più tardi come un’asimmetria sconcertante.

Aggiungete la rotta in avanti e confermate l’ammissione

Il gateway remoto ha bisogno di una rotta verso la sottorete dell’applicazione, e ogni router tra di essi deve ammettere l’origine della filiale. Verificate ciò che il gateway remoto ha davvero invece di ciò che afferma lo schema.

ip route get 10.30.5.10 from 10.10.1.50
traceroute -n -s 10.10.1.50 10.30.5.10

Il primo comando riporta l’interfaccia di uscita e il next hop che il gateway remoto sceglierebbe per quell’origine, una domanda a cui una normale tabella di instradamento non può rispondere. La traccia mostra dove si fermano i pacchetti, e un’interruzione dopo il gateway remoto indica il transito interno anziché il tunnel. Quando la rotta esiste e il traffico sparisce comunque, catturate sul gateway remoto e leggete l’indirizzo di origine in arrivo, perché un indirizzo inatteso significa che una traduzione avviene da qualche parte senza pianificazione. Tutti gli indirizzi qui sono segnaposto, quindi sostituite le vere sottoreti di filiale, transito e applicazione.

Provate dalla filiale, poi riprovate il vecchio percorso

L’accettazione richiede un’origine reale anziché una sonda dal gateway remoto. Eseguite il controllo da un host della filiale e mantenete le destinazioni che già funzionavano nella stessa prova.

curl -sS -m 5 http://10.30.5.10:8080/health
ping -c 3 10.20.1.1

Una risposta dall’applicazione dimostra insieme il percorso di andata e quello di ritorno, mentre il ping verso la vecchia destinazione dimostra che la modifica non ha rotto ciò che già funzionava. Rilevate l’indirizzo di origine che l’applicazione registra, perché le sue regole di accesso e qualsiasi rotta di ritorno devono corrispondere a quel valore. Dove la filiale traduce prima del tunnel, l’indirizzo della politica e l’indirizzo che l’applicazione vede differiscono per progetto, quindi annotate entrambi. Ripetete la prova dopo un rinnovo della chiave o una modifica dell’instradamento, perché questi percorsi tendono a essere validati una volta e poi dimenticati.

Assegnate un responsabile a ciascuno dei tre segmenti e alla rotta di ritorno dentro la rete di destinazione. Un percorso con quattro responsabili fallisce nelle lacune tra di loro.