On va el DNS quan combines Tor i una VPN

Hi ha dues eines de privadesa en marxa, una pàgina no carrega i una prova de resolució diu que alguna cosa fora del navegador ha rebut un nom. Abans que això es converteixi en un informe de fuita, posa nom a l’intercanvi del qual prové. Una configuració de Tor més VPN conté com a mínim tres consultes de noms diferents amb tres responsables diferents, i recórrer-les en l’ordre en què es produeixen és la manera més ràpida de veure quina es comporta malament.

Posa nom a cada intercanvi abans de qualificar-lo de fuita

El primer intercanvi resol el propi punt de connexió de la VPN i es produeix abans que existeixi cap protecció. El segon resol una destinació per al navegador Tor, que pot lliurar el nom al servidor intermedi en lloc de resoldre’l localment. El tercer cobreix tota la resta de la màquina, incloent-hi les comprovacions d’actualitzacions, els clients de correu i les consultes de serveis del propi sistema operatiu. Només el primer pot ocórrer sense que hi intervinguin els altres dos.

Cadascun pot seguir una via diferent, i una única prova al navegador només observa la seva pròpia petició. Prendre un resultat com l’estat dels tres és on comença la major part de la confusió.

Anota quins noms pertanyen a cada capa abans de canviar res. Els noms organitzatius privats, una destinació pública i el propi punt de connexió del túnel no tenen el mateix requisit, i una política que els tracti com una sola categoria trencarà alguna cosa.

La consulta d’arrencada passa abans del túnel

Un client configurat amb un nom d’amfitrió ha de resoldre aquest nom per obrir el túnel, i en aquell moment no hi ha túnel que porti la consulta. La respon qualsevol resolutor que el sistema operatiu ofereixi a la xarxa actual, que pot ser un portal captiu, un resolutor d’hotel o un de públic. Això no és una fuita al túnel, perquè encara no hi ha túnel.

Canviar la configuració de DNS segur del navegador tampoc no afecta aquesta consulta, perquè pertany a un servei que s’executa fora del navegador i comença abans que s’obri cap pàgina. Si el nom del punt de connexió no es resol, cap política dins del túnel no ajudarà, perquè la fallada es produeix una etapa abans de tot el que descriu la configuració.

Aquest és l’únic lloc on fer servir una adreça literal per al punt de connexió, si el proveïdor ho admet, elimina una dependència en lloc d’afegir-ne una. També elimina la capacitat de seguir un proveïdor que rota adreces, així que l’intercanvi és real i cal decidir-lo en lloc de descobrir-lo.

El navegador i la resta de la màquina difereixen

La interfície SOCKS de Tor admet passar un nom d’amfitrió de destinació al servidor intermedi, cosa que significa que l’extrem remot fa la resolució i la màquina local no pregunta mai. Una aplicació genèrica que admet un servidor intermedi pot resoldre el nom localment primer i després connectar-se a l’adreça obtinguda, cosa que produeix una consulta local per a una destinació que l’usuari creia que passava pel servidor intermedi. Per tant, les dues aplicacions poden filtrar en llocs diferents mentre comparteixen una única configuració de servidor intermedi. Res en una adreça compartida no indica quin dels dos comportaments s’està fent servir.

Els navegadors afegeixen una altra capa quan el DNS segur està activat, perquè el navegador pot triar el seu propi proveïdor i saltar-se del tot el resolutor del sistema. El client del túnel, mentrestant, pot empènyer un resolutor pel túnel per a tota la màquina. Aquestes dues configuracions poden ser correctes alhora i descriure encara comportaments diferents per a programes diferents.

Comprova el programa que ha fet la petició en lloc d’extrapolar a partir d’una pàgina de prova. La distinció entre una consulta portada dins del túnel i una que no va arribar mai a Tor és exactament la distinció que una única adreça de resolutor no pot mostrar.

Comprova cada programa i després compara-ho amb la intenció

Fes les observacions per separat: què faria servir el sistema, per a què està configurat el navegador i si la connexió SOCKS porta un nom o una adreça. Aquesta darrera és la diferència entre resolució remota i local, i l’especificació d’extensions de SOCKS descriu com es passa un nom d’amfitrió en lloc de resoldre’l primer.

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

Després compara el que has observat amb el que pretenies. Un nom públic resolt pel túnel per un resolutor que has triat no és la mateixa troballa que un nom privat lliurat a un resolutor públic durant una baixada, i normalment només el segon requereix acció. El primer és una configuració que funciona com estava dissenyada, encara que sembli poc familiar en un informe.

Registra les excepcions que acceptes, incloent-hi la consulta d’arrencada que no es pot protegir. Una excepció escrita és una decisió de disseny, mentre que la mateixa excepció descoberta més tard sembla un defecte. Qui la trobi la tractarà com a tal, i passaràs la reunió explicant per què no ho és.