Hindi nagre-resolve ang DNS kapag hinarang ng kill switch ng VPN ang port 53
Maaaring sadyang harangin ng kill switch ang DNS. Ihambing ang pag-resolve sa loob lamang ng tunnel sa isang pagbubukod para sa lokal na resolver, at tukuyin kung aling layer ang tunay na nabigo.
Kapag ibinagsak ng kill switch ang tunnel, kasama nitong nawawala ang landas ng DNS, at ang resolver na natitira ay bihirang ang inaasahan mo. Dalawang disenyo ang humahawak sa sandaling iyon nang magkaiba: harangin ang bawat DNS packet na wala sa loob ng tunnel, o iwanang nakatayo ang isang resolver bilang pagbubukod. Pareho silang katanggaptanggap. Mula sa tab ng browser halos magkapareho ang sintomas, kaya ang unang gawain ay alamin kung aling disenyo ang talagang inilagay mo.
Hinahawakan ko ang pagkakaibang iyon sa harap ko dahil kabaligtaran ang pagwawasto sa bawat kaso. Kailangan ng isang disenyo ng mas malawak na pagbubukod, ang isa ay mas makitid. Ang manghula ay nagkakahalaga sa iyo ng privacy o ng isang hapon.
Dalawang disenyo ng DNS para sa iisang pagpalya
Itinuturing ng disenyo A ang resolver bilang isa pang serbisyo sa likod ng tunnel. Pinapayagan ng mga patakaran ng firewall ang UDP at TCP 53 sa interface ng tunnel lamang, at ang address na ibinibigay sa kliyente ay resolver sa loob ng tunnel. Kapag bumagsak ang tunnel, humihinto ang paghahanap, at iyon ang inaasahang resulta, hindi depekto.
Pinananatiling maabot ng disenyo B ang resolver sa lokal na network, kadalasan ang router sa 192.168.1.1 o ang stub ng operating system sa 127.0.0.53, sa dahilang hindi dapat mamatay ang pag-resolve ng pangalan kasama ng tunnel. Maginhawa ito sa LAN ng bahay kung saan nagre-resolve ang router para sa buong bahay. Sa Wi-Fi ng hotel o paliparan, ang parehong pagbubukod ay tumuturo sa server ng iba, at bawat pangalang itinatype mo ay nabubunyag, kahit nananatiling hinarang ang trapiko mo sa web.
Ang hangganan ay kung kanino ang resolver. Kung nagtitiwala ka sa lokal, ang pagbubukod ay maliit at tapat na butas. Kung hindi, ang disenyong tunnel-lamang ang tanging naninindigan, at ang halaga ay dinadala ng bumagsak na tunnel ang lahat ng pangalan.
Bakit gumagana pa rin ang sariling paghahanap ng kliyente ng VPN
Kailangang i-resolve ng kliyente ang hostname ng gateway bago umiral ang tunnel, kaya hindi dapat sakupin ng mahigpit na pagharang ang bootstrap na landas ng kliyente. Karamihan sa mga kliyente ay nagka-cache ng address ng endpoint o nagbibigay ng dokumentadong pagbubukod sa bootstrap para sa nag-iisang host na iyon. Kung hinaharangan ng set ng patakaran mo ang paghahanap na iyon, hindi na babalik ang tunnel at ipapakita ng mga log ang kliyenteng hindi maabot ang sariling server, na depekto ng patakaran at hindi ng DNS.
Ang hinati na DNS ang isa pang lugar kung saan lumalabas ito. Itinutulak ng kliyente ang panloob na zone sa pribadong resolver at iniiwan ang lahat ng iba sa system resolver. Pagkatapos ng pagbagsak, maaaring mag-resolve pa ang mga pampublikong pangalan habang nag-time out ang mga panloob, dahil wala nang ruta ang pribadong zone. Para sa gumagamit iyon ay "sinira ng VPN ang internet"; para sa log ng resolver ito ay query na hindi kailanman dumating.
Sa ilalim ng systemd-resolved nakikita mo nang direkta ang paghahati. resolvectl status naglilista ng mga DNS server sa bawat link at ng mga routing domain, at pagkatapos bumaba ang tunnel, patuloy na tumuturo ang panloob na domain sa server sa link na wala na. Tumatanggap pa rin ang stub sa 127.0.0.53 ng query, pagkatapos ay naghihintay ng upstream na hindi sasagot, at iyon ang dahilan kung bakit tumatagal ng ilang segundo ang pagpalya sa halip na agad na bumalik.
Hindi nilalampasan ng naka-encrypt na DNS ang filter ng packet
Nagbibiyahe ang DNS over HTTPS at DNS over TLS sa 443 at 853, kaya ang patakarang humaharang sa port 53 ay walang sinabi tungkol sa kanila. Ang pagharang ng "DNS" ayon sa port ay patakaran tungkol sa port, hindi tungkol sa pag-resolve ng pangalan. Kung hinaharangan ng kill switch mo ang lahat ng trapiko sa labas ng tunnel, aksidenteng sakop ang DoH. Kung naglaan ka ng pagbubukod para sa captive portal o pampublikong resolver, hindi ito sakop.
Ang mga kontrol sa panig ng kliyente ang mas murang gamit. Binibitawan ng Firefox ang resolver nitong DoH kapag ang canary na pangalan use-application-dns.net ay hindi nag-resolve, at iyon ang dahilan kung bakit inilalathala ng mga pinamamahalaang network ang domain na iyon bilang NXDOMAIN; maaari ring i-pin ito ng patakaran ng enterprise na patay. May sariling switch at sariling default ang Android Private DNS at ang secure na DNS ng Chrome. Ang patayin ang mga iyon ay mas maaasahan kaysa habulin ang mga address ng resolver, dahil nagbabago ang listahan ng address at ang set ng patakaran mo ay hindi.
May bersyon nito na hindi tungkol sa pagtagas sa anumang paraan. Kailangan pa rin ng aplikasyong may naka-pin na resolver ng landas ng network para maabot ito. Binabago ng encryption kung sino ang makababasa ng query, hindi kung makakalabas ang packet sa makina, kaya natalo ng pagharang sa buong device ang setting nang hindi ito hinahawakan.
Itugma ang sintomas sa layer
Karamihan sa mga ulat ay dumarating bilang isang pangungusap, at kadalasan ay pinapangalanan na ng pangungusap na iyon ang layer. Ang talahanayan sa ibaba ang dinadaanan ko bago hawakan ang isang patakaran; ang layunin ay magpasya kung hinarang, nailihis, o hindi naipadala ang query.
| 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 |
Ang unang dalawang hilera ang madalas mali ang diagnosis ng mga tao. Ang tahimik na pagbagsak at pagtanggi ay parehong mukhang "sira ang DNS" sa browser, ngunit isa lamang sa kanila ang nangangahulugang ginagawa ng kill switch mo ang trabaho nito. Ang pagtanggi ay nangangahulugang may sumagot, kaya wala ang pagharang sa inaakala mong lugar.
Ibalik ang patakaran ng resolver, pagkatapos patunayan
Ayusin ang disenyo, hindi ang sintomas. Para sa pag-resolve sa tunnel lamang, payagan ang 53 sa interface ng tunnel, itulak ang panloob na resolver kasama ng configuration ng tunnel, at iwanan ang pisikal na link na walang anumang pahintulot sa DNS. Sa wg-quick, ang linyang DNS = ang nagsusulat ng resolver sa configuration ng interface, kaya ang tunnel na naglalaktaw dito ay iniiwan ang lumang resolver sa puwesto at lahat ng query ay sa maling landas. manwal ng wg-quick ang nagdodokumento ng gawi na iyon bawat platform.
Pagkatapos i-verify sa ganitong pagkakasunod-sunod. Sa Linux, resolvectl status ipinapakita ang aktibong link, dig +short example.com sinusubukan ang pampublikong pangalan, dig @10.8.0.1 internal.example.com sinusubukan ang pribado, at sudo tcpdump -ni any port 53 ipinapakita kung aling interface ang ginagamit ng mga packet habang pinapatakbo mo ang dalawa. Sa Windows, Get-DnsClientServerAddress -AddressFamily IPv4 at Resolve-DnsName example.com ay nagbibigay ng parehong dalawang katotohanan: sino ang naka-configure, at sino ang sumasagot.
Tapusin sa negatibong pagsubok. Idiskonekta ang tunnel, tiyakin na nabigo ang bagong pampublikong pangalan, tiyakin na nabigo ang pribadong pangalan, at tiyakin na walang packet ng port 53 na umalis sa pisikal na adapter. Ang pagharang na naninindigan lamang para sa mga naka-cache na sagot ay hindi naninindigan talaga.
Checklist bago isara ang ticket:
- Ang resolver na ginamit noong pagpalya ay ang sinadya ng patakaran.
- Pinapayagan pa rin ang sariling paghahanap ng endpoint ng kliyente, sa pamamagitan ng cache o pagbubukod.
- Ang DoH at DoT ay sakop ng pagharang o patay sa ilalim ng patakaran.
- Nabigo nang sarado ang mga pribadong zone, hindi bukas, kapag wala na ang tunnel.