Vaš VPN DNS fallback: kamo zahtjev stvarno odlazi

Postavka resolvera prebacuje se s privatne adrese na javnu i zaključak dolazi odmah: tunel curi. Ponekad je tako. Često je rezervni zahtjev ipak putovao unutar tunela do resolvera koji je odabrao administrator, što od toga čini odluku o politici, a ne kvar. Razdvajanje tih slučajeva zahtijeva tri činjenice umjesto jedne, a prva je tko je odgovorio. Saznajte kome je zahtjev stigao, koja ga je ruta nosila i za koja se imena pitalo.

Rezervni put je politika, a ne jedno ponašanje

Svaki klijent mora odlučiti što će učiniti kad preferirani resolver prestane odgovarati. Može blokirati razrješavanje, pokušati ponovno, upotrijebiti konfiguriranu alternativu ili to prepustiti operacijskom sustavu, a sa stajališta privatnosti to su četiri različita proizvoda. Čitanje zaslona postavki kaže vam koje je ponašanje konfigurirano; ne kaže vam koje se dogodilo. Zaslon s jednim prekidačem ne opisuje četiri mogućnosti.

Preglednici dodaju svoj sloj. Preglednik s uključenim sigurnim DNS-om može razriješiti ime preko vlastitog odabranog davatelja čak i kad operacijski sustav pokazuje drugamo, što znači da se politika klijenta tunela možda nikad neće razmotriti za zahtjeve koji su vam stvarno važni. Provjerite aplikaciju koja je poslala zahtjev, a ne samo sistemsku postavku.

Identitet zamjenskog resolvera prva je činjenica koju vrijedi utvrditi. Javni resolver koji pripada davatelju kojem već vjerujete drukčija je situacija od adrese koju pruža mreža na kojoj se slučajno nalazite. Sama adresa rijetko otkriva na koju od tih dviju gledate.

Tko prima zahtjev nakon prebacivanja

Primatelj i ruta neovisni su, a samo njihova kombinacija opisuje izloženost. Javni resolver dohvaćen kroz tunel nikad ne vidi adresu vaše pristupne mreže, dok je isti resolver dohvaćen izravno vidi. Oba slučaja daju odgovor, a test curenja koji izvješćuje samo adresu resolvera opisat će ih jednako. Zatražite sučelje kao i adresu kad čitate rezultat.

Interna imena čine razliku konkretnom. Javni resolver obično ne može odgovoriti na ime iz split-horizona, pa zahtjev ne uspijeva dok je ime ipak otkriveno strani koja ga nije trebala vidjeti. Dostupnost i privatnost ovdje dakle idu zajedno umjesto da se razmjenjuju.

Tunel može zahtjev nositi i do resolvera kojim ne upravlja VPN davatelj, jer tunel prosljeđuje umjesto da razrješava. Domaćin koji prosljeđuje vidi zahtjev u čistom tekstu i zatim otvara vlastitu vezu dalje, što štiti sljedeći skok bez zaštite prvoga.

Provjerite rutu i primatelja zajedno

Promatrajte pakete umjesto konfiguracije. Pitajte sustav koji bi se resolver koristio, a zatim potvrdite da je zahtjev doista otišao s očekivanog sučelja na očekivanu adresu.

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

Ako snimka pokazuje da zahtjev napušta fizičko sučelje dok je tunel aktivan, rezervni je put zaobišao tunel bez obzira na to što popis resolvera kaže. Ako se pojavi na sučelju tunela, pitanje postaje tko upravlja udaljenim krajem i što zadržava.

Ponovite provjeru za jedno interno i jedno javno ime. Interni je zahtjev mjesto na kojem se rezervna konfiguracija obično otkrije, jer resolver koji ne može odgovoriti ipak prima pitanje.

Odlučite treba li rezervni put dopustiti

Ako je uvjet da se razrješavanje zaustavi kad preferirani resolver nije dostupan, konfigurirajte provedbenu politiku koja ne uspijeva zatvoreno i prihvatite posljedicu: imena se tijekom prekida neće razriješiti. To je namjerna razmjena dostupnosti, a ne kvar, i dizajn bi to trebao reći prije nego se prekid dogodi.

Ako je uvjet samo to da zahtjevi ne smiju putovati izvan tunela, javni resolver dohvaćen kroz tunel može biti prihvatljiv pod uvjetom da se razumiju operater i njegova politika zadržavanja. Takvo je prihvaćanje prosudba o trećoj strani, a ne tvrdnja o kriptografiji, i pripada onome tko nosi tvrdnju o privatnosti. Ako interna imena moraju nastaviti raditi, rezervni put mora biti resolver koji drži interne zone, što obično znači da je rezervni cilj drugi poslužitelj, a ne druga obitelj adresa.

Dokumentirajte ishod kao rečenicu o ponašanju: koji resolver prima zahtjeve u normalnom radu, koji ih prima nakon kvara i razrješavaju li se interna imena u drugom slučaju. Test curenja koji na kraju učita stranicu dokazuje manje od te rečenice, jer se stranica može učitati preko resolvera koji se nikad nije smio konzultirati.