Onde vai o DNS cando combinas Tor e unha VPN

Hai dúas ferramentas de privacidade en marcha, unha páxina non carga e unha proba de resolución di que algo fóra do navegador recibiu un nome. Antes de que iso se converta nun informe de fuga, nomea o intercambio do que provén. Unha configuración de Tor máis VPN contén polo menos tres consultas de nomes distintas con tres responsables distintos, e percorrelas na orde en que ocorren é a forma máis rápida de ver cal se está a comportar mal.

Nomea cada intercambio antes de chamalo fuga

O primeiro intercambio resolve o propio extremo da VPN e ocorre antes de que exista protección algunha. O segundo resolve un destino para o navegador Tor, que pode entregar o nome ao proxy en lugar de resolvelo localmente. O terceiro cobre todo o demais na máquina, incluídas as comprobacións de actualizacións, os clientes de correo e as consultas de servizo do propio sistema operativo. Só o primeiro pode ocorrer sen que participen os outros dous.

Cada un pode seguir unha ruta distinta, e unha única proba no navegador só observa a súa propia solicitude. Tomar un resultado como o estado dos tres é onde comeza a maior parte da confusión.

Anota que nomes pertencen a que capa antes de cambiar nada. Os nomes organizativos privados, un destino público e o propio extremo do túnel non teñen o mesmo requisito, e unha política que os trate como unha soa categoría romperá algo.

A consulta de arranque ocorre antes do túnel

Un cliente configurado cun nome de host ten que resolver ese nome para abrir o túnel, e nese momento non existe ningún túnel que leve a consulta. Responde calquera resolutor que o sistema operativo ofreza na rede actual, que pode ser un portal cativo, un resolutor de hotel ou un público. Iso non é unha fuga no túnel, porque aínda non hai túnel.

Cambiar o axuste de DNS seguro do navegador tampouco afecta esta consulta, xa que pertence a un servizo que se executa fóra do navegador e arrinca antes de que se abra calquera páxina. Se o nome do extremo non se resolve, ningunha política dentro do túnel axudará, porque o fallo ocorre unha etapa antes de todo o que describe a configuración.

Este é o único lugar onde usar un enderezo literal para o extremo, se o provedor o admite, elimina unha dependencia en lugar de engadir unha. Tamén elimina a capacidade de seguir un provedor que rota enderezos, así que o intercambio é real e debería decidirse en lugar de descubrirse.

O navegador e o resto da máquina difiren

A interface SOCKS de Tor admite pasar un nome de host de destino ao proxy, o que significa que o extremo remoto realiza a resolución e a máquina local nunca pregunta. Unha aplicación xenérica que admite un proxy pode resolver o nome localmente primeiro e despois conectarse ao enderezo obtido, o que produce unha consulta local para un destino que o usuario cría proxiado. Por tanto, as dúas aplicacións poden filtrar en lugares distintos mentres comparten un único axuste de proxy. Nada nun enderezo de proxy compartido lle di cal dos dous comportamentos está en uso.

Os navegadores engaden outra capa cando o DNS seguro está activado, porque o navegador pode elixir o seu propio provedor e saltar por completo o resolutor do sistema. O cliente do túnel, mentres tanto, pode empuxar un resolutor polo túnel para toda a máquina. Eses dous axustes poden ser correctos á vez e describir aínda así comportamentos distintos para programas distintos.

Comproba o programa que fixo a solicitude en lugar de extrapolar desde unha páxina de proba. A distinción entre unha consulta levada dentro do túnel e unha que nunca chegou a Tor é exactamente a distinción que un único enderezo de resolutor non pode mostrar.

Comproba cada programa e despois compárao coa intención

Realiza as observacións por separado: que usaría o sistema, para que está configurado o navegador e se a conexión SOCKS leva un nome ou un enderezo. Este último é a diferenza entre resolución remota e local, e especificación de extensións de SOCKS describe como se pasa un nome de host en lugar de resolvelo 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

Despois compara o observado co que pretendías. Un nome público resolto a través do túnel por un resolutor que escolliches non é o mesmo achado que un nome privado entregado a un resolutor público durante unha caída, e normalmente só o segundo require acción. O primeiro é unha configuración que funciona segundo o deseño, aínda que pareza pouco familiar nun informe.

Rexistra as excepcións que aceptas, incluída a consulta de arranque que non se pode protexer. Unha excepción escrita é unha decisión de deseño, mentres que a mesma excepción descuberta máis tarde parece un defecto. Quen a atope trataráa como tal, e pasarás a reunión explicando por que non o é.