Zakaj nslookup prek VPN deluje, brskalnik pa ne

nslookup pošlje poizvedbo na strežnik, ki ga navedete, in natisne odgovor, zato lahko uspe, medtem ko vsak zavihek brskalnika ne uspe. Brskalnik prosi operacijski sistem za razrešitev, sistem pa pretehta razreševalnike po vmesniku, pravila politike razreševanja imen in omrežno lokacijo vmesnika. Nato lahko brskalnik doda še svoj šifrirani DNS. Tri različne poti, en simptom in tunel običajno ni pokvarjeni del.

Spodnja preverjanja sledijo tem potem od sistema navzven. Ne urejajte profila VPN, dokler ne veste, katera pot je odgovorila in katera ni uspela.

O odgovoru odločajo tri politike

Vsak vmesnik nosi svoj seznam razreševalnikov in iskalne pripone. Vmesnik VPN doda strežnike, medtem ko fizični vmesnik obdrži svoje, in sistem lahko vzame tistega, ki odgovori prvi, zato je iskanje lahko postreženo zunaj tunela, ne da bi to kdo izbral. Pravila tabele politike razreševanja imen lahko pošiljajo izbrane domene na izbrane strežnike, tako se split DNS običajno izraža v Windows. In odjemalec ali prehod VPN lahko potisneta naslov razreševalnika, ki obstaja le v zasebnem omrežju.

Ti trije delujejo drug na drugega na načine, ki se iz brskalnika zdijo samovoljni. Potisnjen razreševalnik na zasebnem naslovu brez poti skozi razdeljeni tunel povzroči, da se vsako iskanje ustavi in nato ne uspe. Pravilo politike, ki pokriva notranjo pripono in kaže na izklopljen strežnik, ustvari enako vidno napako kot manjkajoča pot. Iskalna pripona, ki manjka na vmesniku VPN, spremeni kratko ime v javno poizvedbo za napačno domeno. Vsak od njih potrebuje drugačno popravilo.

Zakaj brskalnik postavi drugo vprašanje

nslookup izda svojo poizvedbo strežniku, ki ga izbere, in ne sledi niti politiki imenskega prostora niti nastavitvi šifriranega DNS brskalnika. Zato ročna poizvedba na javni razreševalnik odgovori, medtem ko brskalnik sporoča, da stran ne obstaja. Primerjate dva programa, ne dveh stanj enega programa.

Prednost družine naslovov pojasnjuje zakasnitev, ne neuspeha. Brskalnik, ki v tunelu, ki prenaša le IPv4, najprej zahteva zapise IPv6, čaka na potek časovne omejitve, preden se umakne. Firefox je imel takšno prednost prav zato, njeno izključevanje pa je diagnostični korak, ne popravilo.

Preberite seznam razreševalnikov in pravila

V Windows izpišite, kar sistem drži, preden začnete teoretizirati. Get-DnsClientServerAddress prikazuje strežnike po vmesniku, Get-DnsClientNrptRule našteva pravila imenskega prostora, Resolve-DnsName pa odgovori na točno ime po sistemski poti. Primerjajte ta odgovor z neposredno poizvedbo na strežnik VPN po naslovu. Ko Resolve-DnsName ne uspe, neposredna poizvedba pa uspe, je osumljenec seznam razreševalnikov ali pravilo imenskega prostora.

Preverite tudi ime samo. Notranje kratko ime lahko potrebuje zasebno pripono, ki jo zagotavlja le vmesnik VPN, medtem ko se popolnoma kvalificirano ime dobro razreši. Opozorilo o potrdilu po uspešnem iskanju spada k drugi težavi.

Nedosegljivi potisnjeni razreševalnik

Prehod ali odjemalec lahko potisne naslov razreševalnika in ta naslov mora biti dosegljiv skozi tunel. V razdeljenem tunelu zasebni razpon, ki vsebuje razreševalnik, morda ni med vključenimi potmi, kar da iskanje, ki nikoli ne prejme odgovora. Potrdite, da pot obstaja, nato vprašajte točno ta naslov skozi tunel. To je neuspeh za napako domene v brskalniku, medtem ko javni razreševalnik še odgovarja.

Če je razreševalnik nedosegljiv, je popravilo pot ali vključeno podomrežje, ne drug strežnik DNS.

Šifrirani DNS obide celotno pot

Brskalniki z DNS-over-HTTPS sami razrešujejo imena prek povezave HTTPS do izbranega ponudnika. Ko je to vklopljeno, sta sistemski razreševalnik in pravila split DNS za ta iskanja popolnoma obidena, zato notranja imena v brskalniku ne uspejo, medtem ko jih operacijski sistem razreši pravilno. Zgodi se tudi obratno: notranja imena v brskalniku uspejo prek ponudnika, ki jih ne bi smel nikoli videti, in to je problem politike, ne povezljivosti.

Zavestno odločite, ali je šifrirani DNS dovoljen na upravljanih napravah, nato ga nastavite prek upravljalne površine brskalnika, da bo izbira vidna. Prepustitev posamezni preferenci ustvari floto, v kateri se isti VPN na vsakem prenosniku obnaša drugače.

Popravila, ki ustrezajo neuspehu

Če VPN potisne svoj razreševalnik, poskrbite, da tunel prenaša promet do njega in da je enaka nastavitev vidna na vmesnikih, ki sodelujejo pri razreševanju. Če lokalna mesta med povezavo prenehajo razreševati, dodajte izrecne izjeme imenskega prostora ali pogojnega posredovalnika, namesto da razreševalnik v celoti zamenjate. Če šifrirani DNS brskalnika obide politiko, je to nastavitev, ki jo je treba spremeniti. Nikoli ne dodajte javnega razreševalnika za popravilo notranjega imena: uhaja zasebne poizvedbe in imena ne razreši.

Nato ločite iskanje od povezave. Ime, ki se razreši na pravi naslov, a zavrne povezavo, je težava storitve, požarnega zidu ali potrdila, in spremembe DNS tega ne bodo odpravile.

Zapišite, katera pot je odgovorila, katera ni uspela in kaj ste spremenili. Naslednje poročilo o istem simptomu bo potem zahtevalo en ukaz namesto popoldneva.