Waar DNS naartoe gaat als je Tor en een VPN combineert

Er draaien twee privacytools, één pagina laadt niet en een resolver-test zegt dat iets buiten de browser een naam heeft ontvangen. Voordat dat een lekrapport wordt, benoem de uitwisseling waar het vandaan kwam. Een Tor-plus-VPN-opstelling bevat minstens drie verschillende naamopvragingen met drie verschillende eigenaren, en ze doorlopen in de volgorde waarin ze gebeuren is de snelste manier om te zien welke zich misdraagt.

Benoem elke uitwisseling voordat je het een lek noemt

De eerste uitwisseling lost het VPN-eindpunt zelf op, en die gebeurt voordat er enige bescherming bestaat. De tweede lost een bestemming op voor de Tor Browser, die de naam aan de proxy kan geven in plaats van hem lokaal op te lossen. De derde dekt al het andere op de machine, inclusief updatecontroles, mailclients en de eigen service-aanvragen van het besturingssysteem. Alleen de eerste kan gebeuren zonder dat de andere twee betrokken zijn.

Elk daarvan kan een ander pad volgen, en één browsertest observeert alleen zijn eigen verzoek. Eén resultaat als de toestand van alle drie behandelen is waar de meeste verwarring begint.

Schrijf op welke namen bij welke laag horen voordat je iets verandert. Privé-organisatienamen, een openbare bestemming en het tunneleindpunt zelf hebben niet dezelfde eis, en een beleid dat ze als één categorie behandelt, zal iets breken.

De bootstrap-aanvraag gebeurt vóór de tunnel

Een client die met een hostnaam is geconfigureerd, moet die naam oplossen om de tunnel te openen, en op dat moment bestaat er geen tunnel om de aanvraag te dragen. Welke resolver het besturingssysteem op het huidige netwerk ook biedt, die antwoordt, en dat kan een captive portal, een hotelresolver of een openbare zijn. Dat is geen lek in de tunnel, want er is nog geen tunnel.

Het wijzigen van de beveiligde DNS-instelling van de browser raakt deze aanvraag ook niet, omdat die bij een dienst hoort die buiten de browser draait en begint voordat er enige pagina wordt geopend. Als de naam van het eindpunt niet wordt opgelost, helpt geen enkel beleid in de tunnel, omdat de fout een fase eerder optreedt dan alles wat de configuratie beschrijft.

Dit is de enige plek waar het gebruik van een letterlijk adres voor het eindpunt, als de provider dat ondersteunt, een afhankelijkheid verwijdert in plaats van toevoegt. Het verwijdert ook de mogelijkheid om een provider te volgen die adressen roteert, dus de ruil is echt en moet worden besloten in plaats van ontdekt.

De browser en de rest van de machine verschillen

De SOCKS-interface van Tor ondersteunt het doorgeven van een bestemmingshostnaam aan de proxy, wat betekent dat de externe kant de resolutie uitvoert en de lokale machine nooit vraagt. Een generieke toepassing die een proxy ondersteunt, kan de naam eerst lokaal oplossen en vervolgens verbinden met het verkregen adres, wat een lokale aanvraag oplevert voor een bestemming waarvan de gebruiker dacht dat die via de proxy liep. De twee toepassingen kunnen dus op verschillende plekken lekken terwijl ze één proxy-instelling delen. Niets in een gedeeld proxyadres vertelt je welk van de twee gedragingen wordt gebruikt.

Browsers voegen nog een laag toe wanneer beveiligde DNS is ingeschakeld, omdat de browser zijn eigen provider kan kiezen en de systeemresolver volledig kan omzeilen. De tunnelclient kan ondertussen een resolver door de tunnel duwen voor de hele machine. Die twee instellingen kunnen beide correct zijn en toch ander gedrag voor verschillende programma's beschrijven.

Controleer het programma dat het verzoek heeft gedaan in plaats van te extrapoleren vanuit één testpagina. Het onderscheid tussen een aanvraag die in de tunnel wordt gedragen en een die Tor nooit bereikte, is precies het onderscheid dat één resolveradres niet kan tonen.

Controleer elk programma en vergelijk dan met de bedoeling

Voer de observaties apart uit: wat het systeem zou gebruiken, waarvoor de browser is geconfigureerd en of de SOCKS-verbinding een naam of een adres draagt. Dat laatste is het verschil tussen externe en lokale resolutie, en specificatie van SOCKS-uitbreidingen beschrijft hoe een hostnaam wordt doorgegeven in plaats van eerst opgelost.

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

Vergelijk dan wat je hebt waargenomen met wat je bedoelde. Een openbare naam die door de tunnel wordt opgelost door een resolver die je hebt gekozen, is niet dezelfde bevinding als een privénaam die tijdens een terugval aan een openbare resolver wordt gegeven, en meestal vereist alleen de tweede actie. De eerste is een configuratie die werkt zoals ontworpen, ook al ziet die er in een rapport ongebruikelijk uit.

Leg de uitzonderingen vast die je accepteert, inclusief de bootstrap-aanvraag die niet kan worden beschermd. Een opgeschreven uitzondering is een ontwerpbeslissing, terwijl dezelfde uitzondering later ontdekt op een defect lijkt. Wie hem vindt, zal hem zo behandelen, en je zult de vergadering besteden aan uitleggen waarom dat niet zo is.