I client della LAN ignorano la VPN del router finché non si attiva il routing per criteri
Le regole di inoltro permettono i pacchetti, ma non scelgono mai un'interfaccia. Una tabella di criteri e una regola a parte decidono quali client della LAN usano la VPN del router.
Il router raggiunge internet attraverso il suo tunnel, mentre un portatile dietro di esso riporta ancora l'indirizzo dell'ISP. Aggiungere regole di accettazione non serve, e questo fallimento è istruttivo: il filtraggio risponde se un pacchetto può passare, non dove va. La scelta dell'interfaccia è già stata fatta da una ricerca di routing che non sa nulla della tua lista di client. Correggi la ricerca e il firewall smette di essere il sospetto.
Una regola di filtro non può scegliere un'interfaccia
Il flusso dei pacchetti su un router Linux esegue prima la decisione di routing e poi l'hook di inoltro. Quando una regola corrisponde al dispositivo del tunnel in uscita, il kernel ha già deciso che il tunnel è la via d'uscita. Se la tabella principale preferisce ancora la rotta predefinita della WAN, il pacchetto è diretto all'ISP e la regola di accettazione appena scritta non lo vede mai. Questo unico fatto sull'ordine spiega perché una pagina di nuove regole del firewall non cambia nulla.
L'esempio seguente usa una LAN di 192.168.8.0/24 su br-lan, un dispositivo di tunnel tun0 e un set-top box a 192.168.8.23 che dovrebbe usare il tunnel.
Leggi la ricerca prima di modificare le regole
Chiedi al kernel di risolvere una rotta per conto di quel client. La risposta include il dispositivo in uscita e l'indirizzo sorgente che verrebbe scelto, ed è tutto ciò che serve per confermare la diagnosi. Se la risposta nomina il dispositivo della WAN, il pacchetto non ha mai avuto la possibilità di raggiungere la tua regola.
ip -4 route get 198.51.100.7 from 192.168.8.23
Ripeti la query per un client che dovrebbe restare sul percorso normale. Quando entrambe le risposte nominano lo stesso dispositivo, non c'è ancora alcun criterio per sorgente in gioco, e la correzione riguarda il routing e non il filtraggio.
Collega una tabella ai client che vuoi coprire
Il routing per criteri inserisce una ricerca di regole prima della tabella principale. Crea una tabella la cui rotta predefinita è il tunnel, poi collega quella tabella a un selettore: un'interfaccia di ingresso, un indirizzo sorgente o un marchio del firewall. Le priorità decidono l'ordine, e la tabella principale sta molto in basso nell'elenco, a 32766, quindi una regola con un numero basso viene consultata per prima. I selettori di interfaccia coprono ogni client del bridge; i selettori di indirizzo coprono una macchina.
ip -4 route add default dev tun0 table 200
ip -4 rule add iif br-lan lookup 200 priority 200
Le interfacce del firmware di solito espongono gli stessi oggetti di una pagina di routing per criteri o di criteri VPN. Un elenco di dispositivi lì è più facile da mantenere delle regole scritte a mano e di solito sopravvive agli aggiornamenti che cambiano la sintassi delle regole.
Scegli il selettore di proposito. Una regola di interfaccia è breve e duratura, ma cattura anche il traffico di gestione del router stesso che arriva su quel bridge. Una regola di sorgente è precisa e richiede una modifica ogni volta che cambia l'elenco dei dispositivi. Annota la scelta, perché la prossima persona che chiederà perché un dispositivo si comporta diversamente ne avrà bisogno.
Tieni le destinazioni locali fuori dal tunnel
Una tabella nuova conosce solo le rotte che ci metti. Manca il prefisso della LAN, quindi il traffico della stampante e del NAS seguirebbe la rotta predefinita del tunnel e sparirebbe. Una rotta throw termina la ricerca in questa tabella e restituisce la decisione alla tabella principale.
ip -4 route add throw 192.168.8.0/24 table 200
Salta quella rotta e le condivisioni locali si rompono, e la sessione di gestione del router stesso può sparire se il selettore è più ampio del previsto. Poi risolvi la questione della sorgente: i pacchetti del tunnel che portano ancora indirizzi della LAN hanno bisogno che l'altro lato conosca un percorso di ritorno, mentre il masquerading sul tunnel elimina questo requisito ed elimina anche l'identità del client che l'altro lato vedrebbe.
Le regole e le rotte aggiunte a runtime spariscono dopo un riavvio o un aggiornamento del firmware. Aggiungile al meccanismo di avvio del router, riavvia una volta e verifica di nuovo dal client: il suo indirizzo pubblico, un secondo client che dovrebbe restare sulla WAN e i contatori del tunnel durante una nuova connessione.