Quando il NAT dentro una VPN sito a sito si guadagna il suo posto

Due sedi usano lo stesso intervallo privato, e il tunnel sale mentre nulla di utile lo attraversa. La traduzione è la risposta abituale, ed è una risposta reale: presentare un intervallo diverso al lato remoto può risolvere una sovrapposizione o un percorso di ritorno che l’altra rete non sa instradare. La parte che si salta è che la traduzione cambia gli indirizzi che vede ogni decisione successiva. Trattala come una decisione di progettazione documentata con una mappatura scritta, non come una regola aggiunta finché un ping riesce.

Decidi quale indirizzo viene riscritto

La traduzione di origine cambia ciò che il servizio remoto e i suoi log vedono come client, così un host di filiale diventa un indirizzo di gateway all’arrivo. La traduzione di destinazione o di prefisso presenta invece un indirizzo alternativo per una risorsa remota. Alcune distribuzioni richiedono una traduzione coordinata su entrambi i lati per separare due reti altrimenti identiche, ed è nella combinazione che inizia la maggior parte della confusione.

Scrivi l’origine prima della traduzione, la destinazione come la chiama l’applicazione e la coppia di indirizzi su cui ogni gateway corrisponde. Tre colonne bastano, e la terza colonna è quella che la gente omette.

Anche l’ordine dei selettori conta. La selezione e la traduzione delle politiche IPsec avvengono in fasi definite, quindi un selettore scritto per gli indirizzi precedenti alla traduzione potrebbe non corrispondere mai al pacchetto nella fase che hai supposto. Controlla la politica installata invece di quella che intendevi installare, perché le due divergono esattamente quando una regola è accettata da un componente e ignorata da un altro:

ip xfrm policy show
ip xfrm state show
nft list ruleset | grep -A4 nat

Segui il payload e il percorso di ritorno

Un server che registra l’origine tradotta invece dell’host di filiale individuale romperà qualsiasi regola o report legato all’indirizzo originale. Prima di cambiare la mappatura, scopri se qualcosa a valle prende una decisione da quel campo: liste di accesso, report di audit, limiti di velocità, controlli di licenza. Ognuno di questi è un punto in cui la traduzione riemerge più tardi come un guasto inspiegato.

I protocolli che trasportano indirizzi nel proprio payload richiedono una pianificazione separata, perché riscrivere l’intestazione esterna non tocca il riferimento interno. FTP attivo, SIP e alcuni prodotti di accesso remoto sono i casi classici, e un progetto che li ignora funzionerà per il traffico web e fallirà per l’applicazione che contava.

Il traffico di ritorno dipende da mappature con stato. Il failover del gateway può perdere quello stato, l’instradamento asimmetrico può aggirarlo, e un riavvio può cancellarlo mentre le sessioni restano aperte sul lato remoto. Per questo una richiesta che raggiunge la destinazione e una sessione che si completa sono due risultati di accettazione diversi.

Pesalo rispetto alla rinumerazione di una sede

Rinumerare una sede in conflitto elimina del tutto la mappatura e lascia un piano di indirizzamento leggibile senza tabelle di traduzione. È costoso sul piano operativo: i record DNS, le assegnazioni statiche, le regole del firewall e ogni indirizzo documentato devono cambiare insieme. Il costo arriva una volta, in una finestra pianificata, con uno stato finale chiaro. Quello che compri è la capacità di leggere una cattura di pacchetti anni dopo senza una tabella di ricerca.

La traduzione evita la maggior parte delle modifiche locali e crea una mappatura che va mantenuta in DNS, documentazione e risoluzione dei problemi per sempre. Il costo arriva in modo continuo, sotto forma di ogni futuro ingegnere che deve imparare che un prefisso significa qualcos’altro dentro il tunnel.

Per una connessione temporanea o una rete partner che non controlli, il costo continuo di solito vale la pena. Per due sedi che possiedi e possiederai per anni, la rinumerazione è spesso la decisione più economica una volta che la migrazione è contata onestamente.

Dimostra entrambe le direzioni con una sessione reale

Prova una sessione applicativa invece di una singola sonda. Una richiesta di eco riuscita dimostra che una direzione di un protocollo funziona, ed è del tutto compatibile con un percorso di ritorno che fallisce per qualsiasi cosa con stato. Usa il servizio che ha motivato il progetto e leggi il suo log all’estremità remota per vedere quale indirizzo di origine ha registrato.

tcpdump -ni any host 10.40.9.20 and port 443
conntrack -L | grep 10.40.9.20
ip route get 10.40.9.20

Poi conferma che solo i servizi previsti sono raggiungibili attraverso la mappatura. La traduzione cambia l’indirizzamento e non fa nulla per l’autorizzazione, quindi la politica del firewall decide ancora cosa è consentito. Un progetto che si affida a un prefisso tradotto oscuro come controllo degli accessi non ha alcun controllo degli accessi.

Registra la mappatura, la sessione provata e gli indirizzi osservati da ciascun lato. La prossima persona che eseguirà il debug di questo tunnel ha bisogno di quei tre fatti più che del file di configurazione.