VPN savienots, bet vārdi netiek atrisināti: kur DNS patiešām lūst

Tunelis ir uzcelts, ikona zaļa, un katra pārlūka cilne ziņo par vārdu atrisināšanas kļūmi. Šo ainu veido trīs dažādi mehānismi: atrisinātājs var būt nesasniedzams, klients var jautāt atrisinātājam, kuru negaidījāt, vai arī var neizdoties tikai privātie vārdi. Atdaliet tos pirms kaut kā maiņas tuneļa protokolā, jo katrs tiek labots citā vietā. Turpmākā secība sākas ar novērojumiem, kas atdala šos trīs.

Kas vaicājumam patiešām vajadzīgs

Vaicājumam vajadzīgas trīs lietas: atrisinātāja adrese, maršruts uz šo adresi un atbilde, kas atbilst jautājumam. Katra no tām var neizdoties atsevišķi, un redzamais simptoms ir tā pati lapa, kas neielādējas. Tāpēc kļūdas lapa gandrīz neko nepasaka, kamēr nezināt, kura no trim salūza.

Klients savu atrisinātāju uzzina no VPN profila, no DHCP tunelī vai no savas konfigurācijas, un tas, kurš avots uzvar, ir atkarīgs no platformas. Operētājsistēmā Windows ipconfig /all izdrukā DNS serverus katram adapterim, tāpēc redzat, vai nosūtītā vērtība tiešām ieradās. Nosūtīta vērtība, kas tā arī nesasniedza operētājsistēmu, ir klusa un bieža kļūme. Izlasiet konfigurēto vērtību pirms profila aiztikšanas.

Linux un macOS atbild uz to pašu jautājumu ar dažādām komandām, un atbilde ir pelnījusi to pašu lasīšanu: resolvectl status un scutil --dns abi uzskaita serverus pa saskarnēm. Salīdziniet šo sarakstu ar adresi, kuru profils apgalvo, ka sūta. Neatbilstība šeit izskaidro visu turpmāko, tāpēc nokārtojiet to pirms vārdu pārbaudes.

Pārbaudiet vienu publisku un vienu privātu vārdu

Pajautājiet parastu publisku resursdatora vārdu un dokumentēto privāto resursdatora vārdu no tās pašas mašīnas un pierakstiet, kurš serveris uz kurieni atbildēja. Ja neizdodas abi, atrisinātājs vai tā maršruts ir salūzis. Ja neizdodas tikai privātais vārds, atrisinātājs atbildēja, un jautājums kļūst par zonu vai maršrutēšanu. Izpildiet abus vaicājumus minūtes laikā vienu no otra, lai maršruta maiņa nevarētu izskaidrot atšķirību.

Turiet iekšējos vārdus ārpus publiskiem ekrānuzņēmumiem un publiskiem atrisinātājiem. Taimauts un atbilde par neesošu domēnu ir dažādi novērojumi: pirmais saka, ka nekas neatgriezās, otrais, ka autoritāte atbildēja, ka vārds neeksistē. Uztverot tos kā vienu kļūdu, jūs nonākat nepareizajā slānī, un sertifikāta brīdinājums atkal ir trešā lieta, nevis DNS kļūme.

nslookup izdrukā gan serveri, kuram jautāja, gan saņemto atbildi, un tas ir tieši tas pāris, kas jums vajadzīgs. Izpildiet to divreiz tajā pašā čaulā un pierakstiet atbildējušo adresi blakus katrai atbildei.

nslookup example.com
nslookup host.corp.example 10.20.30.53

Pārliecinieties, ka klients patiešām sasniedz šo serveri

Profila nosūtītais privātais atrisinātājs ir noderīgs tikai tad, ja klients to sasniedz, kamēr tunelis ir uzcelts. Pareizi izskatīga adrese bez maršruta rada taimautu, un tuneļa savienotais stāvoklis neko nepasaka par šo maršrutu. Pārbaude ir maršruta meklēšana, kas vērsta uz pašu atrisinātāju, nevis uz VPN galapunktu.

Katra platforma uz to atbild vienā rindā, un izvadē nosauktā saskarne ir visa atbilde. Ja tā norāda uz fizisko adapteri, kamēr atrisinātājs atrodas aiz tuneļa, profils nesūta prefiksu, kas to aptvertu.

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

Sadalīta tuneļa profilā atrisinātājs var atrasties ārpus nosūtītajiem maršrutiem, un tā ir profila, nevis servera problēma. Salīdziniet atrisinātāja adresi ar nosūtītajiem prefiksiem un apstipriniet, ka viens no tiem to aptver. Tā pati neatbilstība izskaidro, kāpēc DNS darbojas vienā tīklā un neizdodas citā ar identisku profilu.

Atcerieties, ka pārlūki var apiet sistēmas atrisinātāju

Pārlūks ar ieslēgtu drošo DNS var sūtīt vaicājumus pa HTTPS savam izvēlētam pakalpojumu sniedzējam un pilnībā ignorēt operētājsistēmas atrisinātāju. Tad sistēma izskatās kārtībā, kamēr pārlūks neizdodas, vai otrādi. Tas ir pārlūka, nevis tuneļa politikas jautājums.

Pārbaudiet pārlūka drošā DNS iestatījumu un jebkuru pārvaldīto politiku, kas to kontrolē, pēc tam izmēģiniet otru lietotni vai pārlūku ar nemainītu tuneli. Ja neizdodas tikai viena lietotne, labojums pieder šai lietotnei. Privāts logs nav tīrs salīdzinājums, jo tas vienā pārlūkā var pēc noklusējuma atspējot paplašinājumus, bet citā ne, un tas nekad neapiet pārvaldīto politiku. Tā vietā izmantojiet otru pārlūka profilu vai citu lietotni.

Iztīriet kešatmiņu un vēlreiz pārbaudiet īsto uzdevumu

Pēc iestatījuma labošanas iztīriet vietējo atrisinātāja kešatmiņu, lai vecā atbilde nepārdzīvotu labojumu. Īslaicīga atjaunošanās un pēc tam atkal kļūme nozīmē, ka cēlonis joprojām pastāv, nevis ka tīrīšana neizdevās. Izvēlieties rindu, kas atbilst mašīnai, uz kuras esat, jo trīs kešatmiņas ir atsevišķas.

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

Pēc tam atkārtojiet sākotnējo uzdevumu, nevis sintētisku vaicājumu, jo uzdevums ir tas, kas lietotājam svarīgs. Arī vienreiz pievienojieties no jauna, lai atkārtotā pārbaude aptvertu stāvokli, kādā lietotājs patiešām būs. Microsoft nslookup rokasgrāmata ir lapa, ko vērts paturēt vaicājuma argumentiem.

Ja vārdi neizdodas tikai pēc atvienošanās, klients neatjaunoja iepriekšējo konfigurāciju, un tā ir dzīves cikla kļūda, par kuru jāziņo, nevis DNS serveris, kas jāaizstāj. Strādājošs vaicājums arī nav noplūdes tests, jo izejas valsts neko nepasaka par to, kurš atrisinātājs atbildēja.