VPN konektita, sed nomoj malsukcesas: kie DNS vere rompiĝas

Tunelo funkcias, ikono verda, kaj ĉiu retumila langeto raportas malsukceson de nomrezolucio. Tri malsamaj meĥanismoj produktas tiun bildon: la solvilo eble neatingeblas, la kliento eble demandas solvilon, kiun vi ne atendis, aŭ eble nur la privataj nomoj malsukcesas. Apartigu ilin antaŭ ol ŝanĝi ion en la tunela protokolo, ĉar ĉiu riparatas aliloke. La suba ordo komenciĝas per la observoj, kiuj apartigas la tri.

Kion serĉo vere bezonas

Serĉo bezonas tri aferojn: adreson de solvilo, itinero al tiu adreso, kaj respondo kongrua kun la demando. Ĉiu povas malsukcesi sole, kaj la videbla simptomo estas la sama paĝo, kiu ne ŝargiĝas. Tial la erarpaĝo preskaŭ nenion diras al vi, ĝis vi scias, kiu el la tri rompiĝis.

La kliento lernas sian solvilon el la VPN-profilo, el DHCP sur la tunelo aŭ el sia propra agordo, kaj kiu fonto venkas dependas de la platformo. En Windows, ipconfig /all listigas la DNS-servilojn por adaptilo, do vi povas vidi, ĉu la sendita valoro vere alvenis. Sendita valoro, kiu neniam atingis la operaciumon, estas silentema kaj ofta malsukceso. Legu la agorditan valoron antaŭ ol tuŝi la profilon.

Linux kaj macOS respondas la saman demandon per malsamaj komandoj, kaj la respondo meritas la saman legadon: resolvectl status kaj scutil --dns ambaŭ listigas la servilojn por interfaco. Komparu tiun liston kun la adreso, kiun la profilo asertas sendi. Miskongruo ĉi tie klarigas ĉion malsupren, do solvu ĝin antaŭ ol testi nomojn.

Testu unu publikan kaj unu privatan nomon

Demandu ordinaran publikan gastignomon kaj la dokumentitan privatan gastignomon el la sama maŝino, kaj notu, kiu servilo respondis al ĉiu. Se ambaŭ malsukcesas, la solvilo aŭ ĝia itinero estas rompitaj. Se nur la privata nomo malsukcesas, la solvilo respondis kaj la demando fariĝas la zono aŭ la enkursigado. Rulu la du demandojn ene de unu minuto unu de la alia, por ke itinera ŝanĝo ne povu klarigi la diferencon.

Tenu internajn nomojn ekster publikaj ekrankopioj kaj ekster publikaj solviloj. Tempolimo kaj respondo pri neekzistanta domajno estas malsamaj observoj: la unua diras, ke nenio revenis, la dua, ke aŭtoritato respondis, ke la nomo ne ekzistas. Trakti ilin kiel unu eraron sendas vin al la malŝtupo, kaj atentigo pri atestilo estas denove tria afero, ne DNS-malsukceso.

nslookup presas kaj la servilon, kiun ĝi demandis, kaj la ricevitan respondon, kaj tio estas ĝuste la paro, kiun vi bezonas. Rulu ĝin dufoje en la sama ŝelo kaj skribu la respondintan adreson apud ĉiu respondo.

nslookup example.com
nslookup host.corp.example 10.20.30.53

Konfirmu, ke la kliento vere povas atingi tiun servilon

Privata solvilo sendita de la profilo utilas nur se la kliento povas atingi ĝin dum la tunelo funkcias. Adreso, kiu aspektas ĝusta sen itinero, produktas tempolimon, kaj la konektita stato de la tunelo diras nenion pri tiu itinero. La kontrolo estas itinera serĉo direktita al la solvilo mem, ne al la VPN-finpunkto.

Ĉiu platformo respondas tion per unu linio, kaj la interfaco menciita en la eligo estas la tuta respondo. Se ĝi montras al la fizika adaptilo dum la solvilo sidas malantaŭ la tunelo, la profilo ne sendas prefikson, kiu kovras ĝin.

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

Ĉe disigita tunela profilo la solvilo povas sidi ekster la senditaj itineroj, kio estas profila problemo, ne servila. Komparu la solvilan adreson kun la senditaj prefiksoj kaj konfirmu, ke unu el ili kovras ĝin. La sama miskongruo klarigas, kial DNS funkcias en unu reto kaj malsukcesas en alia kun identa profilo.

Memoru, ke retumiloj povas preterpasi la sisteman solvilon

Retumilo kun ŝaltita sekura DNS povas sendi demandojn per HTTPS al provizanto laŭ sia elekto kaj tute ignori la solvilon de la operaciumo. Tiam la sistemo aspektas ĝusta dum la retumilo malsukcesas, aŭ inverse. Tio estas politika demando por la retumilo, ne por la tunelo.

Kontrolu la sekuran DNS-agordon de la retumilo kaj ajnan administritan politikon, kiu regas ĝin, poste provu duan aplikaĵon aŭ retumilon kun la tunelo senŝanĝa. Se nur unu aplikaĵo malsukcesas, la korekto apartenas al tiu aplikaĵo. Privata fenestro ne estas pura komparo, ĉar ĝi povas malŝalti kromprogramojn defaŭlte en unu retumilo kaj ne en alia, kaj ĝi neniam preterpasas administritan politikon. Uzu anstataŭe duan retumilan profilon aŭ alian aplikaĵon.

Malplenigu la kaŝmemoron kaj retestu la realan taskon

Post korekto de agordo, malplenigu la lokan kaŝmemoron de la solvilo, por ke malnova respondo ne postvivu la korekton. Mallonga resaniĝo sekvata de nova malsukceso signifas, ke la kaŭzo ankoraŭ ĉeestas, ne ke la malplenigo fiaskis. Elektu la linion, kiu kongruas kun la maŝino, sur kiu vi estas, ĉar la tri kaŝmemoroj estas apartaj.

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

Poste ripetu la originan taskon anstataŭ sinteza serĉo, ĉar la tasko estas tio, kio gravas al la uzanto. Rekonektiĝu unufoje, por ke la retesto kovru la staton, en kiu la uzanto vere estos. La nslookup-referenco de Microsoft estas la paĝo, kiun indas konservi por la demandaj argumentoj.

Se nomoj malsukcesas nur post malkonekto, la kliento ne restarigis la antaŭan agordon, kio estas ciklo-viva cimo raportinda, ne DNS-servilo anstataŭiginda. Funkcianta serĉo ankaŭ ne estas likotesto, ĉar la elira lando diras nenion pri tio, kiu solvilo respondis.