Instrada una sottorete LAN tramite OpenVPN e mantieni la route predefinita

Le macchine che fanno routing per una LAN e nello stesso tempo compongono una VPN finiscono nella stessa discussione con se stesse: il tunnel vuole possedere la route predefinita e la LAN ha bisogno di riaverla. Quando OpenVPN si connette, può installare una route predefinita attraverso il tunnel o una coppia di semi-route predefinite, cosa giusta per un portatile e sbagliata per un gateway i cui vicini si aspettano risposte dal suo indirizzo LAN. La risposta non è saltare la VPN. La risposta è dare alle due decisioni tabelle diverse.

Una route predefinita, due proprietari

Il traffico inoltrato e il traffico generato localmente non devono seguire lo stesso percorso. I client della LAN hanno bisogno del tunnel solo per le destinazioni che scegli, mentre le sessioni di gestione dell’host stesso e le sue risposte a quei client hanno bisogno della route predefinita della LAN. Mescolare entrambe nella tabella principale impone un’unica risposta a due domande diverse.

OpenVPN ha un interruttore proprio per questo. route-noexec impedisce al client di toccare del tutto la tabella principale, e i valori che avrebbe usato vengono esportati a uno script route-up come route_vpn_gateway, dev e gli indirizzi dell’interfaccia. Poi decidi tu quale tabella riceve quale route, in codice che potrai rileggere.

Tabella di policy o riscrittura della principale

La tabella separata è l’unica opzione che scala oltre una sottorete. Dai un nome una volta e poi riferisciti a essa per nome, così nessuno deve ricordare un numero:

echo "10 vpn" >> /etc/iproute2/rt_tables
ip rule add from 192.168.50.0/24 table vpn
ip route add default via 10.8.0.1 dev tun0 table vpn

Gli indirizzi qui sono segnaposto. Sostituisci il prefisso LAN, il gateway del tunnel e il nome del dispositivo del tuo deployment prima di eseguire qualsiasi cosa.

La regola deve corrispondere anche all’host

Una regola che corrisponde solo al prefisso LAN copre i pacchetti inoltrati. Non copre il traffico che il gateway stesso origina, né le risposte che rimanda ai client della LAN, che portano l’indirizzo LAN del gateway come sorgente. Quelle ricerche ricadono su main e possono ancora uscire dal tunnel.

Aggiungi una seconda regola per l’indirizzo LAN del gateway stesso, oppure amplia la prima regola a un insieme che includa entrambe. L’ordine conta: metti prima la regola più specifica e verifica il risultato con una ricerca che nomina esplicitamente la sorgente.

ip route get 203.0.113.9 from 192.168.50.1

Se questo riporta il dispositivo del tunnel per una destinazione che dovrebbe restare locale, l’insieme di regole è sbagliato indipendentemente da ciò che contiene la tabella.

NAT o una route sul lato remoto

Il server VPN conosce la sottorete del tunnel e nient’altro. I pacchetti che arrivano con un indirizzo di origine LAN non hanno via di ritorno a meno che qualcuno non la fornisca, e ci sono esattamente due modi per farlo. Aggiungere una route per il prefisso LAN sul server mantiene la sorgente originale visibile da un capo all’altro, che è ciò che di solito vuole un progetto verificato. Il mascheramento sul gateway riscrive la sorgente all’indirizzo del tunnel e non richiede alcuna collaborazione dal server.

iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

Scegli NAT quando non controlli il server e non puoi aggiungervi route. Scegli la route lato server quando contano i log, il controllo degli accessi o la simmetria del percorso di ritorno, perché il mascheramento cancella l’indirizzo originale da tutto ciò che l’altro lato registra.

In ogni caso l’inoltro deve essere abilitato, e un filtro rigoroso sul percorso inverso può scartare la risposta quando main non avrebbe scelto il tunnel per quella sorgente. Controlla il valore effettivo prima di dare la colpa al tunnel.

Fai sopravvivere la separazione a una riconnessione

Le regole e le route aggiunte a mano spariscono quando l’interfaccia viene ricreata, e una voce di tabella obsoleta può sopravvivere alla sessione che l’aveva giustificata. Metti la regola di tabella, la route del tunnel e la voce di mascheramento nello script route-up del client, e svuota la tabella in cima allo script perché un vecchio gateway non sopravviva nella nuova sessione.

Verifica da entrambi i lati: una ricerca sul gateway con la sorgente LAN e una richiesta reale da un client della LAN verso una destinazione che deve attraversare il tunnel. Una route che esiste ma non viene mai selezionata si comporta esattamente come nessuna route, finché non leggerai i contatori.