Ar VPN pakeitė mano DNS? Palyginkite prieš ir po
Profilis gali tyčia perkelti jūsų užklausas. Palyginkite rezolverio politiką ir tikrąjį atsakymą prieš VPN prisijungimą ir po jo, išlaikydami vieną kintamąjį.
Prisijungiate prie tunelio, atidarote privačią ataskaitų sritį, ir vardas išsprendžiamas į adresą, kurio niekada nematėte. Arba nutinka priešingai: naršyklė toliau veikia, o komandų eilutės įrankis staiga nieko neišsprendžia. Abu rezultatai kyla iš to paties pakeitimo, ir žmonės paprastai tai paaiškina vienu sakiniu apie VPN, kuris „naudoja savo DNS“, o to nepakanka taisymui ar patikrinimui. Tame sakinyje slypi du klausimai: kurias užklausas šis profilis turėtų perimti, ir ar jūsų mašina tikrai nusiuntė jas tam rezolveriui, kuris jai buvo duotas? Jų atskyrimas yra visas metodas, nes testas, kuris juos sumaišo, abiem kryptimis pateikia užtikrintai neteisingą atsakymą.
Kodėl profilis apskritai pateikia rezolverį
Tunelio viduje vardai už tolimo galo paprastai išsprendžiami į adresus, kurie egzistuoja tik tame tinkle. Privati zona, tokia kaip corp.internal, neturi viešo delegavimo, todėl ją aptarnaujantis rezolveris turi būti pasiekiamas iš tunelio vidaus. Tas pats mechanizmas tarnauja antram tikslui: kai užklausos kitu atveju išeitų per jūsų tiekėją, tolimosios pusės rezolveris laiko užklausą šifruotame kelyje. Todėl DNS serverio adresas ateina kaip prisijungimo politikos dalis, o ne kaip globalus nustatymas, kurį vieną kartą pasirinkote mašinai.
Adresas pats savaime nieko nenusprendžia. Rezolveris gali atsakyti tik tada, kai iki jo yra maršrutas, o dažniausia gedimas yra rezolveris, pasiekiamas tik kol tunelis pakeltas. Kai tunelis nukrinta, o politika lieka, užklausos eina į adresą be kelio, ir simptomas yra laiko limitas, o ne švari klaida. Šis skirtumas svarbus, kai skaitote kitą testo rezultatą, nes laiko limitas nukreipia žmones į transporto nustatymus, kurie niekada nebuvo susiję.
Palyginkite abu dizainus prieš lygindami atsakymus
Visas tunelis ir padalintas DNS sukuria priešingus lūkesčius, ir nė vienas nėra gedimas. Viso tunelio atveju kiekviena užklausa gali persikelti pas tiekėją arba į įmonės rezolverį, todėl viešų vardų kitoks atsakymas po prisijungimo yra tikėtinas. Padalinto DNS atveju tik sąraše esantys domenai eina į privatų rezolverį, o visa kita lieka vietoje; Windows sistemoje domenų sąrašas gyvena Name Resolution Policy Table, macOS – DNS nustatymų atitinkančiuose domenuose, o systemd-resolved serveryje – kiekvienos jungties maršrutizavimo domenuose.
Būtent šį palyginimą reikia atlikti pirmiausia, nes jis nusprendžia, kas laikoma defektu. Padalinto DNS atveju viešas vardas, atsakantis iš naujo rezolverio, yra tai, ką verta tirti, o teisingai atsakantis vidinis vardas yra sistema, kuri atlieka savo darbą. Viso tunelio atveju anomalija yra viešas vardas, kuris vis dar atsako iš jūsų tiekėjo rezolverio. Microsoft dokumentacija apie VPN vardų sprendimą aprašo šių taisyklių Windows tvarką, įskaitant tai, kaip atitinkantis politikos įrašas tikrinamas prieš paties adapterio serverius.
Kambaryje yra ir trečias rezolveris, kurį lengva pamiršti. Naršyklės saugus DNS pats sprendžia vardus ir gali toliau atsakinėti po to, kai tunelis pakeitė operacinės sistemos politiką, todėl įkelta puslapis įrodo, kad naršyklės rezolveris veikė, o ne kad profilis buvo pritaikytas. Jei lyginate tik tai, ką rodo naršyklė, pusę laiko tikrinate ne tą sluoksnį.
Užfiksuokite bazinę liniją su vienu kintamuoju
Pakeiskite tunelį. Nepakeiskite tame pačiame žingsnyje ir vardo, įrankio ar paieškos priesagos. Pasirinkite vardą, kurį leidžiama užklausti, pažymėkite, kurią programą naudojote, ir užrašykite arba grįžusį adresą, arba tikslią klaidą. Windows sistemoje Get-DnsClientServerAddress -AddressFamily IPv4 išspausdina serverius pagal adapterį, o Get-DnsClientNrptPolicy – politikos įrašus; Linux su systemd-resolved resolvectl status rodo DNS serverius ir maršrutizavimo domenus pagal jungtį; macOS scutil --dns išspausdina rezolverių tvarką, kurios sistema iš tikrųjų laikysis.
Tada prisijunkite per įprastus kliento valdiklius ir pakartokite lygiai tas pačias komandas. Išsaugokite pirmą išvestį, o ne prisiminimą apie ją, nes palyginimas yra esmė, o antrasis skaitymas po podėlio išvalymo jau yra kitas matavimas. Jei bazinė linija buvo paimta su naršykle priekyje, o paleidimas po prisijungimo vyksta terminale, lyginate du rezolverius, o ne dvi vieno rezolverio būsenas.
Aiškus užklausimas ir programos paieška yra skirtingi testai
Užklausti vieną konkretų serverį, naudojant nslookup name 10.20.0.1 arba dig @10.20.0.1 name, įrodo vieną dalyką: kad jūsų nurodytas serveris atsako, kai jį pasiekiate. Tai visiškai apeina pasirinkimo logiką, todėl negali pasakyti, ar sistema būtų pasirinkusi tą serverį šiam vardui. Naudokite tai, kad patikrintumėte, ar paskirtas rezolveris pasiekiamas, ir nenaudokite politikos tikrinimui.
Paieška per vietinį rezolverį tikrai išnaudoja pasirinkimą. resolvectl query name eina tomis pačiomis maršrutizavimo domenų taisyklėmis ir praneša, kuris protokolas atsakė, Resolve-DnsName Windows sistemoje eina per politikos lentelę ir kliento podėlį, o scutil --dns rodo tvarką, kurios laikytųsi paieška. Vykdykite abu tipus ir laikykite juos atskiruose savo užrašų stulpeliuose. Sėkmingas aiškus užklausimas šalia nepavykusios programos paieškos yra maršrutizavimo arba pasirinkimo problema, o ne rezolveris, atsisakantis dirbti.
Podėlis stovi tarp jūsų ir atsakymo. Operacinė sistema, vietinis stub rezolveris, naršyklė ir neigiamas podėlis visi laiko rezultatus, todėl paieška gali pavykti nė vienam paketui nepalikus mašinos. Užrašykite rezultatą prieš ką nors išvalydami: ipconfig /flushdns, resolvectl flush-caches arba sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder macOS. Šiame etape praleiskite platų tinklo atstatymą, nes jis sunaikina įrodymus, kuriuos dar renkate.
Ką reiškia skirtumas
Palyginkite dvi užrašytas eilutes ir klasifikuokite pakeitimą prieš paliesdami bent vieną nustatymą.
| Observation after connect | Most likely cause | Next step |
|---|---|---|
| Answer moves to a private address range | Expected under split DNS or a private zone | Confirm the suffix is in the effective policy, then test the service |
| Lookup times out while connected, works after disconnect | The assigned resolver has no route from this machine | Probe it with an explicit query, then re-read the policy |
| Internal name fails, public names work | Wrong namespace or a suffix missing from the policy | Query the fully qualified name and check the domain list per platform |
| Internal name returns a public address | Split DNS not applied; a public resolver answered | Check browser secure DNS first, then the per-link domain list |
Viena eilutė verta pabrėžimo. Vardas, kuris išsprendžiamas, nėra veikianti paslauga, o DNS sėkmė sako tik tai, kad adresas buvo rastas. Ji nieko nesako apie persiuntimą, užkardos taisykles ar tai, ar jūsų paskyra apskritai gali naudotis paslauga, todėl pabaikite išbandydami tikrąją programą, o ne manydami, kad gedimas pats pasitraukė.
Atkurkite bazinę liniją ir patikrinkite ją
Atsijunkite per paties kliento valdiklius, o ne žudydami procesą, tada dar kartą perskaitykite tas pačias tris komandas. Serveriai pagal jungtį, politikos įrašai ir jūsų testo vardo atsakymas turėtų grįžti į anksčiau užrašytą bazinę liniją. Politikos įrašas, likęs po švaraus atsijungimo, yra tikras defektas, kurį verta užrašyti, ir būtent todėl rankiniai generuoto rezolverio failo pakeitimai yra blogas įprotis: failas perrašomas ir pakeitimas dingsta, arba pakeitimas išlieka ir prisega rezolverį, kuris nebeturi maršruto.
Pereikite šį sąrašą vieną kartą, eilės tvarka. Nuspręskite, kokį dizainą profilis įgyvendina, prieš vertindami bet kurį rezultatą. Laikykite vardą, įrankį ir priesagą fiksuotus abiejuose paleidimuose. Atskirkite aiškų užklausimą nuo programos paieškos. Skaitykite galiojančią politiką, o ne tik atsakymą. Išvalykite podėlius paskiausiai, kai palyginimas jau užrašytas. Patikrinkite tikrąja programa, tada kartą paleiskite iš naujo ir patvirtinkite, kad atsijungimo būsena vis dar švari.