Instrada tra LAN private prima di aggiungere un altro NAT

Due firewall interni, un segmento di transito privato e una richiesta per lasciare che alcuni host di ciascuna LAN parlino con quelli dell’altra. Il riflesso è alzare una VPN o aggiungere un secondo strato di NAT, e entrambi i riflessi costano più di quanto il problema meriti. Il routing ordinario basta quando valgono tre condizioni: gli intervalli di indirizzi non si sovrappongono, entrambe le parti possono restituire il traffico all’altra LAN e il segmento di transito è già abbastanza fidato per i dati. Controlla questi tre prima di progettare qualcosa, perché ognuno cambia la risposta.

Tre condizioni che decidono il progetto

La prima condizione è lo spazio di indirizzi. Se entrambe le LAN usano lo stesso blocco RFC 1918, il routing non può distinguerle e la traduzione diventa inevitabile anziché opzionale. La seconda è un percorso di ritorno: una rotta da A a B è inutile se B non sa anche come raggiungere la LAN di A, e la conoscenza asimmetrica è il motivo più comune per cui un progetto instradato scarta le risposte in silenzio.

La terza è la fiducia. Il routing sposta i pacchetti; non li protegge. Un segmento di transito privato dentro un edificio è un’altra cosa rispetto a una consegna a un fornitore o a un collegamento che attraversa un backbone di campus condiviso. Se il segmento non è fidato, la risposta è un tunnel tra i due firewall, e il piano di routing qui sotto vale ancora al suo interno.

Solo quando tutte e tre puntano nella stessa direzione il progetto semplice vince. Quando una fallisce, correggi quella condizione esplicitamente invece di coprirla con la traduzione, perché il NAT nasconde il guasto invece di risolverlo.

Costruisci il piano delle rotte sulla rete di transito

Dai a ogni firewall un indirizzo sul segmento condiviso e aggiungi una rotta specifica per ogni LAN remota. Nient’altro della configurazione esistente deve spostarsi, e in particolare la rotta predefinita verso internet deve restare esattamente dov’è. Sostituire una rotta predefinita con il firewall pari invierebbe ogni destinazione non correlata attraverso il transito, che è un cambiamento molto più grande di quello richiesto. La documentazione pfSense sul routing statico descrive lo stesso modello rotta più gateway per quella piattaforma, e il controllo equivalente esiste su qualunque firewall tu esegua davvero.

Il firewall A serve 10.30.0.0/24 e il firewall B serve 10.40.0.0/24, con i due indirizzi di transito su 192.0.2.0/24. Ogni host della LAN mantiene il proprio firewall locale come gateway, quindi l’unico nuovo stato è una rotta su ciascun lato. Su un firewall basato su Linux lo stesso piano appare così, e l’inoltro deve essere abilitato, altrimenti la rotta verrà risolta mentre il pacchetto viene scartato.

sysctl -w net.ipv4.ip_forward=1
ip route add 10.40.0.0/24 via 192.0.2.20 dev eth1
ip route get 10.40.0.15
traceroute -n 10.40.0.15

Tieni il filtraggio separato dalla traduzione

Routing e policy sono controlli diversi, ed è sul secondo che la maggior parte dei progetti instradati fallisce davvero. Consenti le sorgenti, le destinazioni e i servizi specifici alla frontiera d’ingresso che i pacchetti attraversano davvero, e ricorda che un’etichetta di interfaccia come WAN è un nome, non un’affermazione sulla fiducia. Una porta di transito che porta traffico privato può avere ancora il blocco degli indirizzi privati attivo per impostazione predefinita.

Poi guarda la traduzione in uscita prima di concludere che non avviene alcun NAT. Regole in uscita automatiche possono riscrivere traffico che non era mai destinato a essere tradotto, e questo distrugge gli indirizzi di origine che servono all’altra parte per la propria policy e i propri log. Conferma che i flussi scelti conservino gli indirizzi originali e lascia in pace le regole di traduzione internet per il traffico che ne ha ancora bisogno.

iptables -t nat -S POSTROUTING
iptables -t nat -L POSTROUTING -n -v
tcpdump -ni eth1 -c 5 host 10.40.0.15

Quando il NAT è la risposta onesta

La traduzione si guadagna il suo posto quando gli intervalli di indirizzi si sovrappongono davvero e la rinumerazione non è disponibile, oppure quando una policy richiede che un lato veda un solo indirizzo invece di una sottorete. In quei casi una mappatura deliberata uno-a-uno o limitata alle porte è una decisione di progetto con conseguenze note, non un espediente.

La conseguenza da dire ad alta voce è che l’altra parte non può più vedere né filtrare le singole sorgenti. I log si riducono all’indirizzo che traduce, la policy per host smette di funzionare e la risoluzione dei problemi diventa una caccia a quale host interno possedeva un flusso in un dato momento. Se nulla di tutto questo conta per il traffico in questione, il NAT va bene.

Quando il transito stesso è l’ipotesi sbagliata

Se il segmento condiviso attraversa un fornitore, una matrice di commutazione condivisa o qualsiasi percorso in cui un’altra parte potrebbe leggere il traffico, il solo routing non è una risposta completa. Un tunnel tra i due firewall dà riservatezza e autenticazione del pari, e la tabella di routing al suo interno è la stessa tabella che avresti scritto sul transito.

Decidilo dalla domanda sulla fiducia della prima sezione, non da un’abitudine secondo cui le VPN sono più sicure. Un tunnel su un segmento già privato aggiunge costo operativo e un’altra modalità di guasto senza alcun guadagno, mentre il routing su un segmento non fidato scambia la riservatezza con una semplicità che non puoi permetterti. Scrivi quale delle tre condizioni ha guidato la scelta, e il prossimo ingegnere non dovrà ridiscuterla.