VPN prijungtas, bet vardai nepavyksta: kur DNS iš tiesų lūžta

Tunelis pakeltas, piktograma žalia, o kiekviena naršyklės kortelė praneša apie vardų sprendimo gedimą. Šį vaizdą kuria trys skirtingi mechanizmai: sprendiklis gali būti nepasiekiamas, klientas gali klausti sprendiklio, kurio nesitikėjote, arba gali nepavykti tik privatiems vardams. Atskirkite juos prieš ką nors keisdami tunelio protokole, nes kiekvienas taisomas kitoje vietoje. Toliau pateikta tvarka prasideda nuo stebėjimų, kurie atskiria tris atvejus.

Ko užklausai iš tikrųjų reikia

Užklausai reikia trijų dalykų: sprendiklio adreso, maršruto iki to adreso ir atsakymo, kuris atitinka klausimą. Kiekvienas jų gali sugesti atskirai, o matomas simptomas yra tas pats puslapis, kuris neįkeliamas. Todėl klaidos puslapis beveik nieko nepasako, kol nežinote, kuris iš trijų lūžo.

Klientas savo sprendiklį sužino iš VPN profilio, iš DHCP tunelyje arba iš savo konfigūracijos, o kuri šaltinis laimi, priklauso nuo platformos. Windows sistemoje ipconfig /all išspausdina DNS serverius pagal adapterį, taigi matote, ar išsiųsta reikšmė tikrai atvyko. Išsiųsta reikšmė, kuri taip ir nepasiekė operacinės sistemos, yra tylus ir dažnas gedimas. Perskaitykite sukonfigūruotą reikšmę prieš liesdami profilį.

Linux ir macOS atsako į tą patį klausimą skirtingomis komandomis, o atsakymas vertas to paties skaitymo: resolvectl status ir scutil --dns abu išvardija serverius pagal sąsają. Palyginkite tą sąrašą su adresu, kurį profilis teigia siunčiąs. Nesutapimas čia paaiškina viską toliau, todėl išsiaiškinkite jį prieš testuodami vardus.

Išbandykite vieną viešą ir vieną privatų vardą

Užklauskite įprasto viešo pagrindinio kompiuterio vardo ir dokumentuoto privataus pagrindinio kompiuterio vardo iš tos pačios mašinos ir užrašykite, kuris serveris atsakė į kiekvieną. Jei abu nepavyksta, sprendiklis arba jo maršrutas sugedęs. Jei nepavyksta tik privatus vardas, sprendiklis atsakė, ir klausimas tampa zona arba maršrutizavimas. Vykdykite abi užklausas per minutę viena nuo kitos, kad maršruto pakeitimas negalėtų paaiškinti skirtumo.

Laikykite vidinius vardus atokiau nuo viešų ekrano kopijų ir viešų sprendiklių. Skirtukas laiko viršijimas ir atsakymas apie neegzistuojantį domeną yra skirtingi stebėjimai: pirmasis sako, kad nieko negrįžo, antrasis – kad valdžia atsakė, jog vardo nėra. Vertinant juos kaip vieną klaidą, patenkama į ne tą sluoksnį, o sertifikato įspėjimas vėl yra trečias dalykas, ne DNS gedimas.

nslookup išspausdina ir serverį, kurio buvo klausta, ir gautą atsakymą, ir tai yra būtent ta pora, kurios jums reikia. Paleiskite jį du kartus toje pačioje apvalkale ir šalia kiekvieno atsakymo užrašykite atsakiusį adresą.

nslookup example.com
nslookup host.corp.example 10.20.30.53

Patvirtinkite, kad klientas iš tikrųjų pasiekia tą serverį

Profilio siunčiamas privatus sprendiklis naudingas tik tada, kai klientas gali jį pasiekti, kai tunelis pakeltas. Teisingai atrodantis adresas be maršruto sukelia laiko viršijimą, o prijungta tunelio būsena nieko nesako apie tą maršrutą. Patikra yra maršruto paieška, nukreipta į patį sprendiklį, o ne į VPN galinį tašką.

Kiekviena platforma į tai atsako viena eilute, o išvestyje įvardyta sąsaja yra visas atsakymas. Jei ji rodo į fizinį adapterį, o sprendiklis yra už tunelio, profilis nesiunčia priešdėlio, kuris jį apimtų.

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

Padalinto tunelio profilyje sprendiklis gali būti už siunčiamų maršrutų, ir tai yra profilio, o ne serverio problema. Palyginkite sprendiklio adresą su siunčiamais priešdėliais ir patvirtinkite, kad vienas jų jį apima. Tas pats nesutapimas paaiškina, kodėl DNS veikia viename tinkle ir nepavyksta kitame su identišku profiliu.

Atminkite, kad naršyklės gali apeiti sistemos sprendiklį

Naršyklė su įjungtu saugiu DNS gali siųsti užklausas HTTPS ryšiu savo pasirinktam teikėjui ir visiškai nepaisyti operacinės sistemos sprendiklio. Tada sistema atrodo tvarkinga, o naršyklė nepavyksta, arba atvirkščiai. Tai naršyklės, o ne tunelio politikos klausimas.

Patikrinkite naršyklės saugaus DNS nuostatą ir bet kokią valdomą politiką, kuri ją kontroliuoja, tada išbandykite antrą programą arba naršyklę su nepakeistu tuneliu. Jei nepavyksta tik viena programa, taisymas priklauso tai programai. Privatus langas nėra švarus palyginimas, nes jis vienoje naršyklėje gali pagal numatytuosius nustatymus išjungti plėtinius, o kitoje ne, ir jis niekada neapeina valdomos politikos. Vietoj to naudokite antrą naršyklės profilį arba kitą programą.

Išvalykite podėlį ir dar kartą išbandykite tikrąją užduotį

Pataisę nuostatą, išvalykite vietinį sprendiklio podėlį, kad senas atsakymas nepergyventų taisymo. Trumpas atsigavimas ir vėl gedimas reiškia, kad priežastis vis dar yra, o ne kad valymas nepavyko. Pasirinkite eilutę, atitinkančią mašiną, kurioje esate, nes trys podėliai yra atskiri.

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

Tada pakartokite pirminę užduotį, o ne sintetinę užklausą, nes užduotis yra tai, kas rūpi naudotojui. Prisijunkite dar kartą, kad pakartotinis testas apimtų būseną, kurioje naudotojas iš tikrųjų bus. Microsoft nslookup nuoroda yra puslapis, kurį verta pasilikti užklausos argumentams.

Jei vardai nepavyksta tik po atsijungimo, klientas neatkūrė ankstesnės konfigūracijos, ir tai yra gyvavimo ciklo klaida, apie kurią reikia pranešti, o ne DNS serveris, kurį reikia pakeisti. Veikianti užklausa taip pat nėra nutekėjimo testas, nes išėjimo šalis nieko nepasako apie tai, kuris sprendiklis atsakė.