SNAT, DNAT e Masquerade: cosa fa ogni regola NAT di una VPN

Metti una cattura su entrambi i lati di un gateway VPN e un solo flusso può mostrare quattro indirizzi diversi. Il NAT di origine riscrive da dove il pacchetto dichiara di venire; il NAT di destinazione riscrive dove va. Masquerade non è una terza direzione, è una regola di NAT di origine che prende il suo indirizzo dall’interfaccia in uscita invece che da un valore fisso. Nomina quale delle tre ti serve davvero e la maggior parte dei ticket «la VPN è rotta» si riduce a una domanda sul percorso di ritorno.

Cosa riscrive ogni regola

Il NAT di origine, di solito scritto SNAT, cambia l’indirizzo di origine di un flusso quando esce da un router o da un gateway. Il servizio che riceve risponde all’indirizzo tradotto, e la macchina che traduce annulla la modifica usando lo stato che ha conservato per quella connessione. Su Linux quello stato vive in conntrack, per questo conntrack -L stampa le tuple originale e di risposta una accanto all’altra.

Il NAT di destinazione, DNAT, cambia invece la destinazione. Un pacchetto indirizzato a un indirizzo pubblico su UDP 51820 può essere riscritto verso un server WireGuard interno a 10.8.0.2:51820. È così che un router domestico o un bilanciatore cloud pubblica un listener VPN, e questo non dice nulla su ciò che il tunnel potrà trasportare dopo.

Masquerade appartiene alla famiglia SNAT. La regola non nomina alcun indirizzo; usa quello che l’interfaccia in uscita ha quando il pacchetto parte. Linux le assegna un proprio target, ed è la scelta abituale su un’interfaccia WAN che riceve l’indirizzo via DHCP o PPPoE.

Dove vive la mappatura decide il guasto

Annota la tupla a ogni confine: prima del tunnel, al suo interno e sull’interfaccia pubblica. Una cattura dentro il tunnel differisce legittimamente da una all’esterno, e chi confronta le due senza sapere dove avviene la traduzione inseguirà l’host sbagliato.

Il traffico di ritorno deve passare dal dispositivo che detiene la mappatura. Se la risposta prende un’altra strada, un secondo uplink, una rotta di policy o un provider che non ha mai sentito parlare del tuo range privato, la traduzione inversa con stato non avviene mai e il client vede traffico a senso unico. Aggiungere altro NAT di origine raramente risolve una rotta di ritorno mancante; può nascondere il sintomo su un flusso mentre rompe la policy basata sugli indirizzi ovunque altrove.

L’altro errore comune è aspettarsi che un tunnel crei raggiungibilità. Un client privato i cui pacchetti escono verso internet ha bisogno di un assetto in uscita valido: una rotta predefinita, un gateway che inoltra e, di solito, traduzione di origine verso un indirizzo pubblico. La cifratura da sola non rende raggiungibile un indirizzo privato.

Masquerade o SNAT esplicito

Confrontali per ciò che promettono. Masquerade sceglie l’indirizzo di uscita, lo SNAT esplicito lo fissa. Su un gateway con un indirizzo pubblico stabile, fissarlo dà ai log e alle liste di permesso dei partner un valore prevedibile. Su un collegamento WAN dinamico, un indirizzo SNAT fissato diventa sbagliato nel momento in cui cambia la lease, ed è esattamente il caso per cui è stato costruito Masquerade.

La portata conta quanto la scelta. Una regola Masquerade che corrisponde a ogni pacchetto che lascia il gateway, senza limiti di origine o destinazione, traduce anche traffico che volevi lasciare intatto, compreso il traffico verso altre reti private. Limita la regola al range dei client, alla destinazione prevista e all’interfaccia.

È con IPsec basato su policy che questo morde più forte. La guida all’inoltro di strongSwan illustra come abilitare l’inoltro IP e aggiungere una regola SNAT di origine per i client, e la stessa documentazione copre l’esclusione del traffico che deve conservare l’indirizzo originale. Traduci un’origine prima che la policy di sicurezza la incontri e il tunnel può salire mentre il traffico continua a cadere, perché il pacchetto non somiglia più al selettore negoziato.

