Het die VPN my DNS verander? Vergelyk voor en ná

Jy maak die tonnel oop, maak ’n private paneel oop, en die naam los op na ’n adres wat jy nog nooit gesien het nie. Of die teenoorgestelde gebeur: die blaaier werk aan terwyl ’n opdragreëlprogram skielik niks oplos nie. Albei uitkomste kom uit dieselfde verandering, en mense verduidelik dit gewoonlik met een sin oor die VPN wat "sy eie DNS gebruik", wat nie presies genoeg is om te ontfout of te verifieer nie. Twee vrae steek in daardie sin: watter opsoektogte moet hierdie profiel oorneem, en het jou masjien dit werklik na die resolver gestuur wat aan hom gegee is? Om hulle apart te hou is die hele metode, want ’n toets wat hulle vermeng, lewer ’n selfversekerde verkeerde antwoord in albei rigtings.

Waarom ’n profiel hoegenaamd ’n resolver voorsien

Binne ’n tonnel los name agter die verre kant gewoonlik op na adresse wat net in daardie netwerk bestaan. ’n Private sone soos corp.internal het geen openbare delegering nie, so die resolver wat dit beantwoord, moet van binne die tonnel bereikbaar wees. Dieselfde meganisme dien ’n tweede doel: wanneer opsoektogte andersins deur jou ISP sou verlaat, hou ’n resolver aan die verre kant die navraag binne die geënkripteerde pad. Dis waarom die DNS-bedieneradres as deel van die verbinding se beleid kom eerder as as ’n globale instelling wat jy een keer vir die masjien gekies het.

Die adres op sigself beslis niks. ’n Resolver kan net antwoord as daar ’n roete na hom is, en die mees algemene faling is ’n resolver wat net bereikbaar is terwyl die tonnel op is. Wanneer die tonnel val en die beleid bly, gaan opsoektogte na ’n adres sonder ’n pad, en die simptoom is ’n tydverstryking eerder as ’n skoon fout. Daardie verskil maak saak wanneer jy die volgende toetsresultaat lees, want ’n tydverstryking stuur mense na vervoerinstellings wat nooit betrokke was nie.

Vergelyk die twee ontwerpe voordat jy antwoorde vergelyk

Volle tonnel en gesplete DNS lewer teenoorgestelde verwagtinge, en nie een is ’n fout nie. Onder ’n volle tonnel kan elke opsoektog na die verskaffer of na die korporatiewe resolver skuif, so openbare name wat ná verbinding anders antwoord, is verwag. Onder gesplete DNS gaan net gelyste domeine na die private resolver terwyl alles anders plaaslik bly; op Windows woon die domeinlys in die Name Resolution Policy Table, op macOS in die DNS-instellings se match domains, en op ’n systemd-resolved-gasheer in per-skakel routing domains.

Dit is die vergelyking om eerste te maak, want dit bepaal wat as ’n fout geld. Met gesplete DNS is ’n openbare naam wat van ’n nuwe resolver antwoord die ding werd om te ondersoek, terwyl ’n interne naam wat korrek antwoord die stelsel is wat sy werk doen. Met ’n volle tonnel is ’n openbare naam wat nog steeds van jou ISP-resolver antwoord die afwyking. Microsoft se dokumentasie oor VPN-naamresolusie beskryf die Windows-volgorde van hierdie reëls, insluitend hoe ’n passende beleidinskrywing voor die adapter se eie bedieners geraadpleeg word.

Daar is ’n derde resolver in die vertrek wat maklik is om te vergeet. Die blaaier se veilige DNS los name op sy eie op en kan aanhou antwoord nadat die tonnel die bedryfstelsel se beleid verander het, so ’n bladsy wat laai bewys dat die blaaier se resolver gewerk het, nie dat die profiel toegepas is nie. As jy net vergelyk wat die blaaier wys, toets jy die helfte van die tyd die verkeerde laag.

Teken ’n basislyn aan met net een veranderlike

Verander die tonnel. Moenie ook die naam, die werktuig of die soek-agtervoegsel in dieselfde stap verander nie. Kies ’n naam wat jy mag navraag doen, let op watter toepassing jy gebruik het, en skryf óf die adres wat teruggekom het óf die presiese fout neer. Op Windows druk Get-DnsClientServerAddress -AddressFamily IPv4 die bedieners per adapter af en Get-DnsClientNrptPolicy druk die beleidinskrywings af; op Linux met systemd-resolved wys resolvectl status die DNS-bedieners en routeringsdomeine per skakel; op macOS druk scutil --dns die resolver-orde af wat die stelsel werklik gaan volg.

