VPN-DNS-fallbacken din: kvar førespurnaden faktisk går

Ei resolverinnstilling skiftar frå den private adressa til ei offentleg, og konklusjonen kjem med ein gong: tunnelen lek. Nokre gonger stemmer det. Ofte reiste reserveførespurnaden framleis inne i tunnelen til ein resolver administratoren hadde valt, noko som gjer det til ei politisk avgjerd snarare enn ein feil. Å skilje desse tilfella krev tre fakta i staden for eitt, og det første er kven som svara. Finn ut kven som tok imot førespurnaden, kva rute som bar han, og kva namn det vart spurt om.

Fallback er ein policy, ikkje éi åtferd

Kvar klient må avgjere kva han gjer når den føretrekte resolveren sluttar å svare. Han kan blokkere oppslag, prøve på nytt, bruke eit konfigurert alternativ eller overlate det til operativsystemet, og frå eit personvernperspektiv er det fire ulike produkt. Å lese innstillingsskjermen fortel deg kva åtferd som er konfigurert; han fortel deg ikkje kva som oppstod. Ein skjerm med éin brytar skildrar ikkje fire moglegeheiter.

Nettlesarar legg på sitt eige lag. Ein nettlesar med sikker DNS slått på kan slå opp eit namn via sin eigen valde leverandør sjølv når operativsystemet peikar ein annan stad, noko som betyr at tunnelklienten sin policy kanskje aldri vert spurd for førespurnadene du faktisk bryr deg om. Sjekk programmet som laga førespurnaden, ikkje berre systeminnstillinga.

Identiteten til den erstattande resolveren er det første faktumet det er verdt å fastslå. Ein offentleg resolver som høyrer til ein leverandør du alt stolar på, er ein annan situasjon enn ei adresse levert av nettverket du tilfeldigvis er på. Adressa sjølv fortel sjeldan kva av dei to du ser på.

Kven som tek imot førespurnaden etter bytet

Mottakaren og ruta er uavhengige, og berre kombinasjonen deira skildrar eksponeringa. Ein offentleg resolver nådd gjennom tunnelen ser aldri adressa til tilgangsnettverket ditt, medan den same resolveren nådd direkte ser ho. Begge tilfella gir eit svar, og ein lekkasjetest som berre rapporterer resolveradressa, vil skildre dei likt. Spør etter grensesnittet så vel som adressa når du les resultatet.

Interne namn gjer skilnaden konkret. Ein offentleg resolver kan vanlegvis ikkje svare på eit split-horizon-namn, så førespurnaden feilar medan namnet likevel er blitt avslørt for ein part som ikkje hadde noko med å sjå det. Tilgjenge og personvern går difor saman her i staden for å bytast mot kvarandre.

Ein tunnel kan òg bera førespurnaden til ein resolver som ikkje vert driven av VPN-leverandøren, fordi tunnelen vidaresender i staden for å slå opp. Verten som vidaresender ser førespurnaden i klartekst og opnar deretter si eiga samband vidare, noko som vernar neste hopp utan å verne det første.

Sjekk ruta og mottakaren saman

Observer pakkane i staden for konfigurasjonen. Spør systemet kva resolver som ville vorte brukt, og stadfest deretter at førespurnaden faktisk forlét det venta grensesnittet til den venta adressa.

resolvectl status | grep -E "Current DNS Server|DNS Servers|DNSOverTLS"
dig +short example.com
tcpdump -ni any udp port 53 or tcp port 853

Viss opptaket viser førespurnaden forlate det fysiske grensesnittet medan tunnelen er oppe, gjekk fallbacken utanom tunnelen uansett kva resolverlista seier. Viss han dukkar opp på tunnelgrensesnittet, vert spørsmålet kven som driv den fjerne enden og kva han held på.

Gjenta sjekken for eitt internt namn og eitt offentleg namn. Den interne førespurnaden er der ein fallback-konfigurasjon vanlegvis avslører seg, fordi ein resolver som ikkje kan svare likevel tek imot spørsmålet.

Avgjer om fallbacken skal tillatast

Viss kravet er at oppslag stoppar når den føretrekte resolveren ikkje er tilgjengeleg, konfigurer ein handhevingspolicy som feilar lukka og godta konsekvensen: namn vil ikkje verte slått opp under eit avbrot. Det er ein medviten tilgjengehandel og ikkje ein funksjonsfeil, og designet bør seie det før avbrotet skjer.

Viss kravet berre er at førespurnader ikkje skal reise utanfor tunnelen, kan ein offentleg resolver nådd gjennom tunnelen vere akseptabel føresett at operatøren og oppbevaringspolicyen hans er forstått. Ei slik aksept er ei vurdering av ein tredjepart og ikkje ein påstand om kryptografi, og ho høyrer til den som eig personvernpåstanden. Viss interne namn må halde fram med å verke, må fallbacken vere ein resolver som held dei interne sonene, noko som vanlegvis betyr at fallbackmålet er ein annan tenar og ikkje ein annan adressefamilie.

Dokumenter resultatet som ei setning om åtferd: kva resolver som tek imot førespurnader i normal drift, kven som tek imot dei etter ein feil, og om interne namn vert slått opp i det andre tilfellet. Ein lekkasjetest som til slutt lastar ei side, beviser mindre enn den setninga, fordi ei side kan lastast gjennom ein resolver som aldri burde vore spurd.