Dovresti applicare SNAT a un inoltro di porta verso una sottorete VPN?

Inoltrare una porta verso un host che sta dietro il client VPN del router fallisce in un modo che sembra un problema di firewall, perché la richiesta arriva chiaramente. Il servizio registra una connessione, il client attende e non torna nulla. La traduzione di destinazione ha fatto il suo lavoro; il pacchetto di ritorno è la parte che è sparita. Una regola NAT sorgente selettiva sul router risolve il problema, e la parte interessante è decidere quanto può essere stretta quella regola.

Perché la risposta prende un'altra strada

Un inoltro di porta riscrive dove va un pacchetto, mai da dove è venuto. L'indirizzo del client internet resta nel campo sorgente per tutto il tunnel, quindi il servizio remoto vede uno sconosciuto e risponde nell'unico modo che conosce: tramite il proprio gateway predefinito. Quel gateway è il concentratore VPN dall'altra parte, che non ha alcuna rotta di ritorno verso un indirizzo pubblico arbitrario.

Guarda una cattura sull'interfaccia del tunnel e l'asimmetria è evidente: pacchetti di richiesta in uscita, nulla in entrata. La catena di inoltro ha consentito il flusso e il tunnel lo ha trasportato, quindi lo scarto avviene dopo che l'host remoto ha già scelto un percorso di ritorno.

Una regola sorgente abbastanza stretta da fidarsene

Rendi il router la sorgente a cui risponde l'host remoto. In questa disposizione l'indirizzo WAN è 203.0.113.24, la LAN è 192.168.88.0/24, l'indirizzo del tunnel del router è 172.20.5.1, e il servizio risponde su 172.20.5.40:8443. La regola sotto corrisponde al pacchetto dopo la traduzione di destinazione, per questo nomina l'indirizzo tradotto e non quello pubblico. Nulla in essa dipende dall'indirizzo del client, ed è esattamente questo il punto.

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

Ogni corrispondenza in quella riga esiste per mantenere la riscrittura locale a un servizio su un tunnel. Togli l'interfaccia o la porta e riscrivi più traffico di quanto il problema richieda, ed è così che una correzione mirata diventa un mistero per la persona successiva.

Quando una maschera globale è la scelta onesta

Se il router inoltra molti servizi nella stessa sottorete VPN, una regola per servizio diventa un elenco che nessuno mantiene. Mascherare tutto ciò che esce dall'interfaccia del tunnel è più semplice e prevedibile, al costo di nascondere il client originale a ogni host dall'altra parte. Sceglilo quando i log laggiù non servono all'attribuzione; mantieni la regola stretta quando servono.

Le due opzioni falliscono anche in modo diverso. Una regola stretta mancante rompe un servizio; una maschera ampia che corrisponde a troppo può riscrivere in silenzio traffico che già funzionava, comprese le connessioni in uscita del router stesso.

Controlla i contatori prima di pubblicare

Le regole che non corrispondono mai sembrano identiche a quelle che funzionano finché non conti i pacchetti. Rileggi la tabella con i contatori di byte prima che qualsiasi client si connetta, poi connettiti da una rete che non è la LAN e rileggila. Due letture sono ciò che trasforma un'ipotesi in un fatto. Pubblica l'inoltro solo dopo che la seconda si muove.

iptables -t nat -L POSTROUTING -v -n --line-numbers

Un contatore a zero sulla regola sorgente dopo una connessione reale significa che la corrispondenza è sbagliata, di solito perché la destinazione o la porta non corrispondono al pacchetto dopo la traduzione. Se il contatore sale ma il client va ancora in timeout, il percorso di ritorno è riparato e qualcos'altro sta scartando la risposta, quindi guarda poi la politica di inoltro dall'altra parte. L'accesso a forcella dall'interno della LAN è un problema separato e richiede una regola propria, non una versione più ampia di questa.