Hai creato una rete per gli ospiti, hai aggiunto una rotta, e gli ospiti escono ancora dalla tua normale connessione a internet. Il tunnel è attivo, la LAN principale funziona, e i dispositivi degli ospiti riportano un indirizzo nell'intervallo che hai assegnato, quindi nulla sembra rotto. Quello che di solito manca non è una rotta ma un selettore: il router decide il percorso prima di considerare su quale interfaccia è arrivato il pacchetto, e a meno che qualcosa non corrisponda esplicitamente al traffico degli ospiti, quel traffico eredita il valore predefinito. La correzione è un segmento, una regola di policy e un percorso di ritorno, in quest'ordine.

Il sintomo: gli ospiti escono ancora dalla WAN

L'indizio è l'indirizzo di uscita. Un dispositivo ospite che raggiunge internet attraverso il tunnel riporterà l'indirizzo del fornitore del tunnel, e uno che ha ereditato il valore predefinito riporterà la tua connessione normale. Confronta affiancati un dispositivo ospite e un dispositivo della LAN principale, perché il caso interessante è quando differiscono da ciò che hai configurato e coincidono tra loro.

Il secondo indizio è l'assenza di traffico sull'interfaccia del tunnel mentre gli ospiti navigano. Se i contatori non si muovono, la policy non è mai stata applicata, e regolare il tunnel stesso non può aiutare.

Passo 1: un segmento reale, non solo un nome

Un nome SSID non crea isolamento. Verifica che la rete ospiti termini sulla propria interfaccia, VLAN o bridge, e che l'intervallo di indirizzi sia distinto dalla LAN affidabile. Su molti access point consumer, l'SSID ospiti viene collegato in bridge nello stesso segmento di tutto il resto, il che rende impossibile il resto di questo lavoro finché non viene corretto.

Poi conferma l'intervallo ospiti e il suo server DHCP, e mantieni le impostazioni del resolver associate a quel segmento invece che all'intero router. Una sottorete ospiti che esiste solo come commento in una regola del firewall non è un segmento, e il router non avrà alcuna interfaccia con cui corrispondere.

Non collegare gli ospiti in bridge nella LAN principale per rendere più facile configurare la VPN. Questo scambia l'isolamento che volevi con una scorciatoia di routing, ed è la ragione abituale per cui una rete ospiti finisce con l'accesso alla stampante e al NAS.

Passo 2: seleziona il tunnel per origine

Le tabelle di routing vengono scelte per destinazione, quindi una regola che dice «invia 0.0.0.0/0 al tunnel» vale per tutti. Il routing policy aggiunge una seconda dimensione: selezionare la tabella per indirizzo di origine. Su un router basato su Linux, questa è una regola aggiuntiva più una tabella dedicata, e l'ordine conta perché vince la prima regola corrispondente:

ip rule add from 192.168.60.0/24 lookup 100 priority 1000
ip route add default dev wg0 table 100
ip route get 1.1.1.1 from 192.168.60.10

Quest'ultimo comando risponde direttamente alla domanda: quale interfaccia userà questa origine per questa destinazione. Eseguilo prima e dopo la modifica e saprai se la policy ha avuto effetto senza toccare un browser.

La maggior parte dei firmware dei router esprime la stessa cosa come regola di interfaccia o selezione del gateway basata sull'origine. Qualunque sia la sintassi usata dalla tua piattaforma, il principio è identico: corrispondi all'interfaccia di ingresso o al prefisso di origine, poi sovrascrivi la rotta solo per quella corrispondenza. Una regola che corrisponde per destinazione non può distinguere un ospite da un dispositivo domestico.

Passo 3: il percorso di ritorno e la traduzione

Un pacchetto che esce dal tunnel deve tornare. O il peer del tunnel conosce una rotta di ritorno al prefisso ospiti, oppure il router traduce l'origine ospiti nell'indirizzo del tunnel. Scegline una e annotala, perché le modalità di guasto appaiono diverse: una rotta di ritorno mancante dà una connessione che si stabilisce e non risponde mai, mentre una traduzione mancante spesso non produce nulla.

nft add rule ip nat POSTROUTING ip saddr 192.168.60.0/24 oifname "wg0" masquerade

Se scegli la traduzione, ricorda che il peer ora vede un solo indirizzo per ogni ospite, quindi qualsiasi policy per client all'estremità remota scompare. Se invece conservi gli indirizzi, entrambe le estremità hanno bisogno del prefisso ospiti nel proprio routing e nella propria policy, il che è più lavoro e più prevedibile.

IPv6 ha bisogno della propria regola. Una policy scritta per IPv4 non copre l'altra famiglia, e un dispositivo ospite con IPv6 funzionante la userà volentieri mentre il tuo percorso IPv4 accuratamente instradato resta inattivo. Instrada entrambe le famiglie o disabilita IPv6 sul segmento ospiti, ma non presumere che la regola combinata che hai scritto copra ciò che il dispositivo fa davvero. Prova con un client che ha entrambe le famiglie abilitate, perché è il caso che il progetto deve superare. Un portatile che preferisce IPv6 sembra corretto in un test solo IPv4 e perde in quello reale.

Prova l'isolamento, non solo la navigazione

Navigare dimostra che l'uscita è cambiata. Non dimostra che il segmento sia isolato, e l'isolamento è la ragione per cui esiste la rete ospiti. Da un dispositivo ospite, prova a raggiungere l'interfaccia di amministrazione del router, un host della LAN affidabile e un servizio che dovrebbe essere rifiutato; tutti e tre dovrebbero fallire, e il fallimento dovrebbe essere una decisione di policy invece di un timeout che nessuno può spiegare.

Poi prova un dispositivo della LAN principale e conferma che la sua uscita non è cambiata. È la regressione che questo progetto causa più spesso: una regola ampia pensata per gli ospiti, applicata a ogni interfaccia perché la corrispondenza era scritta sulla destinazione.

Infine, decidi cosa succede quando il tunnel è inattivo. Gli ospiti o non hanno internet o passano a un percorso che approvi, e lasciarlo indeciso significa un ritorno silenzioso alla connessione normale, che è esattamente la fuga che la policy ospiti doveva prevenire. La ricetta per l'instradamento del traffico internet percorre la stessa selezione del percorso per un router basato su pfSense.

Il DNS originato dal router è il caso che sorprende le persone per ultimo. Se gli ospiti usano il router come resolver, le query del router stesso seguono la rotta del router invece della regola ospiti, quindi le ricerche possono uscire dalla connessione normale mentre il traffico applicativo no. Tieni il segmento, il resolver e la policy di guasto in un'unica nota, e la persona successiva potrà controllare tutti e tre senza ridurre di nuovo il progetto.

Articoli correlati