Ficheiro hosts fronte a filtro do router: bloquear un sitio cunha VPN

Unha entrada no ficheiro hosts e un filtro do router bloquean o mesmo sitio por razóns completamente distintas, e por iso un segue funcionando baixo unha VPN e o outro detense en silencio. O ficheiro hosts responde a un nome antes de que ningún paquete saia da máquina. O filtro do router inspecciona o tráfico que o atravesa. Pon un túnel entre eses dous puntos e o segundo perde a súa vista mentres o primeiro non nota nada.

Onde se resolve o nome decídeo todo

Todo bloqueo comeza cunha pregunta: quen converte o nome nun enderezo? Nun escritorio normal a resposta é o resolutor do sistema, que percorre a súa orde configurada e normalmente le o ficheiro hosts antes de consultar o DNS. Nunha rede filtrada a resposta pode ser o router, que só ve a consulta se o cliente a envía a través del sen protección. Cambia a ruta e cambias quen ten permiso para responder.

Unha VPN fai dúas cousas á vez aquí: move a ruta predeterminada e pode empuxar o seu propio servidor DNS. Calquera dos dous cambios abonda para afastar a resolución de nomes do dispositivo que aplicaba o bloqueo.

Ese é o mecanismo detrás da queixa habitual de que o filtro funciona ata que se conecta a VPN.

Unha entrada hosts responde antes de que exista o túnel

Unha liña como 127.0.0.1 www.example.com léaa o resolutor local, así que a resposta prodúcese na máquina sen que interveña ningunha rede. Conecta un túnel, cambia o servidor DNS, cambia de rede: a entrada segue devolvendo loopback. Por iso un bloqueo hosts é o único dos dous que non depende de onde remata a VPN.

Os seus puntos cegos son igual de locais. Unha aplicación que leva o seu propio resolutor, fala DNS over HTTPS ou se conecta a un enderezo literal nunca pregunta ao sistema, así que a entrada non se consulta. Un enderezo na caché dentro dun proceso en marcha ten o mesmo efecto ata que ese proceso se reinicia.

Confirma a resposta con getent ahosts en Linux ou Resolve-DnsName en Windows en lugar de confiar nunha pestana do navegador.

Un filtro do router só ve o que o atravesa

Un filtro de contido ou URL nun router doméstico fai coincidir nomes e peticións que o atravesan en forma lexible. Cando o cliente constrúe un túnel cifrado cara a un servidor noutro lugar, o router ve un único fluxo cara a ese servidor e nada dentro. O filtro non ten ningún nome co que coincidir, así que permite o tráfico, e iso parece que o filtro fallou, non que o evitaron.

A topoloxía que funciona é a outra: o router sostén o túnel el mesmo, descifra no extremo e aplica alí o filtro. Nese deseño o filtro séntase onde aparece o texto claro.

Se o túnel remata no portátil, o router está fóra do camiño protexido por definición, non importa como estea escrita a regra.

Catro puntos de aplicación e que falla en cada un

Catro lugares poden aplicar un bloqueo, e cada un falla de forma distinta. Le a lista como un mapa de cobertura, non como unha clasificación.

• Ficheiro hosts ou resolutor local: funciona sen conexión e baixo calquera túnel, pero evítao un resolutor integrado ou un enderezo codificado a man.
• Filtrado DNS na porta de enlace VPN: cobre os clientes que usan o resolutor empuxado e perde os clientes que sobrescriben o DNS.
• Regras de saída na porta de enlace por enderezo ou SNI: independentes do DNS do cliente, pero cegas aos nomes que non pode ler e aos enderezos que non aprendeu.
• Política xestionada de navegador ou dispositivo: forte en hardware xestionado, ausente en dispositivos persoais.

Ningunha destas é unha fronteira de seguridade contra un usuario decidido nun dispositivo non xestionado. Son controis de política, e unha descrición honesta di que tráfico cobre realmente cada unha.

Escolle a capa que encaixa coa intención: a comodidade doméstica pertence ao dispositivo, e unha regra organizativa pertence á porta de enlace.

Proba os dous estados antes de dalo por rematado

Executa os mesmos tres comandos coa VPN conectada e desconectada: getent ahosts para ver a resposta do resolutor, nslookup para ver que devolve a consulta e curl -I contra o sitio para ver se unha conexión aínda se completa. Se o primeiro devolve loopback mentres o terceiro se conecta ao enderezo real, algo evitou o resolutor e a entrada hosts non é o control que pensas.

No router, le os contadores do filtro antes e despois dunha petición. Un contador que nunca se move significa que o tráfico nunca chegou ao filtro, e iso é unha resposta de encamiñamento, non de regra.

Anota o resultado xunto coa topoloxía, porque o próximo cambio de VPN volverá mover o camiño.