Verbind dan deur die kliënt se normale beheer en herhaal presies dieselfde opdragte. Hou die eerste uitset eerder as ’n herinnering daaraan, want die vergelyking is die hele punt en ’n tweede lesing wat ná ’n kasleëring geneem word, is al klaar ’n ander meting. As die basislyn met die blaaier voor geneem is en die ná-verbinding-loop in ’n terminaal gebeur, vergelyk jy twee resolvers, nie twee toestande van een resolver nie.

’n Eksplisiete navraag en ’n toepassingsoektog is verskillende toetse

Om een spesifieke bediener te vra, met nslookup name 10.20.0.1 of dig @10.20.0.1 name, bewys een enkele ding: dat die bediener wat jy genoem het antwoord wanneer jy dit kan bereik. Dit omseil die keuselogika heeltemal, so dit kan jou nie sê of die stelsel daardie bediener vir hierdie naam sou gekies het nie. Gebruik dit om te toets of die toegewysde resolver bereikbaar is, en moenie dit gebruik om beleid te toets nie.

’n Opsoektog deur die plaaslike resolver oefen wel keuse uit. resolvectl query name loop dieselfde routeringsdomein-reëls en rapporteer die protokol wat geantwoord het, Resolve-DnsName op Windows gaan deur die beleidstabel en die kliëntkas, en scutil --dns wys die ordening wat ’n opsoektog sou volg. Voer albei soorte uit, en hou hulle in aparte kolomme van jou notas. ’n Groen eksplisiete navraag langs ’n falende toepassingsoektog is ’n routerings- of keusefout, nie ’n resolver wat weier om te werk nie.

Kasleëring sit tussen jou en die antwoord. Die bedryfstelsel, die plaaslike stomp-resolver, die blaaier en negatiewe kasleëring hou almal resultate, so ’n opsoektog kan slaag sonder dat ’n enkele pakkie die masjien verlaat. Teken die resultaat aan voordat jy enigiets leegmaak: ipconfig /flushdns, resolvectl flush-caches, of sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder op macOS. Slaan die breë netwerkherstel op hierdie stadium oor, want dit vernietig die bewyse wat jy nog versamel.

Wat die verskil beteken

Vergelyk die twee rye wat jy aangeteken het en klassifiseer die verandering voordat jy ’n enkele instelling aanraak.

Een ry verdien klem. ’n Naam wat oplos is nie ’n diens wat werk nie, en DNS-sukses sê net dat ’n adres gevind is. Dit sê niks oor aanstuur, firewall-reëls of of jou rekening die diens hoegenaamd mag gebruik nie, so eindig deur die werklike toepassing te toets eerder as om te aanvaar die fout het vanself weggetrek.

Herstel die basislyn en verifieer dit

Ontkoppel deur die kliënt se eie beheer eerder as om die proses dood te maak, en lees dan dieselfde drie opdragte weer. Die bedieners per skakel, die beleidinskrywings en die antwoord vir jou toetsnaam moet terugkeer na die basislyn wat jy vroeër neergeskryf het. ’n Oorblywende beleidinskrywing ná ’n skoon ontkoppeling is ’n werklike gebrek werd om aan te teken, en dit is ook waarom handmatige wysigings aan ’n gegenereerde resolver-lêer ’n slegte gewoonte is: die lêer word herskryf en die wysiging verdwyn, of die wysiging oorleef en pen ’n resolver vas wat nie meer ’n roete het nie.

Werk hierdie lys een keer deur, in volgorde. Besluit watter ontwerp die profiel implementeer voordat jy enige resultaat beoordeel. Hou naam, werktuig en agtervoegsel vas oor die twee lopies. Skei die eksplisiete navraag van die toepassingsoektog. Lees die effektiewe beleid, nie net die antwoord nie. Leegmaak kasleëring laaste, nadat die vergelyking neergeskryf is. Verifieer met die werklike toepassing, herbegin dan een keer en bevestig dat die ontkoppelde toestand nog skoon is.