Kvar DNS går når du kombinerer Tor og ein VPN

To personvernverktøy køyrer, éi side lastar ikkje, og ein resolvertest seier at noko utanfor nettlesaren har fått eit namn. Før det blir ein lekkasjerapport, nemn utvekslinga det kom frå. Eit Tor-pluss-VPN-oppsett inneheld minst tre ulike namneoppslag med tre ulike eigarar, og å gå gjennom dei i den rekkjefølgja dei skjer er den snøggaste vegen til å sjå kva som oppfører seg gale.

Nemn kvar utveksling før du kallar det ein lekkasje

Den første utvekslinga løyser sjølve VPN-endepunktet, og ho skjer før noko vern finst. Den andre løyser ein destinasjon for Tor Browser, som kan gje namnet vidare til proxyen i staden for å løyse det lokalt. Den tredje dekkjer alt anna på maskinen, mellom anna oppdateringskontrollar, e-postklientar og operativsystemet sine eigne tenesteførespurnader. Berre den første av dei kan skje utan at dei to andre er med.

Kvar av dei kan følgje ein annan veg, og ein einaste nettlesartest observerer berre sin eigen førespurnad. Å handsame eitt resultat som tilstanden til alle tre er der det meste av forvirringa byrjar.

Skriv ned kva namn som høyrer til kva lag før du endrar noko. Private organisasjonsnamn, ein offentleg destinasjon og sjølve tunnelendepunktet har ikkje same kravet, og ein politikk som handsamar dei som éin kategori vil øydeleggje noko.

Bootstrap-førespurnaden skjer før tunnelen

Ein klient som er sett opp med eit vertsnamn, må løyse det namnet for å opne tunnelen, og i det augeblikket finst det ingen tunnel til å bere førespurnaden. Den resolvaren operativsystemet byd på i det gjeldande nettet svarar, og det kan vere ein fanga portal, ein hotellresolver eller ein offentleg. Det er ikkje ein lekkasje i tunnelen, for det finst ingen tunnel enno.

Å endre den trygge DNS-innstillinga til nettlesaren rører heller ikkje denne førespurnaden, sidan ho høyrer til ei teneste som køyrer utanfor nettlesaren og startar før noka side blir opna. Om namnet på endepunktet ikkje blir løyst, hjelper ingen politikk inne i tunnelen, fordi feilen skjer eitt steg tidlegare enn alt konfigurasjonen skildrar.

Dette er den einaste staden der bruk av ei bokstaveleg adresse for endepunktet, om tilbydaren støttar det, fjernar ein avhengnad i staden for å leggje til ein. Det fjernar òg evna til å følgje ein tilbydar som roterer adresser, så byttet er reelt og bør avgjerast i staden for å oppdagast.

Nettlesaren og resten av maskinen er ulike

SOCKS-grensesnittet til Tor støttar å sende eit vertsnamn for destinasjonen vidare til proxyen, noko som tyder at den fjerne enden gjer oppløysinga og den lokale maskinen aldri spør. Eit generelt program som støttar ein proxy kan først løyse namnet lokalt og så kople til adressa det fekk, noko som lagar ein lokal førespurnad for ein destinasjon brukaren trudde gjekk gjennom proxyen. Dei to programma kan difor lekke på ulike stader medan dei deler éi proxy-innstilling. Ingenting i ei delt proxy-adresse fortel deg kva av dei to åtferdene som er i bruk.

Nettlesarar legg til eit lag til når trygg DNS er slått på, fordi nettlesaren kan velje sin eigen tilbydar og gå heilt utanom systemresolvaren. Tunnelklienten kan samstundes skyve ein resolver gjennom tunnelen for heile maskinen. Desse to innstillingane kan begge vere rette og likevel skildre ulik åtferd for ulike program.

Sjekk programmet som gjorde førespurnaden i staden for å generalisere frå éi testsida. Skilnaden mellom ein førespurnad som blir boren inne i tunnelen og ein som aldri nådde Tor, er nett den skilnaden som éi resolveradresse ikkje kan vise.

Sjekk kvart program, og samanlikn så med intensjonen

Gjer observasjonane kvar for seg: kva systemet ville bruke, kva nettlesaren er sett opp for og om SOCKS-sambandet ber eit namn eller ei adresse. Det siste er skilnaden mellom fjern og lokal oppløysing, og spesifikasjonen for SOCKS-utvidingar skildrar korleis eit vertsnamn blir sendt vidare i staden for å bli løyst 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

Samanlikn så det du observerte med det du meinte. Eit offentleg namn som blir løyst gjennom tunnelen av ein resolver du valde, er ikkje same funnet som eit privat namn som blir gitt til ein offentleg resolver under eit fallback, og vanlegvis er det berre det andre som krev handling. Det første er ein konfigurasjon som verkar som tenkt, sjølv om han ser ukjend ut i ein rapport.

Skriv ned unntaka du godtek, mellom anna bootstrap-førespurnaden som ikkje kan vernast. Eit nedskrive unntak er eit designval, medan det same unntaket oppdaga seinare ser ut som ein feil. Den som finn det vil handsame det slik, og du vil bruke møtet på å forklare kvifor det ikkje er det.