Vai VPN mainīja manu DNS? Salīdziniet pirms un pēc
Profils var apzināti pārvietot jūsu vaicājumus. Salīdziniet risinātāja politiku un faktisko atbildi pirms VPN savienojuma un pēc tā, saglabājot vienu mainīgo.
Jūs pievienojat tuneli, atverat privātu paneli, un vārds tiek atrisināts uz adresi, kuru nekad neesat redzējis. Vai notiek pretējais: pārlūks turpina strādāt, bet komandrindas rīks pēkšņi neko neatrisina. Abi rezultāti nāk no tās pašas izmaiņas, un cilvēki to parasti izskaidro ar vienu teikumu par VPN, kas „izmanto savu DNS”, un tas nav pietiekami precīzi atkļūdošanai vai pārbaudei. Šajā teikumā slēpjas divi jautājumi: kurus vaicājumus šim profilam vajadzētu pārņemt, un vai jūsu mašīna tos tiešām nosūtīja tam risinātājam, kas tai tika dots? To šķiršana ir viss metode, jo tests, kas tos sajauc, abos virzienos sniedz pārliecinātu nepareizu atbildi.
Kāpēc profils vispār nodrošina risinātāju
Tuneļa iekšienē vārdi aiz tālā gala parasti tiek atrisināti uz adresēm, kas pastāv tikai šajā tīklā. Privātai zonai, piemēram, corp.internal, nav publiskas deleģēšanas, tāpēc to apkalpojošajam risinātājam jābūt sasniedzamam no tuneļa iekšienes. Tas pats mehānisms kalpo otram mērķim: kad vaicājumi citādi izietu caur jūsu pakalpojumu sniedzēju, tālajā pusē esošais risinātājs notur vaicājumu šifrētajā ceļā. Tāpēc DNS servera adrese nāk kā savienojuma politikas daļa, nevis kā globāls iestatījums, ko vienreiz izvēlējāties mašīnai.
Adrese pati par sevi neko neizlemj. Risinātājs var atbildēt tikai tad, ja uz to ir maršruts, un visbiežākā kļūda ir risinātājs, kas sasniedzams tikai kamēr tunelis ir uzcelts. Kad tunelis krīt un politika paliek, vaicājumi dodas uz adresi bez ceļa, un simptoms ir taimauts, nevis tīra kļūda. Šī atšķirība ir svarīga, lasot nākamo testa rezultātu, jo taimauts sūta cilvēkus uz transporta iestatījumiem, kas nekad nav bijuši saistīti.
Salīdziniet abus dizainus pirms atbilžu salīdzināšanas
Pilns tunelis un sadalītais DNS rada pretējas gaidas, un neviens nav darbības traucējums. Pilna tuneļa gadījumā katrs vaicājums var pārvietoties pie sniedzēja vai uz uzņēmuma risinātāju, tāpēc publisku vārdu atšķirīga atbilde pēc savienojuma ir gaidāma. Sadalītā DNS gadījumā tikai sarakstā esošie domēni dodas uz privāto risinātāju, bet viss pārējais paliek lokāls; Windows domēnu saraksts dzīvo Name Resolution Policy Table, macOS – DNS iestatījumu atbilstošajos domēnos, bet systemd-resolved saimniekā – katra savienojuma maršrutēšanas domēnos.
Šis ir pirmais salīdzinājums, kas jāveic, jo tas izlemj, kas tiek uzskatīts par defektu. Sadalītā DNS gadījumā publisks vārds, kas atbild no jauna risinātāja, ir tas, ko ir vērts izmeklēt, bet pareizi atbildošs iekšējais vārds ir sistēma, kas dara savu darbu. Pilna tuneļa gadījumā anomālija ir publisks vārds, kas joprojām atbild no jūsu sniedzēja risinātāja. Microsoft dokumentācija par VPN vārdu izšķiršanu apraksta šo noteikumu Windows secību, tostarp to, kā atbilstošs politikas ieraksts tiek apskatīts pirms paša adaptera serveriem.
Telpā ir arī trešais risinātājs, ko viegli aizmirst. Pārlūka drošais DNS pats izšķir vārdus un var turpināt atbildēt pēc tam, kad tunelis ir mainījis operētājsistēmas politiku, tāpēc ielādēta lapa pierāda, ka pārlūka risinātājs strādāja, nevis ka profils tika piemērots. Ja salīdzināt tikai to, ko rāda pārlūks, pusi laika pārbaudāt nepareizo slāni.
Reģistrējiet bāzes līniju ar vienu mainīgo
Mainiet tuneli. Nemainiet tajā pašā solī arī vārdu, rīku vai meklēšanas sufiksu. Izvēlieties vārdu, kuru drīkstat vaicāt, atzīmējiet, kuru lietojumprogrammu izmantojāt, un pierakstiet vai nu atgriezto adresi, vai precīzu kļūdu. Windows Get-DnsClientServerAddress -AddressFamily IPv4 izdrukā serverus katram adapterim, bet Get-DnsClientNrptPolicy – politikas ierakstus; Linux ar systemd-resolved resolvectl status parāda DNS serverus un maršrutēšanas domēnus katram savienojumam; macOS scutil --dns izdrukā risinātāju secību, ko sistēma faktiski ievēros.
Pēc tam pievienojieties ar parastajiem klienta vadības elementiem un atkārtojiet tieši tās pašas komandas. Saglabājiet pirmo izvadi, nevis atmiņu par to, jo salīdzinājums ir visa būtība, un otrs nolasījums pēc kešatmiņas notīrīšanas jau ir cits mērījums. Ja bāzes līnija tika ņemta ar pārlūku priekšplānā un palaišana pēc savienojuma notiek terminālī, jūs salīdzināt divus risinātājus, nevis divus viena risinātāja stāvokļus.
Skaidrs vaicājums un lietojumprogrammas meklēšana ir dažādi testi
Uzticēt vienam konkrētam serverim, izmantojot nslookup name 10.20.0.1 vai dig @10.20.0.1 name, pierāda vienu lietu: ka jūsu nosauktais serveris atbild, kad tam var piekļūt. Tas pilnībā apiet atlases loģiku, tāpēc nevar pateikt, vai sistēma būtu izvēlējusies šo serveri šim vārdam. Izmantojiet to, lai pārbaudītu, vai piešķirtais risinātājs ir sasniedzams, un neizmantojiet politikas pārbaudei.
Meklēšana caur vietējo risinātāju patiešām izmanto atlasi. resolvectl query name iet caur tiem pašiem maršrutēšanas domēnu noteikumiem un ziņo, kurš protokols atbildēja, Resolve-DnsName Windows iet caur politikas tabulu un klienta kešatmiņu, bet scutil --dns parāda secību, kurai meklēšana sekotu. Palaidiet abus veidus un glabājiet tos atsevišķās piezīmju kolonnās. Veiksmīgs skaidrs vaicājums blakus neveiksmīgai lietojumprogrammas meklēšanai ir maršrutēšanas vai atlases problēma, nevis risinātājs, kas atsakās strādāt.
Kešatmiņa stāv starp jums un atbildi. Operētājsistēma, vietējais stub risinātājs, pārlūks un negatīvā kešatmiņa visi glabā rezultātus, tāpēc meklēšana var izdoties, nevienam paketam neizejot no mašīnas. Reģistrējiet rezultātu pirms kaut ko notīrāt: ipconfig /flushdns, resolvectl flush-caches vai sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder macOS. Šajā posmā izlaidiet plašo tīkla atiestatīšanu, jo tā iznīcina pierādījumus, kurus vēl vācat.
Ko nozīmē atšķirība
Salīdziniet abas reģistrētās rindas un klasificējiet izmaiņas pirms pieskaraties kaut vienam iestatījumam.
| 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 rinda ir pelnījusi uzsvaru. Vārds, kas tiek atrisināts, nav strādājošs pakalpojums, un DNS panākums saka tikai to, ka adrese tika atrasta. Tas neko nesaka par pārsūtīšanu, ugunsmūra noteikumiem vai to, vai jūsu kontam vispār ir atļauts izmantot pakalpojumu, tāpēc pabeidziet ar īstās lietojumprogrammas pārbaudi, nevis pieņemot, ka kļūda pati atkāpās.
Atjaunojiet bāzes līniju un pārbaudiet to
Atvienojieties ar paša klienta vadības elementiem, nevis nogalinot procesu, un pēc tam vēlreiz nolasiet tās pašas trīs komandas. Serveri katram savienojumam, politikas ieraksti un jūsu testa vārda atbilde ir jāatgriežas pie iepriekš pierakstītās bāzes līnijas. Politikas ieraksts, kas palicis pēc tīras atvienošanas, ir īsts defekts, ko ir vērts reģistrēt, un tieši tāpēc ģenerēta risinātāja faila manuāla labošana ir slikts ieradums: fails tiek pārrakstīts un labojums pazūd, vai labojums paliek un piesprauž risinātāju, kuram vairs nav maršruta.
Izejiet šo sarakstu vienreiz, secīgi. Izlemiet, kuru dizainu profils īsteno, pirms vērtējat jebkuru rezultātu. Turiet vārdu, rīku un sufiksu fiksētus abās palaišanās reizēs. Atdaliet skaidro vaicājumu no lietojumprogrammas meklēšanas. Lasiet spēkā esošo politiku, ne tikai atbildi. Notīriet kešatmiņas pēdējās, kad salīdzinājums ir pierakstīts. Pārbaudiet ar īsto lietojumprogrammu, pēc tam vienreiz pārstartējiet un apstipriniet, ka atvienotais stāvoklis joprojām ir tīrs.