Client OpenVPN per tutta la LAN su OpenWrt: l’ordine che funziona

Quattro lavori indipendenti mettono l’intera LAN di un router dietro un solo tunnel. Il dispositivo del tunnel ha bisogno di un proprietario, di una zona firewall, di una destinazione di traduzione verso l’uplink e, se alcuni client devono restare fuori dalla VPN, di instradamento per indirizzo di origine. A un tunnel che si connette mentre non passa nulla manca di solito uno di questi quattro elementi. Lavorare in ordine di dipendenza significa che un guasto alla fine appartiene al passo che hai appena cambiato. Ogni passo qui sotto termina con qualcosa che puoi osservare, e questo tiene il passo successivo al riparo dalle congetture.

Decidi che cosa condivide il tunnel

Il router che distribuisce Wi-Fi e DHCP può eseguire il client da solo. Così ogni dispositivo collegato finisce dietro il tunnel senza configurazione per dispositivo, ed è la soluzione che vuole la maggior parte dei piccoli siti. È anche quella con il raggio d’azione più ampio quando il tunnel cade, perché ogni dispositivo perde la propria route in una volta. Nulla sulla LAN conserva un’uscita funzionante.

Un secondo router dietro il primo, che esegue il client con una propria sottorete, limita il tunnel ai propri dispositivi. È più facile da rimuovere e più facile da spiegare a chi lo eredita. Il costo è la raggiungibilità tra i due lati senza una route o un inoltro di porta.

In ogni caso, rendi distinte le sottoreti della LAN. Intervalli identici fanno sembrare un lato collegato direttamente, e il buco nero che ne deriva sembra un guasto della VPN per ore.

Dai un proprietario al tunnel

Dichiara il tunnel come interfaccia di rete con un nome, un dispositivo e nessun protocollo proprio. Il sistema di rete crea e gestisce allora il dispositivo, e tutto ciò che sta a valle fa riferimento all’interfaccia per nome, non per dispositivo. È questo che permette alla zona di trovarla.

Non creare lo stesso dispositivo in due posti. Un tunnel fatto a mano accanto a un’interfaccia dichiarata produce un dispositivo che esiste ma non è in nessuna zona, oppure uno che sparisce al riavvio. Entrambi sembrano un guasto del client, e nessuno dei due produce un errore che nomini la causa reale. Scegli il percorso dichiarativo ed elimina quello manuale.

Mantieni il nome identico nella configurazione di rete, firewall e VPN. La zona elenca le reti per nome, quindi un errore di battitura lascia il tunnel fuori da ogni zona mentre l’interfaccia stessa sembra sana. Un’interfaccia sana senza policy è lo stato più difficile da notare.

Mettilo in una zona, poi inoltra verso di essa

Una zona firewall è dove vive la policy: input, output, forward e masquerade. Un tunnel che non è in nessuna zona è governato da valori predefiniti che non hai scelto, e raramente è ciò che serve a un client su router. I blocchi qui sotto dichiarano l’interfaccia, la collocano in una zona e permettono al traffico della LAN di entrare in quella zona.

config interface 'vpn'
    option device 'tun0'
    option proto 'none'

config zone
    option name 'vpn'
    list network 'vpn'
    option input 'REJECT'
    option output 'ACCEPT'
    option forward 'REJECT'
    option masq '1'

config forwarding
    option src 'lan'
    option dest 'vpn'

Sulle versioni precedenti alla 21.02 la stessa riga dell’interfaccia si scrive come option ifname, quindi controlla quale forma interpreta il firmware installato prima di incollare. Il blocco di inoltro è il permesso che consente al traffico della LAN di usare il tunnel. Senza di esso il dispositivo è attivo, il client è connesso e nessun host della LAN raggiunge il tunnel. È la segnalazione più comune di connesso ma senza internet sui client su router.

Il masquerade sulla zona VPN comprime ogni indirizzo della LAN nell’indirizzo del tunnel del router prima che il pacchetto esca. Questo elimina la necessità di una rotta di ritorno verso la tua sottorete dall’altro lato.

Se l’altro lato instrada già la tua LAN, disattivare il masquerade mantiene visibili gli indirizzi di origine e rende significativi i log per client. Scegli una delle due e annota quale, perché le due scelte producono più avanti domande di supporto diverse. Rimuovere l’inoltro predefinito da LAN a WAN è una decisione separata con la sua conseguenza. Toglilo e l’accesso a internet del router se ne va con esso.

Nomina l’uplink reale nel NAT

Sui firmware in cui la regola di traduzione è scritta a mano, l’interfaccia in uscita è il campo che va storto. Una regola che nomina vlan2 non fa nulla quando la sessione termina su ppp0. Una regola senza alcuna interfaccia può tradurre traffico che sarebbe dovuto restare privato. Nessuno dei due errori si annuncia, perché il tunnel continua a funzionare.

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

Sostituisci ppp0 in quella regola con l’interfaccia ricavata da ip route o dall’elenco delle interfacce attive, poi osserva il contatore mentre un host della LAN carica una pagina. Su un router con un solo provider, una regola di masquerade per l’uplink di solito basta. Una seconda regola per l’interfaccia del tunnel non sostituisce la prima.

Poi aggiungi le opzioni del client che decidono cosa entra nel tunnel. Una direttiva redirect-gateway manda il traffico internet del client attraverso la VPN, e senza di essa il tunnel porta solo le route che il server spinge. Controlla la tabella delle route risultante prima di toccare il DNS.

Dividi il Wi-Fi con una seconda tabella

Una tabella di routing non può contenere due default. Un secondo SSID che deve aggirare il tunnel ha quindi bisogno di una propria sottorete e di una propria tabella. Assegna al SSID incanalato un intervallo proprio, poi instrada solo quell’intervallo nel tunnel con una regola che seleziona la tabella.

I pacchetti di policy routing su OpenWrt esprimono esattamente quella combinazione. Funziona anche a mano, con una regola per l’origine e una tabella il cui default punta al dispositivo del tunnel.

Controlla la separazione da entrambe le reti. Un client sul SSID incanalato dovrebbe presentare l’indirizzo di uscita della VPN, e un client sul SSID normale quello del provider. Quando entrambi sembrano uguali, la regola coincide con l’origine sbagliata o la tabella non viene mai consultata. Prova anche dopo una riconnessione, perché una regola che dipende dal nome dell’interfaccia si rompe quando il dispositivo viene rinumerato.

Sospetta dell’orologio e del flag del dispositivo

Il flag persist-tun lascia il dispositivo del tunnel al suo posto tra un riavvio e l’altro. Questo va bene a un server e confonde un client il cui stato dovrebbe essere ricostruito da zero. Rimuovilo mentre diagnostichi un client su router, perché un dispositivo che sopravvive a una negoziazione fallita nasconde quale passo si è rotto davvero. Rimettilo quando il client si connette in modo affidabile, e non prima.

L’orologio è l’altro guasto silenzioso. Un router senza orologio alimentato a batteria parte dall’epoca, il che significa che i controlli dei certificati falliscono finché NTP non si allinea. Confronta i timestamp del log con l’ora reale prima di toccare un certificato, perché un client che si connette un minuto dopo l’avvio di solito sta aspettando la sincronizzazione dell’orario.