DNS se ne razrješava nakon što VPN kill switch blokira port 53

Kada kill switch obori tunel, sa sobom odnese i DNS put, a resolver koji ostane rijetko je onaj koji očekujete. Dva pristupa tom trenutku prilaze vrlo različito: blokiranje svakog DNS paketa koji nije unutar tunela ili ostavljanje jednog resolvera kao izuzetka. Oba se mogu braniti. Iz kartice preglednika simptomi izgledaju gotovo isto, pa je prvi zadatak utvrditi koji ste pristup zaista primijenili.

Držim tu razliku pred sobom jer je popravak u svakom slučaju suprotan. Jedan pristup traži širi izuzetak, drugi uži. Nagađanje vas košta ili privatnosti ili jednog popodneva.

Dva DNS pristupa za isti prekid

Pristup A tretira resolver kao još jednu uslugu iza tunela. Firewall pravila dozvoljavaju UDP i TCP 53 samo na interfejsu tunela, a adresa koja se daje klijentu je resolver unutar tunela. Kada tunel padne, pretrage prestaju i to je namjerni ishod, a ne kvar.

Pristup B drži resolver dostupnim na lokalnoj mreži, obično ruter na 192.168.1.1 ili sistemski stub na 127.0.0.53, uz obrazloženje da razrješavanje imena ne smije umrijeti s tunelom. To je zgodno na kućnoj LAN mreži gdje ruter razrješava za cijelu kuću. Na Wi-Fi mreži hotela ili aerodroma isti izuzetak pokazuje na tuđi server i svako ime koje otipkate biva otkriveno, iako vaš web promet ostaje blokiran.

Granica je ko posjeduje resolver. Ako vjerujete lokalnom, izuzetak je mala i iskrena rupa. Ako ne, pristup samo kroz tunel jedini je koji drži, a cijena je da oboreni tunel odnese sva imena.

Zašto vlastita pretraga VPN klijenta još radi

Klijent mora razriješiti ime hosta pristupnika prije nego tunel postoji, pa stroga blokada ne smije pokrivati klijentovu putanju za podizanje. Većina klijenata ili kešira adresu odredišta ili isporučuje dokumentovan izuzetak za taj jedan host. Ako vaš skup pravila blokira tu pretragu, tunel se nikada ne vraća i logovi pokazuju klijenta koji ne može doći do vlastitog servera, što je defekt politike, a ne DNS-a.

Podijeljeni DNS je drugo mjesto gdje se to pojavljuje. Klijent gura internu zonu na privatni resolver, a sve ostalo ostavlja sistemskom resolveru. Nakon pada javna imena mogu se još razrješavati dok interna istekom vremena otkazuju, jer privatna zona nema više nijednu rutu. Za korisnika je to "VPN je pokvario internet"; za log resolvera to je upit koji nikada nije stigao.

Pod systemd-resolved možete podjelu vidjeti direktno. resolvectl status prikazuje DNS servere po vezi i domene rutiranja, a nakon pada tunela interna domena nastavlja pokazivati na server na vezi koja više ne postoji. Stub na 127.0.0.53 još prihvata upit, pa čeka na uzvodni server koji neće odgovoriti, i zato kvar traje sekundama umjesto da se odmah vrati.

Šifrirani DNS ne zaobilazi filter paketa

DNS preko HTTPS-a i DNS preko TLS-a putuju na 443 i 853, pa pravilo koje blokira port 53 o njima nije reklo ništa. Blokiranje "DNS-a" po portu je politika o portu, ne o razrješavanju imena. Ako vaš kill switch blokira sav promet izvan tunela, DoH je slučajno pokriven. Ako ste izdvojili dopuštenje za captive portal ili javni resolver, nije.

Kontrole na strani klijenta jeftinija su poluga. Firefox napušta svoj DoH resolver kada se kanarinsko ime use-application-dns.net ne razriješi, zato upravljane mreže objavljuju tu domenu kao NXDOMAIN; korporativna politika je može i fiksirati isključenom. Android Private DNS i Chromeov sigurni DNS imaju svoje prekidače i svoje zadane vrijednosti. Isključiti ih pouzdanije je od juranja za adresama resolvera, jer se lista adresa mijenja, a vaš skup pravila ne.

Postoji verzija ovoga koja uopće nije o curenju. Aplikacija s prikvačenim resolverom i dalje treba mrežni put da do njega dođe. Šifriranje mijenja ko može pročitati upit, a ne može li paket napustiti mašinu, pa blokada cijelog uređaja pobjeđuje postavku bez da je dotakne.

Uparite simptom sa slojem

Većina prijava dolazi kao jedna rečenica, a ta rečenica obično već imenuje sloj. Tabela ispod je ono što prođem prije nego dotaknem pravilo; cilj je odlučiti je li upit blokiran, pogrešno usmjeren ili nikada poslan.

Prva dva reda su ono što ljudi pogrešno dijagnostikuju. Tiho padanje i odbijanje u pregledniku izgledaju isto kao "DNS je pokvaren", ali samo jedno od njih znači da vaš kill switch radi svoj posao. Odbijanje znači da je nešto odgovorilo, pa blokada nije tamo gdje mislite.

Vratite politiku resolvera, pa je dokažite

Popravite pristup, ne simptom. Za razrješavanje samo kroz tunel dozvolite 53 na interfejsu tunela, gurnite interni resolver s konfiguracijom tunela i ostavite fizičku vezu bez ikakvog DNS dopuštenja. U wg-quicku linija DNS = je ono što upisuje resolver u konfiguraciju interfejsa, pa tunel koji je izostavi ostavlja stari resolver na mjestu i svaki upit na pogrešnoj putanji. wg-quick priručnik dokumentuje to ponašanje po platformi.

Zatim provjerite ovim redom. Na Linuxu resolvectl status pokazuje aktivnu vezu, dig +short example.com testira javno ime, dig @10.8.0.1 internal.example.com testira privatno, a sudo tcpdump -ni any port 53 pokazuje koji interfejs paketi koriste dok pokrećete oboje. Na Windowsu Get-DnsClientServerAddress -AddressFamily IPv4 i Resolve-DnsName example.com daju iste dvije činjenice: ko je konfigurisan i ko odgovara.

Završite negativnim testom. Isključite tunel, potvrdite da svježe javno ime ne uspijeva, potvrdite da privatno ime ne uspijeva i potvrdite da nijedan paket na portu 53 nije napustio fizički adapter. Blokada koja drži samo za keširane odgovore ne drži uopće.

Kontrolna lista prije zatvaranja tiketa:

• Resolver koji se koristio tokom prekida je onaj koji politika predviđa.
• Klijentova vlastita pretraga odredišta još je dozvoljena, kešom ili izuzetkom.
• DoH i DoT su ili pokriveni blokadom ili onemogućeni politikom.
• Privatne zone otkazuju zatvoreno, ne otvoreno, kad tunel nestane.