Hvor DNS ender, når du kombinerer Tor og en VPN

To privatlivsværktøjer kører, én side indlæses ikke, og en resolvertest siger, at noget uden for browseren har modtaget et navn. Inden det bliver en lækagerapport, skal du navngive den udveksling, det kom fra. Et Tor plus VPN-opsætning indeholder mindst tre forskellige navneopslag med tre forskellige ejere, og at gennemgå dem i den rækkefølge, de sker, er den hurtigste måde at se, hvilken der opfører sig forkert.

Navngiv hver udveksling, før du kalder det en lækage

Den første udveksling slår selve VPN-endepunktet op, og den sker, før der findes nogen beskyttelse. Den anden slår en destination op for Tor Browser, som kan give navnet videre til proxyen i stedet for at slå det op lokalt. Den tredje dækker alt andet på maskinen, herunder opdateringstjek, mailklienter og styresystemets egne tjenesteopslag. Kun den første kan ske, uden at de to andre er involveret.

Hver af dem kan følge en forskellig vej, og en enkelt browserbaseret test observerer kun sin egen anmodning. At behandle ét resultat som tilstanden for alle tre er, hvor det meste forvirring starter.

Skriv ned, hvilke navne der hører til hvilket lag, før du ændrer noget. Private organisatoriske navne, en offentlig destination og selve tunnelendepunktet har ikke samme krav, og en politik, der behandler dem som én kategori, vil ødelægge noget.

Bootstrap-opslaget sker før tunnelen

En klient, der er konfigureret med et værtsnavn, skal slå det navn op for at åbne tunnelen, og i det øjeblik findes der ingen tunnel til at bære forespørgslen. Den resolver, som styresystemet tilbyder på det aktuelle netværk, svarer, og det kan være en captive portal, en hotelresolver eller en offentlig en. Det er ikke en lækage i tunnelen, fordi der ikke er nogen tunnel endnu.

Ændring af browserens indstilling for sikker DNS rører heller ikke dette opslag, da det hører til en tjeneste, der kører uden for browseren og starter, før nogen side åbnes. Hvis endepunktets navn ikke kan slås op, hjælper ingen politik inde i tunnelen, fordi fejlen sker et trin tidligere end alt, hvad konfigurationen beskriver.

Det er det ene sted, hvor brug af en bogstavelig adresse til endepunktet, hvis udbyderen understøtter det, fjerner en afhængighed i stedet for at tilføje en. Det fjerner også muligheden for at følge en udbyder, der roterer adresser, så byttet er reelt og bør besluttes frem for opdages.

Browseren og resten af maskinen er forskellige

Tors SOCKS-grænseflade understøtter at sende et destinationsværtsnavn videre til proxyen, hvilket betyder, at den fjerne ende udfører opslaget, og den lokale maskine aldrig spørger. En generisk applikation, der understøtter en proxy, kan først slå navnet op lokalt og derefter oprette forbindelse til den adresse, den fik, hvilket giver et lokalt opslag for en destination, som brugeren troede var proxet. De to applikationer kan derfor lække forskellige steder, mens de deler én proxyindstilling. Intet i en delt proxyadresse fortæller dig, hvilken af de to adfærdsformer der bruges.

Browsere tilføjer endnu et lag, når sikker DNS er aktiveret, fordi browseren kan vælge sin egen udbyder og helt omgå systemets resolver. Tunnelklienten kan samtidig skubbe en resolver gennem tunnelen for hele maskinen. Begge disse indstillinger kan være korrekte og alligevel beskrive forskellig adfærd for forskellige programmer.

Kontroller det program, der lavede anmodningen, i stedet for at ekstrapolere fra én testsi. Forskellen mellem en forespørgsel, der bæres inde i tunnelen, og en, der aldrig nåede Tor, er præcis den forskel, som én resolveradresse ikke kan vise.

Kontroller hvert program, og sammenlign derefter med hensigten

Kør observationerne hver for sig: hvad systemet ville bruge, hvad browseren er konfigureret til at bruge, og om SOCKS-forbindelsen bærer et navn eller en adresse. Det sidste er forskellen mellem fjernopslag og lokalt opslag, og SOCKS-udvidelsesspecifikationen beskriver, hvordan et værtsnavn sendes videre i stedet for at blive slået op 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

Sammenlign derefter det, du observerede, med det, du havde til hensigt. Et offentligt navn, der slås op gennem tunnelen af en resolver, du har valgt, er ikke det samme fund som et privat navn, der gives til en offentlig resolver under et fallback, og kun det andet kræver normalt handling. Det første er en konfiguration, der fungerer som designet, selv om den ser uvant ud i en rapport.

Registrer de undtagelser, du accepterer, herunder bootstrap-opslaget, som ikke kan beskyttes. En undtagelse, der er skrevet ned, er en designbeslutning, mens den samme undtagelse opdaget senere ser ud som en fejl. Den person, der finder den, vil behandle den som én, og du vil bruge mødet på at forklare, hvorfor det ikke er tilfældet.