DNS nesprendžiamas, kai VPN kill switch užblokuoja 53 prievadą
Kill switch gali sąmoningai blokuoti DNS. Palyginkite sprendimą tik tunelio viduje su vietinio resolverio išimtimi ir tada išsiaiškinkite, kuris sluoksnis iš tikrųjų sugedo.
Kai kill switch numeta tunelį, jis kartu pasiima ir DNS kelią, o likęs resolveris retai būna tas, kurio tikitės. Du sprendimai tą akimirką traktuoja labai skirtingai: blokuoti kiekvieną DNS paketą, kuris nėra tunelio viduje, arbapalikti vieną resolverį kaip išimtį. Abu variantai apginami. Naršyklės kortelėje simptomai atrodo beveik vienodai, todėl pirmas darbas yra išsiaiškinti, kurį sprendimą iš tikrųjų įdiegėte.
Laikau šį skirtumą akyse, nes pataisa abiem atvejais priešinga. Vienam sprendimui reikia platesnės išimties, kitam — siauresnės. Spėliojimas jums kainuoja arba privatumą, arba pusdienį.
Du DNS sprendimai tai pačiai avarijai
Sprendimas A traktuoja resolverį kaip dar vieną paslaugą už tunelio. Ugniasienės taisyklės leidžia UDP ir TCP 53 tik tunelio sąsajoje, o klientui duodamas adresas yra resolveris tunelio viduje. Kai tunelis nukrenta, paieškos sustoja, ir tai yra numatytas rezultatas, o ne gedimas.
Sprendimas B palieka resolverį pasiekiamą vietiniame tinkle, dažniausiai maršrutizatorių adresu 192.168.1.1 arba operacinės sistemos stub adresu 127.0.0.53, remiantis tuo, kad vardų sprendimas neturėtų mirti kartu su tuneliu. Tai patogu namų LAN tinkle, kur maršrutizatorius sprendžia visiems namams. Viešbučio ar oro uosto Wi-Fi tinkle ta pati išimtis rodo į kažkieno kito serverį, ir kiekvienas įvestas vardas atskleidžiamas, nors jūsų žiniatinklio srautas lieka užblokuotas.
Riba yra tai, kam priklauso resolveris. Jei pasitikite vietiniu, išimtis yra maža ir sąžininga skylė. Jei ne, sprendimas tik per tunelį yra vienintelis, kuris laikosi, o kaina yra tai, kad nukritęs tunelis pasiima visus vardus.
Kodėl paties VPN kliento paieška vis dar veikia
Klientas turi išspręsti šliuzo pagrindinio kompiuterio vardą prieš atsirandant tuneliui, todėl griežtas blokavimas neturi apimti kliento įkrovimo kelio. Dauguma klientų arba talpina pabaigos taško adresą podelyje, arba pateikia dokumentuotą įkrovimo išimtį tam vienam mazgui. Jei jūsų taisyklių rinkinys blokuoja tą paiešką, tunelis niekada negrįš, o žurnalai rodys klientą, kuris negali pasiekti savo serverio; tai politikos, o ne DNS defektas.
Padalintas DNS yra kita vieta, kur tai pasirodo. Klientas stumia vidinę zoną į privatų resolverį, o visa kita palieka sistemos resolveriui. Po nukritimo vieši vardai gali vis dar sprendžiami, o vidiniai baigiasi laiko limitu, nes privačioji zona nebeturi maršruto. Naudotojui tai "VPN sugadino internetą"; resolverio žurnalui tai užklausa, kuri taip ir neatėjo.
Su systemd-resolved padalijimą matote tiesiogiai.resolvectl statusišvardija DNS serverius kiekvienai jungčiai ir maršrutizavimo domenus, o tuneliui nukritus vidinis domenas toliau rodo į serverį jungtyje, kurios nebėra. Stub adresu 127.0.0.53 dar priima užklausą, tada laukia viršutinės grandies, kuri neatsakys, ir todėl gedimas trunka kelias sekundes, o ne grįžta iš karto.
Šifruotas DNS neapeina paketų filtro
DNS over HTTPS ir DNS over TLS keliauja per 443 ir 853, tad taisyklė, blokuojanti 53 prievadą, apie juos nieko nepasakė. Blokuoti "DNS" pagal prievadą yra politika apie prievadą, o ne apie vardų sprendimą. Jei jūsų kill switch blokuoja visą srautą už tunelio, DoH patenka atsitiktinai. Jei atskyrei leidimą captive portal ar viešajam resolveriui, nepatenka.
Kliento pusės valdikliai yra pigesnė svirtis. Firefox atsisako savo DoH resolverio, kai kanarėlės vardasuse-application-dns.netneišsprendžiamas, todėl valdomi tinklai skelbia tą domeną kaip NXDOMAIN; įmonės politika gali jį ir išjungtą prisegti. Android Private DNS ir Chrome saugusis DNS turi savo jungiklius ir savo numatytąsias reikšmes. Juos išjungti patikimiau nei vytis resolverių adresus, nes adresų sąrašas keičiasi, o jūsų taisyklių rinkinys ne.
Yra šito versija, kuri visai ne apie nutekėjimus. Programai su prisegtu resolveriu vis tiek reikia tinklo kelio jam pasiekti. Šifravimas keičia tai, kas gali perskaityti užklausą, o ne tai, ar paketas gali palikti mašiną, todėl viso įrenginio blokavimas nugali nustatymą jo neliesdamas.
Suderinkite simptomą su sluoksniu
Dauguma pranešimų ateina vienu sakiniu, ir tas sakinys paprastai jau įvardija sluoksnį. Lentelė žemiau yra tai, ką peržiūriu prieš liesdamas taisyklę; tikslas yra nuspręsti, ar užklausa buvo užblokuota, nukreipta ne ten, ar visai neišsiųsta.
| Symptom | Likely layer | First check |
|---|---|---|
| Every name fails at once, instantly | Resolver answering with a refusal | Query the resolver by address, not by name |
| Lookups hang for seconds, then time out | Packets dropped with no response | Watch port 53 on the physical link |
| Public names resolve, internal ones do not | Split-DNS routing domain | Per-link DNS servers on the tunnel |
| Names resolve, the page still fails | Not DNS: routing or MTU | Connect to the IP directly |
| Only one application fails | Pinned resolver or cached answer | Check that app's DNS setting |
Pirmos dvi eilutės yra tos, kurias žmonės diagnozuoja neteisingai. Tylus nukritimas ir atmetimas naršyklėje atrodo vienodai kaip "DNS sugedo", bet tik vienas iš jų reiškia, kad jūsų kill switch dirba savo darbą. Atmetimas reiškia, kad kažkas atsakė, tad blokavimas yra ne ten, kur manote.
Atkurkite resolverio politiką ir tada ją įrodykite
Taisykite sprendimą, o ne simptomą. Sprendimui tik per tunelį leiskite 53 tunelio sąsajoje, stumkite vidinį resolverį kartu su tunelio konfigūracija ir palikite fizinę jungtį be jokio DNS leidimo. wg-quick atveju resolverį į sąsajos konfigūraciją įrašo eilutėDNS =, tad tunelis, kuris jos neįtraukia, palieka seną resolverį vietoje, ir kiekviena užklausa eina netinkamu keliu.wg-quick vadovasdokumentuoja tą elgseną kiekvienai platformai.
Tada patikrinkite šia tvarka. Linuxeresolvectl statusrodo aktyvią jungtį,dig +short example.comtikrina viešą vardą,dig @10.8.0.1 internal.example.comtikrina privatų, osudo tcpdump -ni any port 53rodo, kurią sąsają naudoja paketai, kol vykdote abu. WindowsGet-DnsClientServerAddress -AddressFamily IPv4irResolve-DnsName example.compateikia tuos pačius du faktus: kas sukonfigūruotas ir kas atsako.
Užbaikite neigiamu testu. Atjunkite tunelį, patvirtinkite, kad naujas viešas vardas nepavyksta, patvirtinkite, kad privatus vardas nepavyksta, irpatvirtinkite, kad nė vienas 53 prievado paketas nepaliko fizinio adapterio. Blokavimas, kuris laikosi tik podėlyje esančių atsakymų, visai nesilaiko.
Kontrolinis sąrašas prieš uždarant bilietą:
- Avarijos metu naudotas resolveris yra tas, kurį numato politika.
- Kliento paieška savo pabaigos taške vis dar leidžiama, per podėlį arba išimtį.
- DoH ir DoT arba patenka į blokavimą, arba politika juos išjungia.
- Privačios zonos nepavyksta uždarai, o ne atvirai, kai tunelio nebelieka.