Arquivo hosts contra filtro do roteador: bloquear um site através de uma VPN

Uma entrada no arquivo hosts e um filtro do roteador bloqueiam o mesmo site por razões completamente diferentes, por isso um continua a funcionar sob uma VPN e o outro para em silêncio. O arquivo hosts responde a um nome antes de qualquer pacote sair da máquina. O filtro do roteador inspeciona o tráfego que o atravessa. Coloque um túnel entre esses dois pontos e o segundo perde a visão, enquanto o primeiro não percebe nada.

Onde o nome é resolvido decide tudo

Todo bloqueio começa com uma pergunta: quem transforma o nome em endereço? Num desktop comum a resposta vem do resolvedor do sistema, que segue a ordem configurada e normalmente lê o arquivo hosts antes de consultar o DNS. Numa rede filtrada a resposta pode vir do roteador, que só vê a consulta se o cliente a enviar através dele sem proteção. Mude o caminho e muda quem tem permissão para responder.

Uma VPN faz duas coisas ao mesmo tempo aqui: move a rota padrão e pode impor o seu próprio servidor DNS. Qualquer uma das duas mudanças basta para afastar a resolução de nomes do dispositivo que aplicava o bloqueio.

Esse é o mecanismo por trás da queixa comum de que o filtro funciona até a VPN se conectar.

Uma entrada hosts responde antes de o túnel existir

Uma linha como 127.0.0.1 www.example.com é lida pelo resolvedor local, então a resposta é produzida na máquina sem rede. Conecte um túnel, mude o servidor DNS, troque de rede: a entrada continua a devolver loopback. Por isso um bloqueio hosts é o único dos dois que não depende de onde a VPN termina.

Os seus pontos cegos são igualmente locais. Um aplicativo que traz o seu próprio resolvedor, fala DNS over HTTPS ou se liga a um endereço literal nunca pergunta ao sistema, então a entrada não é consultada. Um endereço em cache dentro de um processo em execução tem o mesmo efeito até esse processo reiniciar.

Confirme a resposta com getent ahosts no Linux ou Resolve-DnsName no Windows em vez de confiar numa aba do navegador.

Um filtro do roteador só vê o que o atravessa

Um filtro de conteúdo ou URL num roteador doméstico combina nomes e pedidos que o atravessam de forma legível. Quando o cliente constrói um túnel criptografado para um servidor noutro lugar, o roteador vê um único fluxo para esse servidor e nada dentro dele. O filtro não tem nome para combinar, então deixa o tráfego passar, e isso parece uma falha do filtro, não um desvio.

A topologia que funciona é a outra: o roteador segura o túnel ele mesmo, descriptografa na extremidade e aplica ali o filtro. Nesse desenho o filtro fica onde o texto simples aparece.

Se o túnel termina no portátil, o roteador está por definição fora do caminho protegido, não importa como a regra esteja escrita.

Quatro pontos de aplicação e o que cada um deixa passar

Quatro lugares podem aplicar um bloqueio, e cada um falha de forma diferente. Leia a lista como um mapa de cobertura, não como um ranking.

• Arquivo hosts ou resolvedor local: funciona offline e sob qualquer túnel, mas é contornado por um resolvedor embutido ou um endereço codificado.
• Filtragem DNS no gateway VPN: cobre os clientes que usam o resolvedor imposto e perde os clientes que sobrepõem o DNS.
• Regras de saída do gateway por endereço ou SNI: independentes do DNS do cliente, mas cegas aos nomes que não conseguem ler e aos endereços que não aprenderam.
• Política gerida de navegador ou dispositivo: forte em hardware gerido, ausente em dispositivos pessoais.

Nenhuma destas é uma fronteira de segurança contra um utilizador decidido num dispositivo não gerido. São controlos de política, e uma descrição honesta diz que tráfego cada uma cobre de facto.

Escolha a camada que corresponde à intenção: a conveniência doméstica pertence ao dispositivo, e uma regra organizacional pertence ao gateway.

Teste os dois estados antes de dar por concluído

Execute os mesmos três comandos com a VPN ligada e desligada: getent ahosts para ver a resposta do resolvedor, nslookup para ver o que a consulta devolve e curl -I contra o site para ver se uma ligação ainda se completa. Se o primeiro devolve loopback enquanto o terceiro se liga ao endereço real, algo contornou o resolvedor e a entrada hosts não é o controlo que pensa.

No roteador, leia os contadores do filtro antes e depois de um pedido. Um contador que nunca se move significa que o tráfego nunca chegou ao filtro, e isso é uma resposta de encaminhamento, não de regra.

Anote o resultado junto com a topologia, porque a próxima mudança de VPN vai mover o caminho outra vez.