Nakakonekta ang VPN pero nabibigo ang mga pangalan: saan talaga nasisira ang DNS

Nakaangat ang tunel, berde ang icon, at bawat tab ng browser ay nag-uulat ng bigong paglutas ng pangalan. Tatlong magkaibang mekanismo ang lumilikha ng larawang iyan: maaaring hindi maabot ang resolver, maaaring nagtatanong ang kliyente sa resolver na hindi mo inaasahan, o ang mga pribadong pangalan lang ang nabibigo. Paghiwalayin ang mga ito bago mo baguhin ang anuman sa protocol ng tunel, dahil bawat isa ay inaayos sa ibang lugar. Ang pagkakasunod-sunod sa ibaba ay nagsisimula sa mga obserbasyong naghihiwalay sa tatlo.

Ano talaga ang kailangan ng isang paghahanap

Ang isang paghahanap ay nangangailangan ng tatlong bagay: address ng resolver, daanan patungo sa address na iyon, at sagot na tugma sa tanong. Bawat isa ay maaaring mabigo nang mag-isa, at ang nakikitang sintomas ay ang parehong pahinang hindi naglo-load. Kaya halos walang sinasabi sa iyo ang pahina ng error hanggang malaman mo kung alin sa tatlo ang nasira.

Natututuhan ng kliyente ang resolver nito mula sa profile ng VPN, sa DHCP sa tunel, o sa sariling configuration, at kung aling pinagmulan ang mananalo ay depende sa platform. Sa Windows, ipconfig /all naglilista ng mga DNS server bawat adapter, kaya makikita mo kung talagang nakarating ang itinulak na halaga. Ang itinulak na halagang hindi kailanman nakarating sa operating system ay isang tahimik at karaniwang bigo. Basahin ang naka-configure na halaga bago hawakan ang profile.

Ang Linux at macOS ay sumasagot sa parehong tanong gamit ang magkaibang utos, at ang sagot ay karapat-dapat sa parehong pagbasa: resolvectl status at scutil --dns parehong naglilista ng mga server bawat interface. Ihambing ang listahang iyon sa address na sinasabi ng profile na itinutulak nito. Ang hindi pagtutugma rito ay nagpapaliwanag ng lahat sa ibaba, kaya ayusin ito bago subukan ang mga pangalan.

Subukan ang isang pampublikong at isang pribadong pangalan

Tanungin ang isang ordinaryong pampublikong hostname at ang dokumentadong pribadong hostname mula sa parehong makina, at itala kung aling server ang sumagot sa bawat isa. Kung parehong nabigo, sira ang resolver o ang daanan nito. Kung ang pribadong pangalan lang ang nabigo, sumagot ang resolver at ang tanong ay nagiging zone o routing. Patakbuhin ang dalawang query sa loob ng isang minuto upang hindi maipaliwanag ng pagbabago ng daanan ang pagkakaiba.

Ilayo ang mga panloob na pangalan sa mga pampublikong screenshot at sa mga pampublikong resolver. Ang timeout at ang sagot tungkol sa domain na wala ay magkaibang obserbasyon: sinasabi ng una na walang bumalik, sinasabi ng pangalawa na may awtoridad na sumagot na wala ang pangalan. Kung ituturing mong isang error ang dalawa, mapupunta ka sa maling layer, at ang babala ng certificate ay ikatlong bagay na naman, hindi bigo ng DNS.

nslookup ipinapakita ang server na tinanong at ang sagot na natanggap, at iyon mismo ang pares na kailangan mo. Patakbuhin ito nang dalawang beses sa parehong shell at isulat ang address na sumagot sa tabi ng bawat sagot.

nslookup example.com
nslookup host.corp.example 10.20.30.53

Tiyakin na talagang naaabot ng kliyente ang server na iyon

Ang pribadong resolver na itinutulak ng profile ay kapaki-pakinabang lamang kung maaabot ito ng kliyente habang nakaangat ang tunel. Ang address na mukhang tama nang walang daanan ay gumagawa ng timeout, at ang konektadong estado ng tunel ay walang sinasabi tungkol sa daanang iyon. Ang pagsusuri ay paghahanap ng daanan na nakatutok sa resolver mismo, hindi sa endpoint ng VPN.

Bawat platform ay sumasagot niyan sa isang linya, at ang interface na binanggit sa output ay ang buong sagot. Kung ito ay tumuturo sa pisikal na adapter habang ang resolver ay nasa likod ng tunel, hindi nagtutulak ang profile ng prefix na sumasaklaw dito.

ip route get 10.20.30.53                      # Linux
route -n get 10.20.30.53                     # macOS
Find-NetRoute -RemoteIPAddress 10.20.30.53   # Windows PowerShell

Sa profile ng split tunnel, ang resolver ay maaaring nasa labas ng mga itinulak na daanan, na problema ng profile at hindi ng server. Ihambing ang address ng resolver sa mga itinulak na prefix at tiyakin na sinasaklaw ito ng isa sa kanila. Ang parehong hindi pagtutugma ay nagpapaliwanag kung bakit gumagana ang DNS sa isang network at nabibigo sa iba na may katulad na profile.

Tandaan na maaaring laktawan ng mga browser ang resolver ng system

Ang browser na may naka-enable na secure DNS ay maaaring magpadala ng mga query sa HTTPS sa provider na sarili nitong pinili at lubos na balewalain ang resolver ng operating system. Kung gayon ang system ay mukhang tama habang nabibigo ang browser, o kabaliktaran. Iyon ay usapin ng patakaran para sa browser, hindi para sa tunel.

Suriin ang setting ng secure DNS ng browser at anumang pinamamahalaang patakaran na kumokontrol dito, pagkatapos ay subukan ang pangalawang aplikasyon o browser na hindi binago ang tunel. Kung isang aplikasyon lang ang nabigo, ang pagwawasto ay para sa aplikasyong iyon. Ang pribadong window ay hindi malinis na paghahambing, dahil maaaring i-disable nito ang mga extension bilang default sa isang browser at hindi sa iba, at hindi nito kailanman nilalaktawan ang pinamamahalaang patakaran. Gumamit na lang ng pangalawang profile ng browser o ibang aplikasyon.

I-clear ang cache at subukang muli ang tunay na gawain

Pagkatapos ayusin ang isang setting, i-clear ang lokal na cache ng resolver upang ang lumang sagot ay hindi mabuhay nang mas matagal kaysa sa pagwawasto. Ang maikling paggaling na sinusundan ng panibagong bigo ay nangangahulugang naroon pa rin ang dahilan, hindi na nabigo ang pag-clear. Piliin ang linyang tugma sa makinang ginagamit mo, dahil hiwalay ang tatlong cache.

ipconfig /flushdns                 # Windows
resolvectl flush-caches            # Linux
sudo killall -HUP mDNSResponder    # macOS

Pagkatapos ay ulitin ang orihinal na gawain sa halip na sintetikong paghahanap, dahil ang gawain ang mahalaga sa gumagamit. Kumonekta muli nang isang beses, upang masaklaw ng muling pagsubok ang estadong talagang mararanasan ng gumagamit. Ang sanggunian ng nslookup ng Microsoft ang pahinang dapat itago para sa mga argumento ng query.

Kung ang mga pangalan ay nabibigo lamang pagkatapos ng pagdiskonekta, hindi naibalik ng kliyente ang dating configuration, na bug sa lifecycle na dapat iulat, hindi DNS server na dapat palitan. Ang gumaganang paghahanap ay hindi rin pagsubok sa pagtagas, dahil walang sinasabi sa iyo ang bansang labasan kung aling resolver ang sumagot.