Decidi anche cosa deve vedere l’estremità remota. Dopo la traduzione un servizio vede il gateway, non il singolo client. Questo semplifica l’instradamento di ritorno e allo stesso tempo appiattisce i log e annulla le liste di permesso per client. Se conservare gli indirizzi dei client conta, pianifica un percorso di ritorno instradato invece di nasconderli per far passare un test.

Leggere le regole su un gateway Linux

Un gateway di accesso remoto con client su 10.8.0.0/24 e un’interfaccia WAN chiamata eth0 richiede l’inoltro abilitato e una policy di filtraggio che consenta il flusso prima che qualsiasi regola NAT possa aiutare. La versione iptables tiene entrambe le direzioni nella tabella nat:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 51820 \
  -j DNAT --to-destination 10.8.0.2:51820

La forma nftables usa gli stessi due hook con un’interfaccia nominata e una catena esplicita:

nft add rule ip nat postrouting ip saddr 10.8.0.0/24 oifname "eth0" masquerade
nft add rule ip nat prerouting iifname "eth0" udp dport 51820 dnat to 10.8.0.2:51820

Entrambi gli estratti presuppongono che la catena di filtraggio accetti già il flusso inoltrato. NAT non è una regola di permesso, e un pacchetto tradotto correttamente può comunque essere scartato una tabella più avanti. Conferma la mappatura viva con conntrack -L, conferma cosa è caricato con nft list ruleset o iptables-save -t nat, poi cattura su entrambe le interfacce per vedere l’indirizzo cambiare davvero.

Modalità di guasto che sembrano una regola sbagliata

Il traffico a forcella è il classico. Un client interno che raggiunge un server interno tramite l’indirizzo pubblico del server ha bisogno del DNAT in ingresso e di una traduzione di origine in uscita di ritorno, altrimenti il server risponde direttamente al client e la risposta viene rifiutata. La correzione è una seconda regola, più stretta, per quel caso interno-verso-pubblico, non una regola Masquerade più ampia per tutto.

La doppia traduzione è quella silenziosa. Un client già dietro NAT di livello operatore arriva al tuo gateway con un indirizzo che non puoi instradare indietro, quindi traduci di nuovo. Funziona, ma i log ora portano due salti di indirizzamento privato e ogni indagine ha bisogno di entrambe le mappature. IPsec basato su policy aggiunge un terzo giro: traduci prima della corrispondenza di policy e ottieni una SA alzata senza traffico che passa, il che si legge come un bug del firewall e non del NAT.

Poi c’è il test che passa e la distribuzione che fallisce. Eseguire il comando NAT a mano dimostra il meccanismo, non la configurazione. Una regola aggiunta a runtime sparisce al riavvio o al successivo evento dell’interfaccia, e una regola Masquerade legata a un’interfaccia che cambia numero può cambiare in silenzio l’indirizzo che l’estremità remota vede. Metti la regola nella configurazione del firewall che la possiede e ritesta dopo una riconnessione.

Lista di controllo prima di salvare la regola

Nomina prima la direzione: origine, destinazione o entrambe. Poi individua chi deve detenere lo stato — il gateway, il router a monte o il peer IPsec — e conferma che il percorso di ritorno ripassi da lì. Limita la regola al range di client, alla destinazione e all’interfaccia che intendi davvero, e decidi in anticipo se l’estremità remota debba vedere il gateway o l’indirizzo originale del client.

Prova da un client, non dal gateway. Un browser sul gateway stesso può aggirare del tutto la regola di traduzione dei client, quindi una pagina che funziona lì non dimostra nulla sul tunnel. Invia una richiesta originata dal client, osserva i contatori e la tabella conntrack, e ripeti dopo una riconnessione del tunnel e un cambio di indirizzo WAN se una delle due cose è possibile dove lavori.