Kas VPN muutis minu DNS-i? Võrrelge enne ja pärast
Profiil võib teie päringuid meelega ümber suunata. Võrrelge resoluutori poliitikat ja tegelikku vastust enne VPN-i ühendamist ja pärast seda, hoides ühte muutujat.
Ühendate tunneli, avate privaatse armatuurlaua ja nimi laheneb aadressiks, mida te pole kunagi varem näinud. Või juhtub vastupidine: brauser töötab edasi, samal ajal kui käsureatööriist äkki ei lahenda midagi. Mõlemad tulemused pärinevad samast muudatusest ja inimesed selgitavad seda tavaliselt ühe lausega VPN-ist, mis "kasutab oma DNS-i", mis ei ole silumiseks ega kontrollimiseks piisavalt täpne. Selles lauses on peidetud kaks küsimust: millised päringud peaks see profiil üle võtma, ja kas teie masin saatis need tegelikult resoluutorile, mis talle anti? Nende lahus hoidmine on kogu meetod, sest test, mis need segab, annab mõlemas suunas enesekindla vale vastuse.
Miks profiil üldse resoluutori annab
Tunneli sees lahenevad kaugema otsa taga olevad nimed tavaliselt aadressideks, mis eksisteerivad ainult selles võrgus. Privaatsel tsoonil nagu corp.internal puudub avalik delegeerimine, seega peab seda teenindav resoluutor olema kättesaadav tunneli seest. Sama mehhanism teenib teist eesmärki: kui päringud muidu väljuksid teie teenusepakkuja kaudu, hoiab kaugemal pool olev resoluutor päringu krüpteeritud teekonnas. Seetõttu saabub DNS-serveri aadress ühenduse poliitika osana, mitte globaalse seadistusena, mille valisite masina jaoks üks kord.
Aadress iseenesest ei otsusta midagi. Resoluutor saab vastata ainult siis, kui sinna viib marsruut, ja kõige tavalisem rike on resoluutor, mis on kättesaadav ainult tunneli ajal. Kui tunnel katkeb ja poliitika jääb, lähevad päringud aadressile, millel pole teekonda, ja sümptomiks on ajalõpp, mitte puhas viga. See erinevus loeb järgmise testitulemuse lugemisel, sest ajalõpp suunab inimesi transpordiseadistustesse, mis polnud kunagi seotud.
Võrrelge kahte lahendust enne vastuste võrdlemist
Täistunnel ja jaotatud DNS annavad vastandlikud ootused ja kumbki pole rike. Täistunneli korral võib iga päring liikuda teenusepakkuja või ettevõtte resoluutori juurde, seega on ootuspärane, et avalikud nimed vastavad pärast ühendamist erinevalt. Jaotatud DNS-i korral lähevad ainult loetletud domeenid privaatsesse resoluutorisse, kõik muu jääb kohalikuks; Windowsis elab domeenide loend Name Resolution Policy Table'is, macOS-is DNS-i seadistuste sobivates domeenides ning systemd-resolved hostis lingipõhistes marsruutimisdomeenides.
Just see võrdlus tuleb teha esimesena, sest see otsustab, mida lugeda veaks. Jaotatud DNS-i puhul on avalik nimi, mis vastab uuest resoluutorist, see, mida tasub uurida, samal ajal kui sisemine nimi, mis vastab õigesti, on süsteem, mis teeb oma tööd. Täistunneli puhul on anomaalia avalik nimi, mis vastab endiselt teie teenusepakkuja resoluutorist. Microsofti dokumentatsioon VPN-i nimelahenduse kohta kirjeldab nende reeglite Windowsi järjestust, sealhulgas seda, kuidas sobivat poliitikakannet konsulteeritakse enne adapteri enda servereid.
Ruumis on ka kolmas resoluutor, mida on lihtne unustada. Brauseri turvaline DNS lahendab nimesid ise ja võib vastata ka pärast seda, kui tunnel muutis operatsioonisüsteemi poliitikat, seega laaduv lehekülg tõestab, et brauseri resoluutor töötas, mitte et profiil rakendati. Kui võrdlete ainult seda, mida brauser näitab, testite poole ajast vale kihti.
Registreerige lähtejoon ainult ühe muutujaga
Muutke tunnelit. Ärge muutke samas sammus ka nime, tööriista ega otsingusufiksit. Valige nimi, mida tohib pärida, märkige üles, millist rakendust kasutasite, ja kirjutage kas tagastunud aadress või täpne viga. Windowsis prindib Get-DnsClientServerAddress -AddressFamily IPv4 serverid iga adapteri kohta ja Get-DnsClientNrptPolicy prindib poliitikakanded; Linuxis systemd-resolvediga näitab resolvectl status DNS-servereid ja marsruutimisdomeene lingi kohta; macOS-is prindib scutil --dns resoluutorite järjestuse, mida süsteem tegelikult järgib.
Seejärel ühendage kliendi tavapäraste juhtelementide kaudu ja korrake täpselt samu käske. Hoidke esimene väljund alles, mitte mälestus sellest, sest võrdlus on kogu mõte ja teine lugemine pärast vahemälu tühjendamist on juba teine mõõtmine. Kui lähtejoon võeti brauser ees ja ühendamise järgne käivitus toimub terminalis, võrdlete kahte resoluutorit, mitte ühe resoluutori kahte olekut.
Otsene päring ja rakenduse otsing on erinevad testid
Ühe kindla serveri käest küsimine, kasutades nslookup name 10.20.0.1 või dig @10.20.0.1 name, tõestab üht asja: et nimetatud server vastab, kui selle juurde pääseb. See möödub valikuloogikast täielikult, seega ei saa see öelda, kas süsteem oleks selle serveri selle nime jaoks valinud. Kasutage seda kontrollimaks, kas määratud resoluutor on kättesaadav, ja ärge kasutage seda poliitika kontrollimiseks.
Kohaliku resoluutori kaudu tehtud otsing rakendab valikut tõesti. resolvectl query name läbib samad marsruutimisdomeeni reeglid ja teatab, milline protokoll vastas, Resolve-DnsName Windowsis käib läbi poliitikatabeli ja kliendi vahemälu, ning scutil --dns näitab järjekorda, mida otsing järgiks. Käivitage mõlemat tüüpi ja hoidke neid märkmetes eraldi veergudes. Õnnestunud otsene päring ebaõnnestunud rakenduse otsingu kõrval on marsruutimise või valiku probleem, mitte resoluutor, mis keeldub töötamast.
Vahemälu seisab teie ja vastuse vahel. Operatsioonisüsteem, kohalik stub-resoluutor, brauser ja negatiivne vahemälu hoiavad kõik tulemusi, seega võib otsing õnnestuda, ilma et ükski pakett masinast lahkuks. Registreerige tulemus enne millegi tühjendamist: ipconfig /flushdns, resolvectl flush-caches või sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder macOS-is. Jätke lai võrgu lähtestamine selles etapis vahele, sest see hävitab tõendid, mida te veel kogute.
Mida erinevus tähendab
Võrrelge kahte registreeritud rida ja klassifitseerige muudatus enne, kui puudutate ühtki seadistust.
| 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 |
Üks rida väärib rõhutamist. Nimi, mis laheneb, ei ole teenus, mis töötab, ja DNS-i õnnestumine ütleb ainult, et aadress leiti. See ei ütle midagi edastamise, tulemüürireeglite ega selle kohta, kas teie kontol on üldse lubatud teenust kasutada, seega lõpetage tegeliku rakenduse testimisega, selle asemel et eeldada, et rike taandus iseenesest.
Taastage lähtejoon ja kontrollige seda
Katkestage ühendus kliendi enda juhtelementidega, mitte protsessi tappes, ja lugege siis samad kolm käsku uuesti. Lingipõhised serverid, poliitikakanded ja teie testnime vastus peaksid naasma varem kirja pandud lähtjoonele. Pärast puhast katkestamist allesjäänud poliitikakanne on tõeline defekt, mida tasub registreerida, ja just seetõttu on loodud resoluutorifaili käsitsi muutmine halb harjumus: fail kirjutatakse üle ja muudatus kaob, või muudatus jääb püsima ja kinnitab resoluutori, millel pole enam marsruuti.
Käige see loend üks kord läbi, järjekorras. Otsustage, millist lahendust profiil rakendab, enne kui hindate ükskõik millist tulemust. Hoidke nimi, tööriist ja sufiks mõlemas käivituses fikseerituna. Eraldage otsene päring rakenduse otsingust. Lugege kehtivat poliitikat, mitte ainult vastust. Tühjendage vahemälud viimasena, pärast võrdluse kirjapanekut. Kontrollige tegeliku rakendusega, seejärel taaskäivitage üks kord ja kinnitage, et katkestatud olek on endiselt puhas.