Pubblicare un servizio LAN sull’indirizzo proprio del gateway VPN

Presentare un dispositivo LAN su uno degli indirizzi tunnel propri del gateway richiede una sola riga di NAT. La connessione fallisce comunque, perché il dispositivo che risponde non ha idea che l’indirizzo del client sia raggiungibile attraverso quel gateway. Seguite il pacchetto dal client verso l’interno, poi seguite la risposta di ritorno verso l’esterno, e la metà mancante diventa evidente.

Partite dal punto di vista del client

Il client di questo esempio si trova nel pool VPN 10.62.0.0/24 e si connette a 10.62.0.1 sulla porta 8080. Quell’indirizzo appartiene al gateway stesso, quindi il pacchetto arriva nel kernel del gateway e non a un altro peer. Dietro il gateway, la LAN è 172.21.4.0/24. Il gateway possiede 172.21.4.10 e il dispositivo che serve davvero HTTP è 172.21.4.40.

Un indirizzo che appartiene a un altro peer VPN non è intercambiabile con l’indirizzo di servizio del gateway. Se il client si connette all’indirizzo di un peer, nessuna regola del gateway è coinvolta e tutto questo percorso è il caso sbagliato.

Delimitate la traduzione di destinazione di proposito

La versione stretta presenta una sola porta e riscrive solo la destinazione. Il pacchetto conserva il protocollo e la sorgente, ed è questo che rende interessante il resto del percorso.

iptables -t nat -A PREROUTING -i tun0 -s 10.62.0.0/24 -d 10.62.0.1 -p tcp --dport 8080 -j DNAT --to-destination 172.21.4.40:80

Una regola senza criteri di protocollo e porta è la versione ampia: conserva la porta scelta dal client e cambia solo l’indirizzo. È legittima quando si vuole presentare l’intero host e sbagliata quando l’intento era un solo servizio. Rileggete la regola e confermate il nome dell’interfaccia. Una regola DNAT sull’interfaccia sbagliata non corrisponde a nulla, il che produce lo stesso timeout di una regola assente e fa perdere un’ora a guardare il dispositivo.

Fate concordare il confine dell’inoltro

La traduzione cambia l’intestazione, non concede il permesso. Con una politica di scarto predefinita il flusso inoltrato ha bisogno della propria accettazione, e la direzione di ritorno ha bisogno della regola di connessione stabilita che la vostra politica probabilmente già ha.

iptables -A FORWARD -i tun0 -o lan0 -d 172.21.4.40 -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Un’accettazione incondizionata per ogni flusso DNAT è più ampia di questo progetto e permetterà anche mappature aggiunte più tardi da qualcun altro. Nominate la destinazione e la porta, e lasciate chiuso il resto. Se i contatori della regola di inoltro restano a zero mentre quelli del NAT salgono, il pacchetto viene scartato prima della vostra regola. Leggete l’ordine delle catene invece di aggiungere una seconda copia.

Il dispositivo deve rispondere in qualche modo

Dopo la traduzione il dispositivo vede una sorgente in 10.62.0.0/24. La sua risposta va al gateway predefinito, che è il router della LAN, non il gateway VPN, a meno che qualcosa non gli dica il contrario. Due disposizioni lo correggono e non sono equivalenti. Una rotta sul dispositivo o sul router della LAN invia 10.62.0.0/24 a 172.21.4.10 preservando la sorgente del client. Una traduzione di sorgente limitata nasconde invece il client dietro l’indirizzo LAN del gateway.

ip route add 10.62.0.0/24 via 172.21.4.10 dev eth1
iptables -t nat -A POSTROUTING -s 10.62.0.0/24 -d 172.21.4.40 -o lan0 -p tcp --dport 80 -j SNAT --to-source 172.21.4.10

Scegliete in base a ciò che serve al servizio. La politica per client e i log significativi vogliono la forma instradata; un dispositivo a cui non si può dare una rotta, o un servizio che deve semplicemente vedere un indirizzo LAN, indicano la forma tradotta. Non ricorrete a una regola masquerade globale per far funzionare una sola risposta. Nasconde ogni client da ogni destinazione e rompe silenziosamente le politiche che dipendono dagli indirizzi di sorgente.

Non provate dal gateway stesso

Una richiesta generata sul gateway verso 10.62.0.1 esce dalla catena OUTPUT, non dalla PREROUTING in ingresso. Il suo fallimento o successo non dice nulla sulla regola rivolta al client, ed è così che le persone concludono che una regola funzionante è rotta.

conntrack -L | grep 172.21.4.40
tcpdump -ni any 'port 8080 or port 80'

Eseguite una vera richiesta client e leggete entrambe le cose. La voce conntrack mostra la traduzione applicata, e le catture mostrano se la richiesta è passata alla LAN e se è tornata una risposta verso il tunnel. Usate una connessione nuova dopo aver cambiato le regole, perché lo stato esistente conserva la mappatura precedente e continuerà a fallire alla vecchia maniera. Poi confermate l’intera conversazione: l’indirizzo del dispositivo, il permesso di inoltro e la rotta di risposta descrivono lo stesso flusso.