Fitxer hosts contra filtre del router: bloquejar un lloc amb una VPN

Una entrada al fitxer hosts i un filtre del router bloquegen el mateix lloc per motius completament diferents, i per això un continua funcionant sota una VPN i l'altre s'atura en silenci. El fitxer hosts respon a un nom abans que cap paquet surti de la màquina. El filtre del router inspecciona el trànsit que el travessa. Posa un túnel entre aquests dos punts i el segon perd la vista mentre el primer no s'adona de res.

On es resol el nom ho decideix tot

Cada bloqueig comença amb una pregunta: qui converteix el nom en una adreça? En un ordinador de taula normal la resposta és el resoledor del sistema, que recorre el seu ordre configurat i normalment llegeix el fitxer hosts abans de consultar el DNS. En una xarxa filtrada la resposta pot ser el router, que només veu la consulta si el client l'envia a través seu sense protecció. Canvia el camí i canvies qui té permís per respondre.

Una VPN fa dues coses alhora aquí: mou la ruta per defecte i pot empènyer el seu propi servidor DNS. Qualsevol dels dos canvis n'hi ha prou per allunyar la resolució de noms del dispositiu que aplicava el bloqueig.

Aquest és el mecanisme darrere de la queixa habitual que el filtre funciona fins que la VPN es connecta.

Una entrada hosts respon abans que existeixi el túnel

Una línia com 127.0.0.1 www.example.com la llegeix el resoledor local, així que la resposta es produeix a la màquina sense que hi intervingui cap xarxa. Connecta un túnel, canvia el servidor DNS, canvia de xarxa: l'entrada encara retorna loopback. Per això un bloqueig hosts és l'únic dels dos que no depèn d'on acaba la VPN.

Els seus punts cecs són igualment locals. Una aplicació que porta el seu propi resoledor, parla DNS over HTTPS o es connecta a una adreça literal no pregunta mai al sistema, així que l'entrada no es consulta. Una adreça en memòria cau dins d'un procés en marxa té el mateix efecte fins que aquell procés es reinicia.

Confirma la resposta amb getent ahosts a Linux o Resolve-DnsName a Windows en lloc de confiar en una pestanya del navegador.

Un filtre del router només veu el que el travessa

Un filtre de contingut o URL en un router domèstic fa coincidir noms i peticions que el travessen en forma llegible. Quan el client construeix un túnel xifrat cap a un servidor en un altre lloc, el router veu un sol flux cap a aquell servidor i res a dins. El filtre no té cap nom per fer coincidir, així que permet el trànsit, i això sembla que el filtre ha fallat, no que l'han evitat.

La topologia que funciona és l'altra: el router té el túnel ell mateix, desxifra a l'extrem i hi aplica el filtre. En aquest disseny el filtre se situa on apareix el text pla.

Si el túnel acaba a l'ordinador portàtil, el router és fora del camí protegit per definició, tant se val com s'escriu la regla.

Quatre punts d'aplicació i què falla a cadascun

Quatre llocs poden aplicar un bloqueig, i cadascun falla de manera diferent. Llegeix la llista com un mapa de cobertura, no com un rànquing.

• Fitxer hosts o resoledor local: funciona sense connexió i sota qualsevol túnel, però l'evita un resoledor integrat o una adreça codificada a mà.
• Filtratge DNS a la passarel·la VPN: cobreix els clients que fan servir el resoledor empès i deixa fora els clients que sobreescriuen el DNS.
• Regles de sortida a la passarel·la per adreça o SNI: independents del DNS del client, però cegues per als noms que no pot llegir i per a les adreces que no ha après.
• Política de navegador o dispositiu gestionat: forta en maquinari gestionat, absent en dispositius personals.

Cap d'aquestes és una frontera de seguretat contra un usuari decidit en un dispositiu no gestionat. Són controls de política, i una descripció honesta diu quin trànsit cobreix cadascun de fet.

Tria la capa que encaixa amb la intenció: la comoditat domèstica pertany al dispositiu, i una regla organitzativa pertany a la passarel·la.

Prova tots dos estats abans de donar-lo per acabat

Executa les mateixes tres ordres amb la VPN connectada i desconnectada: getent ahosts per veure la resposta del resoledor, nslookup per veure què retorna la consulta i curl -I contra el lloc per veure si una connexió encara es completa. Si la primera retorna loopback mentre la tercera es connecta a l'adreça real, alguna cosa ha evitat el resoledor i l'entrada hosts no és el control que et penses.

Al router, llegeix els comptadors del filtre abans i després d'una petició. Un comptador que no es mou mai vol dir que el trànsit no va arribar mai al filtre, i això és una resposta d'encaminament, no de regla.

Anota el resultat juntament amb la topologia, perquè el proper canvi de VPN tornarà a moure el camí.