VPN povezan, a imena ne delujejo: kje se DNS v resnici zlomi

Tunel je vzpostavljen, ikona zelena, vsak zavihek brskalnika pa poroča o napaki pri razreševanju imen. To sliko ustvarijo trije različni mehanizmi: razreševalnik je lahko nedosegljiv, odjemalec lahko sprašuje razreševalnik, ki ga niste pričakovali, ali pa odpovedo le zasebna imena. Ločite jih, preden karkoli spremenite v protokolu tunela, ker se vsak popravlja na drugem mestu. Vrstni red spodaj se začne z opažanji, ki te tri primere ločijo.

Kaj poizvedba v resnici potrebuje

Poizvedba potrebuje tri stvari: naslov razreševalnika, pot do tega naslova in odgovor, ki ustreza vprašanju. Vsaka lahko odpove sama, vidni simptom pa je ista stran, ki se ne naloži. Zato vam stran z napako ne pove skoraj ničesar, dokler ne veste, katera od treh se je zlomila.

Odjemalec svoj razreševalnik izve iz profila VPN, iz DHCP na tunelu ali iz lastne konfiguracije, in kateri vir zmaga, je odvisno od platforme. V sistemu Windows ipconfig /all izpiše strežnike DNS za vsak vmesnik, tako da vidite, ali je poslana vrednost res prispela. Poslana vrednost, ki ni nikoli prispela v operacijski sistem, je tiha in pogosta napaka. Preberite konfigurirano vrednost, preden se dotaknete profila.

Linux in macOS na isto vprašanje odgovarjata z drugimi ukazi, in odgovor si zasluži enako branje: resolvectl status in scutil --dns oba naštejeta strežnike po vmesniku. Primerjajte ta seznam z naslovom, za katerega profil trdi, da ga pošilja. Neskladje tukaj pojasni vse naprej, zato ga razrešite, preden preizkusite imena.

Preizkusite eno javno in eno zasebno ime

Vprašajte za običajno javno ime gostitelja in dokumentirano zasebno ime gostitelja z istega računalnika in zapišite, kateri strežnik je odgovoril na vsako. Če odpovedo oba, je pokvarjen razreševalnik ali njegova pot. Če odpove le zasebno ime, je razreševalnik odgovoril in vprašanje postane cona ali usmerjanje. Zaženite obe poizvedbi v razmaku ene minute, da razlike ne more pojasniti sprememba poti.

Držite notranja imena stran od javnih posnetkov zaslona in javnih razreševalnikov. Časovna omejitev in odgovor o neobstoječi domeni sta različni opažanji: prvo pravi, da se ni vrnilo nič, drugo, da je oblast odgovorila, da ime ne obstaja. Če ju obravnavate kot eno napako, pridete na napačno plast, opozorilo o potrdilu pa je spet tretja stvar, ne napaka DNS.

nslookup izpiše tako strežnik, ki ga je vprašal, kot prejeti odgovor, in to je natanko tisti par, ki ga potrebujete. Zaženite ga dvakrat v isti lupini in zapišite naslov, ki je odgovoril, ob vsakem odgovoru.

nslookup example.com
nslookup host.corp.example 10.20.30.53

Preverite, ali odjemalec res doseže ta strežnik

Zasebni razreševalnik, ki ga pošilja profil, je koristen le, če ga odjemalec doseže, medtem ko je tunel vzpostavljen. Naslov, ki je videti pravilen, a nima poti, povzroči časovno omejitev, povezano stanje tunela pa o tej poti ne pove ničesar. Preverjanje je iskanje poti, usmerjeno na sam razreševalnik, ne na končno točko VPN.

Vsaka platforma na to odgovori z eno vrstico, vmesnik, naveden v izhodu, pa je celoten odgovor. Če kaže na fizični vmesnik, medtem ko je razreševalnik za tunelom, profil ne pošilja predpone, ki bi ga pokrila.

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

V profilu razdeljenega tunela je lahko razreševalnik zunaj poslanih poti, kar je težava profila in ne strežnika. Primerjajte naslov razreševalnika s poslanimi predponami in potrdite, da ena od njih pokriva ta naslov. Isto neskladje pojasni, zakaj DNS deluje v enem omrežju in odpove v drugem z identičnim profilom.

Ne pozabite, da lahko brskalniki obidejo sistemski razreševalnik

Brskalnik z vklopljenim varnim DNS lahko pošilja poizvedbe po HTTPS ponudniku po lastni izbiri in popolnoma prezre razreševalnik operacijskega sistema. Takrat je sistem videti pravilen, medtem ko brskalnik odpove, ali obratno. To je vprašanje pravilnika za brskalnik, ne za tunel.

Preverite nastavitev varnega DNS v brskalniku in vse upravljane pravilnike, ki jo nadzirajo, nato preizkusite drugo aplikacijo ali brskalnik z nespremenjenim tunelom. Če odpove le ena aplikacija, popravek sodi v to aplikacijo. Zasebno okno ni čista primerjava, ker lahko v enem brskalniku privzeto onemogoči razširitve, v drugem pa ne, in nikoli ne obide upravljanega pravilnika. Namesto tega uporabite drug profil brskalnika ali drugo aplikacijo.

Izpraznite predpomnilnik in znova preizkusite resnično nalogo

Po popravku nastavitve izpraznite lokalni predpomnilnik razreševalnika, da stara odgovor ne preživi popravka. Kratka oživitev, ki ji sledi nova napaka, pomeni, da je vzrok še vedno tam, ne pa da je praznjenje spodletelo. Izberite vrstico, ki ustreza računalniku, na katerem ste, ker so trije predpomnilniki ločeni.

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

Nato ponovite prvotno nalogo namesto sintetične poizvedbe, ker je naloga tisto, kar uporabnika zanima. Znova se povežite enkrat, da ponovni preizkus pokrije stanje, v katerem bo uporabnik v resnici. Referenčna stran nslookup podjetja Microsoft je stran, ki jo velja obdržati za argumente poizvedbe.

Če imena odpovedo šele po prekinitvi, odjemalec ni obnovil prejšnje konfiguracije, kar je napaka življenjskega cikla za prijavo, ne strežnik DNS za zamenjavo. Delujoča poizvedba tudi ni preskus uhajanja, ker država izhoda ne pove, kateri razreševalnik je odgovoril.