Vaš VPN DNS fallback: kam zahteva v resnici odide

Nastavitev razreševalnika se preklopi z zasebnega naslova na javnega in sklep pride takoj: tunel uhaja. Včasih je res tako. Pogosto je nadomestna poizvedba vseeno potovala znotraj tunela do razreševalnika, ki ga je izbral skrbnik, kar iz tega naredi odločitev o politiki in ne napako. Za ločevanje teh primerov so potrebna tri dejstva namesto enega, prvo pa je, kdo je odgovoril. Ugotovite, kdo je prejel poizvedbo, katera pot jo je nesla in po katerih imenih se je spraševalo.

Nadomestna pot je politika, ne eno vedenje

Vsak odjemalec se mora odločiti, kaj stori, ko želeni razreševalnik neha odgovarjati. Lahko blokira razreševanje, poskusi znova, uporabi konfigurirano alternativo ali to prepusti operacijskemu sistemu, in z vidika zasebnosti so to štirje različni izdelki. Branje zaslona z nastavitvami vam pove, katero vedenje je konfigurirano; ne pove, katero se je zgodilo. Zaslon z enim stikalom ne opisuje štirih možnosti.

Brskalniki dodajo svojo plast. Brskalnik z vključenim varnim DNS lahko razreši ime prek lastnega izbranega ponudnika tudi, ko operacijski sistem kaže drugam, kar pomeni, da politika odjemalca tunela morda nikoli ne bo vprašana za zahteve, ki so vam res pomembne. Preverite aplikacijo, ki je zahtevo poslala, ne le sistemske nastavitve.

Identiteta nadomestnega razreševalnika je prvo dejstvo, ki se ga je vredno lotiti. Javni razreševalnik, ki pripada ponudniku, ki mu že zaupate, je drugačna situacija kot naslov, ki ga zagotovi omrežje, v katerem ste. Naslov sam redko pove, na katero od teh dveh gledate.

Kdo prejme poizvedbo po preklopu

Prejemnik in pot sta neodvisna in le njuna kombinacija opisuje izpostavljenost. Javni razreševalnik, dosežen skozi tunel, nikoli ne vidi naslova vašega dostopovnega omrežja, medtem ko isti razreševalnik, dosežen neposredno, ga vidi. Oba primera dasta odgovor in preizkus uhajanja, ki poroča le naslov razreševalnika, ju bo opisal enako. Ob branju rezultata vprašajte po vmesniku in naslovu.

Notranja imena naredijo razliko konkretno. Javni razreševalnik običajno ne more odgovoriti na ime iz split-horizona, zato poizvedba ne uspe, medtem ko je ime vseeno razkrito strani, ki je ni imela kaj videti. Razpoložljivost in zasebnost torej gresta tu skupaj, namesto da bi se izmenjevali.

Tunel lahko poizvedbo odnese tudi do razreševalnika, ki ga ponudnik VPN ne upravlja, ker tunel posreduje in ne razrešuje. Gostitelj, ki posreduje, vidi poizvedbo v čistem besedilu in nato odpre svojo povezavo naprej, kar zaščiti naslednji skok, ne pa prvega.

Preverite pot in prejemnika skupaj

Opazujte pakete in ne konfiguracije. Vprašajte sistem, kateri razreševalnik bi bil uporabljen, nato potrdite, da je poizvedba res odšla z pričakovanega vmesnika na pričakovani naslov.

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

Če posnetek pokaže, da poizvedba zapušča fizični vmesnik, medtem ko je tunel aktiven, je nadomestna pot obšla tunel ne glede na to, kaj pravi seznam razreševalnikov. Če se pojavi na vmesniku tunela, postane vprašanje, kdo upravlja oddaljeni konec in kaj hrani.

Preverjanje ponovite za eno notranje in eno javno ime. Notranja poizvedba je kraj, kjer se nadomestna konfiguracija običajno razkrije, ker razreševalnik, ki ne more odgovoriti, vprašanje vseeno prejme.

Odločite, ali naj bo nadomestna pot dovoljena

Če je zahteva, da se razreševanje ustavi, ko želeni razreševalnik ni na voljo, nastavite izvršilno politiko, ki ne uspe zaprto, in sprejmite posledico: imena se med prekinitvijo ne bodo razrešila. To je namerna izmenjava razpoložljivosti in ne okvara, in zasnova bi to morala povedati, preden do prekinitve pride.

Če je zahteva le, da poizvedbe ne potujejo izven tunela, je javni razreševalnik, dosežen skozi tunel, lahko sprejemljiv, če razumete operaterja in njegovo politiko hrambe. Taka sprejemljivost je presoja o tretji strani in ne trditev o kriptografiji, in pripada tistemu, ki ima zahtevek glede zasebnosti. Če morajo notranja imena delovati naprej, mora biti nadomestna pot razreševalnik, ki hrani notranje cone, kar običajno pomeni, da je nadomestni cilj drug strežnik in ne druga družina naslovov.

Izid zapišite kot stavek o vedenju: kateri razreševalnik prejema poizvedbe pri običajnem delovanju, kateri jih prejme po okvari in ali se notranja imena v drugem primeru razrešijo. Preizkus uhajanja, ki na koncu naloži stran, dokaže manj kot ta stavek, ker se stran lahko naloži prek razreševalnika, ki se ga ne bi smelo nikoli vprašati.