Vart DNS tar vägen när du kombinerar Tor och en VPN

Två integritetsverktyg körs, en sida laddas inte och ett resolvertest säger att något utanför webbläsaren har fått ett namn. Innan det blir en läckarapport, namnge utbytet det kom från. En Tor plus VPN-konfiguration innehåller minst tre olika namnförfrågningar med tre olika ägare, och att gå igenom dem i den ordning de sker är det snabbaste sättet att se vilken som beter sig fel.

Namnge varje utbyte innan du kallar det en läcka

Det första utbytet löser själva VPN-slutpunkten, och det sker innan något skydd existerar. Det andra löser en destination för Tor Browser, som kan lämna namnet till proxyn i stället för att lösa det lokalt. Det tredje täcker allt annat på maskinen, inklusive uppdateringskontroller, e-postklienter och operativsystemets egna tjänsteförfrågningar. Bara det första kan ske utan att de andra två är inblandade.

Var och en av dem kan följa en annan väg, och ett enda webbläsartest observerar bara sin egen begäran. Att behandla ett resultat som tillståndet för alla tre är där det mesta av förvirringen börjar.

Skriv ner vilka namn som hör till vilket lager innan du ändrar något. Privata organisationsnamn, en offentlig destination och själva tunnelslutpunkten har inte samma krav, och en policy som behandlar dem som en kategori kommer att bryta något.

Bootstrap-förfrågan sker före tunneln

En klient som konfigurerats med ett värdnamn måste lösa det namnet för att öppna tunneln, och i det ögonblicket finns ingen tunnel som kan bära förfrågan. Den resolver som operativsystemet erbjuder på det aktuella nätverket svarar, och det kan vara en fångad portal, en hotellresolver eller en offentlig. Det är inte en läcka i tunneln, eftersom det inte finns någon tunnel ännu.

Att ändra webbläsarens inställning för säker DNS påverkar inte heller denna förfrågan, eftersom den hör till en tjänst som körs utanför webbläsaren och startar innan någon sida öppnas. Om slutpunktens namn inte kan lösas hjälper ingen policy inne i tunneln, eftersom felet inträffar ett steg tidigare än allt som konfigurationen beskriver.

Detta är den enda platsen där användningen av en bokstavlig adress för slutpunkten, om leverantören stöder det, tar bort ett beroende i stället för att lägga till ett. Det tar också bort möjligheten att följa en leverantör som roterar adresser, så bytet är verkligt och bör beslutas i stället för upptäckas.

Webbläsaren och resten av maskinen skiljer sig

Tors SOCKS-gränssnitt stöder att skicka ett destinationsvärdnamn vidare till proxyn, vilket innebär att den fjärran änden utför uppslagningen och den lokala maskinen aldrig frågar. Ett generellt program som stöder en proxy kan först lösa namnet lokalt och sedan ansluta till den adress det fick, vilket ger en lokal förfrågan för en destination som användaren trodde gick via proxyn. De två programmen kan därför läcka på olika ställen medan de delar en enda proxyinställning. Inget i en delad proxyadress berättar vilket av de två beteendena som används.

Webbläsare lägger till ytterligare ett lager när säker DNS är aktiverad, eftersom webbläsaren kan välja sin egen leverantör och kringgå systemets resolver helt. Tunnelklienten kan samtidigt skjuta en resolver genom tunneln för hela maskinen. Dessa två inställningar kan båda vara korrekta och ändå beskriva olika beteende för olika program.

Kontrollera programmet som gjorde begäran i stället för att generalisera från en testside. Skillnaden mellan en förfrågan som bärs inne i tunneln och en som aldrig nådde Tor är precis den skillnad som en enda resolveradress inte kan visa.

Kontrollera varje program och jämför sedan med avsikten

Gör observationerna var för sig: vad systemet skulle använda, vad webbläsaren är konfigurerad för och om SOCKS-anslutningen bär ett namn eller en adress. Det sista är skillnaden mellan fjärruppslagning och lokal uppslagning, och specifikationen för SOCKS-utökningar beskriver hur ett värdnamn skickas vidare i stället för att slås upp först.

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

Jämför sedan det du observerade med det du avsåg. Ett offentligt namn som slås upp genom tunneln av en resolver du valt är inte samma fynd som ett privat namn som lämnas till en offentlig resolver vid en återgång, och vanligtvis är det bara det andra som kräver åtgärd. Det första är en konfiguration som fungerar som designat, även om den ser ovanlig ut i en rapport.

Registrera de undantag du accepterar, inklusive bootstrap-förfrågan som inte kan skyddas. Ett nedskrivet undantag är ett designbeslut, medan samma undantag upptäckt senare ser ut som en defekt. Den som hittar det kommer att behandla det som en sådan, och du kommer att tillbringa mötet med att förklara varför det inte är det.