Hvor DNS går hen når du kombinerer Tor og en VPN

To personvernverktøy kjører, én side lastes ikke, og en resolvertest sier at noe utenfor nettleseren har mottatt et navn. Før det blir en lekkasjerapport, navngi utvekslingen det kom fra. Et Tor-pluss-VPN-oppsett inneholder minst tre forskjellige navneoppslag med tre forskjellige eiere, og å gå gjennom dem i den rekkefølgen de skjer er den raskeste måten å se hvilken som oppfører seg galt.

Navngi hver utveksling før du kaller det en lekkasje

Den første utvekslingen slår opp selve VPN-endepunktet, og den skjer før noen beskyttelse eksisterer. Den andre slår opp en destinasjon for Tor Browser, som kan gi navnet videre til proxyen i stedet for å slå det opp lokalt. Den tredje dekker alt annet på maskinen, inkludert oppdateringskontroller, e-postklienter og operativsystemets egne tjenesteforespørsler. Bare den første kan skje uten at de to andre er involvert.

Hver av dem kan følge en annen vei, og én enkelt nettlesertest observerer bare sin egen forespørsel. Å behandle ett resultat som tilstanden til alle tre er der det meste av forvirringen begynner.

Skriv ned hvilke navn som hører til hvilket lag før du endrer noe. Private organisasjonsnavn, en offentlig destinasjon og selve tunnelendepunktet har ikke samme krav, og en policy som behandler dem som én kategori vil ødelegge noe.

Bootstrap-oppslaget skjer før tunnelen

En klient som er konfigurert med et vertsnavn, må slå opp det navnet for å åpne tunnelen, og i det øyeblikket finnes det ingen tunnel som kan bære forespørselen. Den resolveren operativsystemet tilbyr på det gjeldende nettverket svarer, og det kan være en fanget portal, en hotellresolver eller en offentlig. Det er ikke en lekkasje i tunnelen, fordi det ikke finnes noen tunnel ennå.

Å endre nettleserens innstilling for sikker DNS berører heller ikke dette oppslaget, siden det hører til en tjeneste som kjører utenfor nettleseren og starter før noen side åpnes. Hvis navnet på endepunktet ikke lar seg slå opp, hjelper ingen policy inne i tunnelen, fordi feilen skjer ett trinn tidligere enn alt konfigurasjonen beskriver.

Dette er det eneste stedet hvor bruk av en bokstavelig adresse for endepunktet, hvis leverandøren støtter det, fjerner en avhengighet i stedet for å legge til en. Det fjerner også evnen til å følge en leverandør som roterer adresser, så byttet er reelt og bør besluttes i stedet for oppdages.

Nettleseren og resten av maskinen er forskjellige

SOCKS-grensesnittet til Tor støtter å sende et vertsnavn for destinasjonen videre til proxyen, noe som betyr at den fjerne enden utfører oppslaget og den lokale maskinen aldri spør. Et generelt program som støtter en proxy, kan først slå opp navnet lokalt og deretter koble til adressen det fikk, noe som gir et lokalt oppslag for en destinasjon brukeren trodde gikk gjennom proxyen. De to programmene kan derfor lekke på forskjellige steder mens de deler én proxyinnstilling. Ingenting i en delt proxyadresse forteller deg hvilken av de to atferdene som er i bruk.

Nettlesere legger til et lag når sikker DNS er slått på, fordi nettleseren kan velge sin egen leverandør og gå helt utenom systemresolveren. Tunnelklienten kan samtidig skyve en resolver gjennom tunnelen for hele maskinen. Disse to innstillingene kan begge være riktige og likevel beskrive ulik atferd for ulike programmer.

Sjekk programmet som laget forespørselen i stedet for å generalisere fra én testside. Forskjellen mellom en forespørsel som bæres inne i tunnelen og en som aldri nådde Tor, er nøyaktig den forskjellen som én resolveradresse ikke kan vise.

Sjekk hvert program, og sammenlign deretter med intensjonen

Gjør observasjonene hver for seg: hva systemet ville bruke, hva nettleseren er konfigurert for, og om SOCKS-tilkoblingen bærer et navn eller en adresse. Det siste er forskjellen mellom fjern og lokal oppslagning, og spesifikasjonen for SOCKS-utvidelser beskriver hvordan et vertsnavn sendes videre i stedet for å slås opp 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 deretter det du observerte med det du mente. Et offentlig navn som slås opp gjennom tunnelen av en resolver du valgte, er ikke det samme funnet som et privat navn som gis til en offentlig resolver under en fallback, og vanligvis er det bare det andre som krever handling. Det første er en konfigurasjon som fungerer som designet, selv om den ser uvanlig ut i en rapport.

Registrer unntakene du aksepterer, inkludert bootstrap-oppslaget som ikke kan beskyttes. Et nedskrevet unntak er en designbeslutning, mens det samme unntaket oppdaget senere ser ut som en feil. Den som finner det vil behandle det som en feil, og du vil bruke møtet på å forklare hvorfor det ikke er det.