File hosts contro filtro del router: bloccare un sito tramite una VPN

Una voce nel file hosts e un filtro del router bloccano lo stesso sito per motivi completamente diversi, per questo uno continua a funzionare sotto una VPN e l'altro si ferma in silenzio. Il file hosts risponde a un nome prima che qualsiasi pacchetto lasci la macchina. Il filtro del router ispeziona il traffico che lo attraversa. Metti un tunnel tra quei due punti e il secondo perde la sua visuale, mentre il primo non nota nulla.

Dove viene risolto il nome decide tutto

Ogni blocco comincia con una domanda: chi trasforma il nome in un indirizzo? Su un normale desktop la risposta è il resolver di sistema, che segue l'ordine configurato e di solito legge il file hosts prima di interrogare il DNS. Su una rete filtrata la risposta può essere il router, che vede la query solo se il client la invia attraverso di esso senza protezione. Cambia il percorso e cambi chi ha il permesso di rispondere.

Una VPN fa due cose insieme qui: sposta la rotta predefinita e può imporre il proprio server DNS. Ciascuno dei due cambiamenti basta a spostare la risoluzione dei nomi lontano dal dispositivo che applicava il blocco.

È questo il meccanismo dietro la solita lamentela che il filtro funziona finché la VPN non si connette.

Una voce hosts risponde prima che esista il tunnel

Una riga come 127.0.0.1 www.example.com viene letta dal resolver locale, quindi la risposta viene prodotta sulla macchina senza rete. Connetti un tunnel, cambia il server DNS, cambia rete: la voce restituisce ancora loopback. Per questo un blocco hosts è l'unico dei due che non risente di dove termina la VPN.

I suoi punti ciechi sono altrettanto locali. Un'applicazione che porta il proprio resolver, parla DNS over HTTPS o si connette a un indirizzo letterale non chiede mai al sistema, quindi la voce non viene consultata. Un indirizzo in cache dentro un processo in esecuzione ha lo stesso effetto finché quel processo non si riavvia.

Conferma la risposta con getent ahosts su Linux o Resolve-DnsName su Windows invece di fidarti di una scheda del browser.

Un filtro del router vede solo ciò che lo attraversa

Un filtro di contenuti o URL su un router domestico abbina nomi e richieste che lo attraversano in forma leggibile. Quando il client costruisce un tunnel cifrato verso un server altrove, il router vede un solo flusso verso quel server e nulla al suo interno. Il filtro non ha alcun nome da abbinare, quindi lascia passare il traffico, e questo sembra un fallimento del filtro, non un aggiramento.

La topologia che funziona è l'altra: il router tiene il tunnel stesso, decifra all'estremità e applica lì il filtro. In quel progetto il filtro si trova dove appare il testo in chiaro.

Se il tunnel termina sul portatile, il router è per definizione fuori dal percorso protetto, non importa come sia scritta la regola.

Quattro punti di applicazione e cosa manca a ciascuno

Quattro luoghi possono applicare un blocco, e ciascuno fallisce in modo diverso. Leggi l'elenco come una mappa di copertura, non come una classifica.

• File hosts o resolver locale: funziona offline e sotto qualsiasi tunnel, ma viene aggirato da un resolver integrato o da un indirizzo scritto a mano.
• Filtraggio DNS sul gateway VPN: copre i client che usano il resolver imposto e manca i client che sovrascrivono il DNS.
• Regole di uscita del gateway per indirizzo o SNI: indipendenti dal DNS del client, ma cieche ai nomi che non riescono a leggere e agli indirizzi che non hanno imparato.
• Criterio gestito di browser o dispositivo: forte su hardware gestito, assente sui dispositivi personali.

Nessuna di queste è un confine di sicurezza contro un utente determinato su un dispositivo non gestito. Sono controlli di criterio, e una descrizione onesta dice quale traffico ciascuno copre davvero.

Scegli il livello che corrisponde all'intento: la comodità domestica appartiene al dispositivo, e una regola organizzativa appartiene al gateway.

Prova entrambi gli stati prima di dichiararlo finito

Esegui gli stessi tre comandi con la VPN connessa e disconnessa: getent ahosts per vedere la risposta del resolver, nslookup per vedere cosa restituisce la query e curl -I verso il sito per vedere se una connessione si completa ancora. Se il primo restituisce loopback mentre il terzo si connette all'indirizzo reale, qualcosa ha aggirato il resolver e la voce hosts non è il controllo che pensi.

Sul router, leggi i contatori del filtro prima e dopo una richiesta. Un contatore che non si muove mai significa che il traffico non ha mai raggiunto il filtro, e questa è una risposta di instradamento, non di regola.

Annota il risultato insieme alla topologia, perché il prossimo cambio di VPN sposterà di nuovo il percorso.