Para onde vai o DNS quando combina Tor e uma VPN

Estão em execução duas ferramentas de privacidade, uma página não carrega e um teste de resolução diz que algo fora do navegador recebeu um nome. Antes de isso se tornar um relatório de fuga, nomeie a troca de onde veio. Uma configuração de Tor mais VPN contém pelo menos três consultas de nomes diferentes com três responsáveis diferentes, e percorrê-las pela ordem em que acontecem é a forma mais rápida de ver qual está a comportar-se mal.

Nomeie cada troca antes de chamar isto de fuga

A primeira troca resolve o próprio ponto final da VPN, e acontece antes de existir qualquer proteção. A segunda resolve um destino para o navegador Tor, que pode entregar o nome ao proxy em vez de o resolver localmente. A terceira cobre tudo o resto na máquina, incluindo verificações de atualizações, clientes de correio e as consultas de serviço do próprio sistema operativo. Só a primeira pode ocorrer sem que as outras duas estejam envolvidas.

Cada uma pode seguir um caminho diferente, e um único teste no navegador observa apenas o seu próprio pedido. Tomar um resultado como o estado das três é onde começa a maior parte da confusão.

Anote que nomes pertencem a que camada antes de mudar alguma coisa. Nomes organizacionais privados, um destino público e o próprio ponto final do túnel não têm o mesmo requisito, e uma política que os trate como uma única categoria vai partir alguma coisa.

A consulta de arranque acontece antes do túnel

Um cliente configurado com um nome de anfitrião tem de resolver esse nome para abrir o túnel, e nesse momento não existe túnel que transporte a consulta. Responde qualquer resolvedor que o sistema operativo ofereça na rede atual, que pode ser um portal cativo, um resolvedor de hotel ou um público. Isso não é uma fuga no túnel, porque ainda não há túnel.

Alterar a definição de DNS seguro do navegador também não afeta esta consulta, já que pertence a um serviço que corre fora do navegador e começa antes de qualquer página ser aberta. Se o nome do ponto final não for resolvido, nenhuma política dentro do túnel ajudará, porque a falha ocorre uma etapa antes de tudo o que a configuração descreve.

Este é o único lugar onde usar um endereço literal para o ponto final, se o fornecedor o suportar, remove uma dependência em vez de acrescentar uma. Também remove a capacidade de seguir um fornecedor que roda endereços, pelo que a troca é real e deve ser decidida em vez de descoberta.

O navegador e o resto da máquina diferem

A interface SOCKS do Tor suporta passar um nome de anfitrião de destino ao proxy, o que significa que é o extremo remoto que faz a resolução e a máquina local nunca pergunta. Uma aplicação genérica que suporta um proxy pode resolver o nome localmente primeiro e depois ligar-se ao endereço obtido, o que produz uma consulta local para um destino que o utilizador julgava estar a passar pelo proxy. As duas aplicações podem, portanto, fugir em locais diferentes enquanto partilham uma única definição de proxy. Nada num endereço de proxy partilhado lhe diz qual dos dois comportamentos está a ser usado.

Os navegadores acrescentam outra camada quando o DNS seguro está ativado, porque o navegador pode escolher o seu próprio fornecedor e contornar completamente o resolvedor do sistema. O cliente do túnel, entretanto, pode empurrar um resolvedor pelo túnel para toda a máquina. Essas duas definições podem estar corretas ao mesmo tempo e ainda assim descrever comportamentos diferentes para programas diferentes.

Verifique o programa que fez o pedido em vez de extrapolar a partir de uma página de teste. A distinção entre uma consulta transportada dentro do túnel e uma que nunca chegou ao Tor é exatamente a distinção que um único endereço de resolvedor não consegue mostrar.

Verifique cada programa e depois compare com a intenção

Faça as observações separadamente: o que o sistema usaria, para que está o navegador configurado e se a ligação SOCKS transporta um nome ou um endereço. Este último é a diferença entre resolução remota e local, e especificação das extensões SOCKS descreve como um nome de anfitrião é passado em vez de ser resolvido primeiro.

resolvectl status | grep -E "Current DNS Server|DNS Servers"
ss -tnp '( dport = :9050 )'
dig +short dev.internal.example
getent hosts vpn-endpoint.example.net

Depois compare o que observou com o que pretendia. Um nome público resolvido pelo túnel por um resolvedor que escolheu não é a mesma conclusão que um nome privado entregue a um resolvedor público durante um recuo, e normalmente só o segundo exige ação. O primeiro é uma configuração a funcionar como foi concebida, mesmo que pareça invulgar num relatório.

Registe as exceções que aceita, incluindo a consulta de arranque que não pode ser protegida. Uma exceção escrita é uma decisão de conceção, enquanto a mesma exceção descoberta mais tarde parece um defeito. Quem a encontrar tratá-la-á como tal, e você passará a reunião a explicar porque não é.