Perché il DNS del router aggira il tunnel VPN?

Le query dei client seguono il tunnel, mentre le query del router stesso escono dalla WAN, e la regola del firewall che governa una non ha alcun effetto sull’altra. Il motivo non è un bug: una richiesta inoltrata e una richiesta che il router genera da sé sono due flussi separati, e ciascuno viene confrontato con una parte diversa della configurazione. Catturare solo la metà client produce una risposta sicura su un percorso che la seconda metà non usa mai. La correzione consiste nel puntare deliberatamente il resolver del router e poi testare i due percorsi separatamente.

A quale flusso appartiene davvero la cattura dei pacchetti

Una query comporta due scambi. Un client della LAN invia una query al resolver del router, e questa arriva come traffico inoltrato sull’interfaccia LAN, quindi una rotta di policy o una regola NAT scritta per i pacchetti inoltrati può trovare corrispondenza. Poi il router risponde dalla cache o, in caso di mancanza, apre la propria query verso un server upstream.

Quella seconda query ha il router come origine e come propria destinazione, e la piattaforma ne sceglie il percorso in un blocco di configurazione diverso. Entrambi gli scambi portano lo stesso nome, e nessuno è una copia dell’altro. Una cattura presa sul lato LAN dimostra quindi dove è andato il pacchetto del client e non dice nulla sul pacchetto in uscita.

La verifica pratica consiste nell’osservare entrambi i lati contemporaneamente. Sul router, elenca il socket del resolver, interrogalo localmente e cattura l’interfaccia WAN:

sockstat -4 -l | grep :53
dig +short @127.0.0.1 example.com
tcpdump -ni igb0 udp port 53

Se l’elenco dei socket mostra un listener legato all’indirizzo di loopback o della LAN, il router risponde localmente invece di inoltrare a un altro host. La cattura mostra allora se la query upstream risultante esce dall’interfaccia del tunnel o dalla WAN, ed è la risposta che la regola di rotta di policy non avrebbe mai dato.

Perché la rotta di policy non vede mai la seconda query

Le regole del firewall vengono scritte per un’interfaccia, una sorgente, una destinazione e una porta, e vengono valutate per i pacchetti che attraversano l’apparecchio. Una query che il router origina non attraversa nulla, perché un processo locale la consegna direttamente alla tabella di routing. Routing di policy e NAT valgono quindi solo per il percorso inoltrato, ed è per questo che un insieme di regole può sembrare completo e lasciare comunque il DNS del router fuori dal tunnel.

La distinzione sopravvive a ogni riscrittura del firmware perché deriva dal percorso del pacchetto e non da una funzione. Tutto ciò che l’apparecchio genera per sé, siano query del resolver, sincronizzazione dell’ora, controlli degli aggiornamenti o accesso agli specchi dei pacchetti, è di origine locale e finisce nello stesso punto cieco. È anche per questo che un test eseguito da un portatile non dimostra nulla sul router.

Dove il resolver di pfSense decide il proprio percorso upstream

pfSense rende visibile la separazione. Il traffico dei client può essere instradato per policy attraverso un gateway VPN mentre il traffico del firewall segue l’impostazione in uscita del resolver invece delle regole LAN. Nell’interfaccia web quell’impostazione si trova sotto Services > DNS Resolver > Outgoing Network Interfaces, e il suo valore è l’elenco delle interfacce che il resolver può usare per le query upstream.

Nominare lì l’interfaccia del tunnel, e solo quella, è ciò che fa seguire il tunnel alle query del router stesso. Lasciato il valore predefinito, il resolver sceglie un’uscita dalla tabella di routing, che su un host con doppia WAN o VPN è spesso la WAN.

Altri firmware espongono la stessa decisione con un’etichetta diversa: un elenco di server upstream legato a un indirizzo sorgente, una modalità di solo inoltro o una politica di rotte documentata. L’impostazione da cercare è sempre quella che sceglie un’uscita o una sorgente per le query generate localmente. Il riferimento di configurazione del resolver documenta quell’opzione per pfSense e vale la pena leggerlo prima della modifica.

Scegli il comportamento in caso di guasto prima dell’impostazione

Quando il tunnel cade, due comportamenti sono difendibili: fermare le query upstream perché nulla fuoriesca, oppure ripiegare su un resolver approvato su un percorso noto. Entrambi sono politiche, e nessuno è ciò che si ottiene per impostazione predefinita. Decidi quale serve alla rete prima di toccare l’elenco delle interfacce.

La chiusura in caso di guasto è più facile da difendere, ma trasforma un’interruzione del tunnel in un’interruzione della risoluzione dei nomi per ogni dispositivo dietro il router. Il ripiego mantiene l’ufficio utilizzabile, al costo di uno scambio upstream fuori dal tunnel che deve essere accettabile di proposito e non per caso. Scrivi la scelta, perché la prossima persona che vedrà un indirizzo di resolver fuori dalla VPN lo leggerà come una fuga, a meno che una nota non dica il contrario. È quella nota a separare un ripiego documentato da un riscontro inspiegato nella revisione del trimestre successivo.

Due casi complicano la decisione. I nomi privati possono richiedere un resolver interno che il tunnel raggiunge, e un browser o un’applicazione con un proprio DNS cifrato può aggirare del tutto il router, quindi il resolver configurato non è sempre quello usato da una data applicazione.

Verifica entrambi i percorsi e tieni separati i risultati

Un test DNS nel browser risponde a una domanda ristretta: quali resolver ha usato quel browser, nelle condizioni di quel test. Non inventaria i dispositivi della rete e non può vedere una query che il router ha generato per sé. Tratta il suo output come un punto dati e non come un audit.

Da un client della LAN, chiedi al router un nome pubblico e poi un nome privato a cui solo la tua zona interna dovrebbe rispondere. Un errore solo sulla seconda query indica un inoltro dei nomi e non il tunnel:

dig @192.168.1.1 example.com
dig @192.168.1.1 intranet.example.lan

Poi abbatti il tunnel e ripeti entrambe le query. Risposte rifiutate significano che il resolver chiude in caso di guasto; una risposta riuscita indica un resolver di ripiego e il percorso usato. Confronta ciò con la nota che hai scritto e con una cattura sull’interfaccia WAN presa nello stesso minuto.

Tieni separate le osservazioni nel registro: lo scambio tra client e router, lo scambio tra router e upstream e la configurazione che ha deciso il secondo. Un successivo cambio di routing eserciterà quel secondo scambio senza avviso. Una risposta che arriva da un luogo diverso dall’endpoint VPN non è di per sé una fuga; diventa una fuga solo quando la configurazione ha scelto quel percorso per caso.