Kodėl nslookup išsprendžia per VPN, o naršyklė – ne

nslookup siunčia užklausą jūsų nurodytam serveriui ir išspausdina atsakymą, todėl jis gali pavykti, kai kiekviena naršyklės kortelė nepavyksta. Naršyklė prašo operacinės sistemos išspręsti, o sistema pasveria kiekvienos sąsajos resolverius, vardų sprendimo politikos taisykles ir adapterio tinklo vietą. Tada naršyklė gali pridėti savo šifruotą DNS. Trys skirtingi keliai, vienas simptomas, ir tunelis paprastai nėra sugedusi dalis.

Žemiau pateikti patikrinimai eina tais keliais nuo sistemos į išorę. Neredaguokite VPN profilio, kol nežinote, kuris kelias atsakė, o kuris nepavyko.

Atsakymą lemia trys politikos

Kiekviena sąsaja turi savo resolverių sąrašą ir paieškos priesagas. VPN adapteris prideda serverių, o fizinis adapteris laiko savus, ir sistema gali paimti tą, kuris atsakys pirmas, todėl paieška gali būti aptarnauta už tunelio ribų niekam to nesirenkant. Vardų sprendimo politikos lentelės taisyklės gali siųsti pasirinktus domenus pasirinktiems serveriams, taip paprastai išreiškiamas split DNS Windows aplinkoje. Ir VPN klientas ar šliuzas gali įstumti resolverio adresą, kuris egzistuoja tik privačiame tinkle.

Šie trys sąveikauja taip, kad iš naršyklės atrodo savavališkai. Įstumtas resolveris privačiu adresu be maršruto per split tunelį priverčia kiekvieną paiešką strigti ir tada nepavykti. Politikos taisyklė, apimanti vidinę priesagą ir nurodanti į išjungtą serverį, duoda tą pačią matomą klaidą kaip trūkstamas maršrutas. VPN adapteryje trūkstama paieškos priesaga paverčia trumpą vardą vieša užklausa neteisingam domenui. Kiekvienam reikia kitokio remonto.

Kodėl naršyklė užduoda kitą klausimą

nslookup siunčia savo užklausą pasirinktam serveriui ir nesivadovauja nei vardų erdvės politika, nei naršyklės šifruoto DNS nustatymu. Todėl rankinė užklausa viešam resolveriui atsako, o naršyklė praneša, kad svetainės nėra. Jūs lyginate dvi programas, o ne dvi vienos programos būsenas.

Adresų šeimos pirmenybė paaiškina vėlavimą, o ne nepavykimą. Naršyklė, kuri tunelyje, pernešančiame tik IPv4, pirmiausia prašo IPv6 įrašų, laukia laiko limito pabaigos, kol atsitraukia. Firefox turėjo būtent tam skirtą pirmenybę, o jos išjungimas yra diagnostinis žingsnis, o ne remontas.

Perskaitykite resolverių sąrašą ir taisykles

Windows aplinkoje išspausdinkite, ką sistema laiko, prieš teoretizuodami. Get-DnsClientServerAddress rodo serverius pagal sąsają, Get-DnsClientNrptRule išvardija vardų erdvės taisykles, o Resolve-DnsName atsako tikslų vardą sistemos keliu. Palyginkite šį atsakymą su tiesiogine užklausa VPN serveriui pagal adresą. Kai Resolve-DnsName nepavyksta, o tiesioginė užklausa pavyksta, įtariamasis yra resolverių sąrašas arba vardų erdvės taisyklė.

Patikrinkite ir patį vardą. Vidiniam trumpam vardui gali reikėti privačios priesagos, kurią teikia tik VPN adapteris, o visiškai kvalifikuotas vardas išsprendžiamas gerai. Sertifikato įspėjimas po sėkmingos paieškos priklauso kitai problemai.

Nepasiekiamas įstumtas resolveris

Šliuzas ar klientas gali įstumti resolverio adresą, ir šis adresas turi būti pasiekiamas per tunelį. Split tunelyje privatus diapazonas, kuriame yra resolveris, gali būti neįtrauktuose maršrutuose, todėl gaunama paieška, kuri niekada nesulaukia atsakymo. Patvirtinkite, kad maršrutas egzistuoja, tada užklauskite būtent tą adresą per tunelį. Tai nesėkmė, slypinti už domeno klaidos naršyklėje, kol viešas resolveris dar atsako.

Jei resolveris nepasiekiamas, remontas yra maršrutas arba įtrauktas potinklis, o ne kitas DNS serveris.

Šifruotas DNS apeina visą kelią

Naršyklės su DNS-over-HTTPS pačios išsprendžia vardus per HTTPS ryšį su pasirinktu teikėju. Kai tai įjungta, sistemos resolveris ir split DNS taisyklės tiems ieškojimams visiškai apeinami, todėl vidiniai vardai nepavyksta naršyklėje, o operacinė sistema juos išsprendžia teisingai. Būna ir atvirkščiai: vidiniai vardai pavyksta naršyklėje per teikėją, kuris niekada neturėjo jų matyti, ir tai yra politikos, o ne ryšio problema.

Sąmoningai nuspręskite, ar šifruotas DNS leidžiamas valdomuose įrenginiuose, tada sukonfigūruokite jį per naršyklės valdymo sąsają, kad pasirinkimas būtų matomas. Palikus tai asmeniniam pasirinkimui, susidaro parkas, kuriame tas pats VPN kiekviename nešiojamame kompiuteryje elgiasi skirtingai.

Remontas, atitinkantis nesėkmę

Jei VPN įstumia savo resolverį, užtikrinkite, kad tunelis neštų srautą į jį ir tas pats nustatymas būtų matomas adapteriuose, dalyvaujančiuose sprendime. Jei vietinės svetainės nustoja spręstis prisijungus, pridėkite aiškias vardų erdvės išimtis arba sąlyginį persiuntėją, o ne keiskite resolverį ištisai. Jei naršyklės šifruotas DNS apeina politiką, tai yra nustatymas, kurį reikia pakeisti. Niekada nepridėkite viešo resolverio vidiniam vardui taisyti: jis nutekina privačias užklausas ir neišsprendžia vardo.

Tada atskirkite paiešką nuo ryšio. Vardas, kuris išsprendžiamas į teisingą adresą, bet atsisako ryšio, yra paslaugos, užkardos ar sertifikato problema, ir DNS pakeitimai to nesutvarkys.

Užsirašykite, kuris kelias atsakė, kuris nepavyko ir ką pakeitėte. Tuomet kitas to paties simptomo pranešimas pareikalaus vienos komandos, o ne visos popietės.