Archivo hosts frente a filtro del router: bloquear un sitio con una VPN

Una entrada en el archivo hosts y un filtro del router bloquean el mismo sitio por razones completamente distintas, y por eso uno sigue funcionando bajo una VPN mientras el otro se detiene sin hacer ruido. El archivo hosts responde a un nombre antes de que ningún paquete salga de la máquina. El filtro del router inspecciona el tráfico que lo atraviesa. Pon un túnel entre esos dos puntos y el segundo pierde su vista mientras el primero no nota nada.

Dónde se resuelve el nombre lo decide todo

Todo bloqueo empieza con una pregunta: ¿quién convierte el nombre en una dirección? En un escritorio normal la respuesta es el resolutor del sistema, que recorre su orden configurado y normalmente lee el archivo hosts antes de consultar el DNS. En una red filtrada la respuesta puede ser el router, que solo ve la consulta si el cliente la envía a través de él sin protección. Cambia la ruta y cambias quién tiene permiso para responder.

Una VPN hace dos cosas a la vez aquí: mueve la ruta predeterminada y puede empujar su propio servidor DNS. Cualquiera de los dos cambios basta para alejar la resolución de nombres del dispositivo que aplicaba el bloqueo.

Ese es el mecanismo que hay detrás de la queja habitual de que el filtro funciona hasta que se conecta la VPN.

Una entrada hosts responde antes de que exista el túnel

Una línea como 127.0.0.1 www.example.com la lee el resolutor local, así que la respuesta se produce en la máquina sin que intervenga ninguna red. Conecta un túnel, cambia el servidor DNS, cambia de red: la entrada sigue devolviendo loopback. Por eso un bloqueo hosts es el único de los dos que no depende de dónde termina la VPN.

Sus puntos ciegos son igual de locales. Una aplicación que lleva su propio resolutor, habla DNS over HTTPS o se conecta a una dirección literal nunca pregunta al sistema, así que la entrada no se consulta. Una dirección en caché dentro de un proceso en marcha tiene el mismo efecto hasta que ese proceso se reinicia.

Confirma la respuesta con getent ahosts en Linux o Resolve-DnsName en Windows en lugar de fiarte de una pestaña del navegador.

Un filtro del router solo ve lo que lo atraviesa

Un filtro de contenido o URL en un router doméstico hace coincidir nombres y peticiones que lo atraviesan en forma legible. Cuando el cliente construye un túnel cifrado hacia un servidor en otro lugar, el router ve un único flujo hacia ese servidor y nada dentro. El filtro no tiene ningún nombre con el que coincidir, así que permite el tráfico, y eso parece que el filtro ha fallado, no que lo han evitado.

La topología que funciona es la otra: el router sostiene el túnel él mismo, descifra en el extremo y aplica allí el filtro. En ese diseño el filtro se sienta donde aparece el texto claro.

Si el túnel termina en el portátil, el router está fuera del camino protegido por definición, sin importar cómo esté escrita la regla.

Cuatro puntos de aplicación y qué falla en cada uno

Cuatro lugares pueden aplicar un bloqueo, y cada uno falla de forma distinta. Lee la lista como un mapa de cobertura, no como una clasificación.

• Archivo hosts o resolutor local: funciona sin conexión y bajo cualquier túnel, pero lo evita un resolutor integrado o una dirección escrita a mano.
• Filtrado DNS en la puerta de enlace VPN: cubre a los clientes que usan el resolutor empujado y pierde a los clientes que sobrescriben el DNS.
• Reglas de salida en la puerta de enlace por dirección o SNI: independientes del DNS del cliente, pero ciegas a los nombres que no puede leer y a las direcciones que no ha aprendido.
• Política gestionada de navegador o dispositivo: fuerte en hardware gestionado, ausente en dispositivos personales.

Ninguna de estas es una frontera de seguridad contra un usuario decidido en un dispositivo no gestionado. Son controles de política, y una descripción honesta dice qué tráfico cubre realmente cada una.

Elige la capa que encaja con la intención: la comodidad doméstica pertenece al dispositivo, y una regla organizativa pertenece a la puerta de enlace.

Prueba los dos estados antes de darlo por terminado

Ejecuta los mismos tres comandos con la VPN conectada y desconectada: getent ahosts para ver la respuesta del resolutor, nslookup para ver qué devuelve la consulta y curl -I contra el sitio para ver si una conexión aún se completa. Si el primero devuelve loopback mientras el tercero se conecta a la dirección real, algo ha evitado el resolutor y la entrada hosts no es el control que crees.

En el router, lee los contadores del filtro antes y después de una petición. Un contador que nunca se mueve significa que el tráfico nunca llegó al filtro, y eso es una respuesta de enrutamiento, no de regla.

Anota el resultado junto con la topología, porque el próximo cambio de VPN volverá a mover la ruta.