Hat de VPN myn DNS feroare? Ferlykje foar en nei
In profyl kin dyn opfragen mei opsetsin ferpleatse. Ferlykje it belied fan ’e resolver en it echte antwurd foar en nei’t in VPN ferbynt, wylst ien fariabele fêst bliuwt.
Do ferbynt de tunnel, do iepeneest in priveed dashboard, en de namme wurdt oplost nei in adres datst noch nea sjoen hast. Of it tsjinoerstelde bart: de browser bliuwt wurkjen wylst in kommandorigel-ark ynienen neat mear oplost. Beide útkomsten komme fan deselde feroaring, en minsken ferklearje it meastentiids mei ien sin oer de VPN dy’t "syn eigen DNS brûkt", wat net sekuer genôch is om te debuggen of te ferifiearjen. Twa fragen sitte ferburgen yn dy sin: hokker opfragen heart dit profyl oer te nimmen, en hat dyn masine dy echt nei de resolver stjoerd dy’t it krigen hat? Se los hâlde is de hiele metoade, want in test dy’t se mingt jout in selswis ferkeard antwurd yn beide rjochtingen.
Wêrom’t in profyl hielendal in resolver leveret
Binnen in tunnel wurde nammen efter it fiere ein meastentiids oplost nei adressen dy’t allinnich yn dat netwurk bestean. In privee sône lykas corp.internal hat gjin iepenbiere delegaasje, dus de resolver dy’t it beantwurdet moat fan binnen de tunnel berikber wêze. Deselde meganisme tsjinnet in twadde doel: as opfragen oars fia dyn provider fuortgean soene, hâldt in resolver oan ’e fiere kant de fraach binnen it fersifere paad. Dêrom komt it DNS-serveradres as diel fan it belied fan ’e ferbining en net as in globale ynstelling dy’tst ienris foar de masine keazen hast.
It adres allinnich beslút neat. In resolver kin allinnich antwurdzje as der in rûte nei ta is, en de meast foarkommende storing is in resolver dy’t allinnich berikber is salang’t de tunnel oan is. As de tunnel falt en it belied bliuwt, geane opfragen nei in adres sûnder paad, en it symptoom is in tiidferrin ynstee fan in skjinne flater. Dat ferskil is wichtich asst it folgjende testresultaat lêst, want in tiidferrin stjoert minsken nei transportynstellings dy’t nea belutsen wiene.
Ferlykje de twa ûntwerpen foar’tst antwurden ferlykest
Folle tunnel en splitst DNS jouwe tsjinoerstelde ferwachtingen, en gjin fan beide is in steuring. Under in folle tunnel kin elke opfraach nei de provider of nei de bedriuwsresolver ferpleatse, dus is it ferwachte dat iepenbiere nammen nei it ferbinen oars antwurdzje. Under splitst DNS geane allinnich de listige domeinen nei de priveeresolver wylst al it oare lokaal bliuwt; op Windows wennet de domeinlist yn ’e Name Resolution Policy Table, op macOS yn ’e byhearrende domeinen fan ’e DNS-ynstellings, en op in systemd-resolved-host yn ’e rûte-domeinen per keppeling.
Dat is de ferliking dy’t earst makke wurde moat, want it beslút wat as flater jildt. By splitst DNS is in iepenbiere namme dy’t fan in nije resolver antwurdet it ding dat ûndersyk wurdich is, wylst in ynterne namme dy’t korrekt antwurdet it systeem is dat syn wurk docht. By in folle tunnel is de anomalie in iepenbiere namme dy’t noch altyd fan ’e resolver fan dyn provider antwurdet. De dokumintaasje fan Microsoft oer VPN-nammeoplossing beskriuwt de Windows-oarder fan dizze regels, ynklusyf hoe’t in oerienkommende beliedsitem rieplachte wurdt foar’t de eigen servers fan ’e adapter.
Der is in tredde resolver yn ’e keamer dy’t maklik te ferjitten is. De feilige DNS fan ’e browser lost nammen sels op en kin trochgean mei antwurdzjen neidat de tunnel it belied fan it bestjoeringssysteem feroare hat, dus in side dy’t laden wurdt bewiist dat de resolver fan ’e browser wurke hat, net dat it profyl tapast is. Asst allinnich ferlykest wat de browser toant, testest de helte fan ’e tiid de ferkearde laach.
Registrearje in basisline mei mar ien fariabele
Feroarje de tunnel. Feroarje net tagelyk de namme, it ark of it syk-efterheaksel yn deselde stap. Kies in namme dy’tst freegje meist, notearje hokker applikaasje’tst brûkt hast, en skriuw of it adres dat weromkaam of de krekte flater del. Op Windows printsje Get-DnsClientServerAddress -AddressFamily IPv4 de servers per adapter en Get-DnsClientNrptPolicy de beliedsitems; op Linux mei systemd-resolved toant resolvectl status de DNS-servers en rûte-domeinen per keppeling; op macOS printsje scutil --dns de resolver-oarder dy’t it systeem echt folgje sil.
Ferbynt dan fia de normale kontrôles fan ’e klant en werhelje krekt deselde opdrachten. Hâld de earste útfier yn stee fan in oantinken dêroan, want de ferliking is it hiele punt en in twadde lêzing nei it leegjen fan ’e cache is al in oare mjitting. As de basisline nommen is mei de browser foaroan en de útfiering nei it ferbinen bart yn in terminal, ferlykest twa resolvers, net twa tastannen fan ien resolver.
In eksplisite opfraach en in applikaasjesyk binne ferskate tests
Ien bepaald server freegje, mei nslookup name 10.20.0.1 of dig @10.20.0.1 name, bewiist ien ding: dat de server dy’tst neamdest antwurdet asst der komme kinst. It giet folslein om ’e seleksjelogika hinne, dus it kin dy net fertelle oft it systeem dy server foar dizze namme keazen hie. Brûk it om te testen oft de tawiisde resolver berikber is, en brûk it net om belied te testen.
In syk fia de lokale resolver oefent wol seleksje út. resolvectl query name rint deselde rûte-domeinregels del en rapportearret hokker protokol antwurde, Resolve-DnsName op Windows giet fia de beliedstabel en de klantcache, en scutil --dns toant de oarder dy’t in syk folgje soe. Rin beide soarten en hâld se yn aparte kolommen fan dyn notysjes. In slagge eksplisite opfraach neist in mislearre applikaasjesyk is in rûte- of seleksjeprobleem, net in resolver dy’t wegeret te wurkjen.
De cache stiet tusken dy en it antwurd. It bestjoeringssysteem, de lokale stub-resolver, de browser en negative caching hâlde allegear resultaten, dus in syk kin slagje sûnder dat ien pakket de masine ferlit. Registrearje it resultaat foar’tst wat leegjest: ipconfig /flushdns, resolvectl flush-caches of sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder op macOS. Sla de brede netwurkweromset oer yn dizze faze, want it fernielt it bewiis datst noch sammelst.
Wat it ferskil betsjut
Ferlykje de twa rigen dy’tst registrearre hast en klassifisearje de feroaring foar’tst ien ynstelling oanreast.
| 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 |
Ien rige fertsjinnet klam. In namme dy’t oplost is gjin tsjinst dy’t wurket, en DNS-súkses seit allinnich dat der in adres fûn is. It seit neat oer trochstjoeren, firewallregels of oft dyn akkount de tsjinst hielendal brûke mei, dus einigje mei it testen fan ’e echte applikaasje ynstee fan oan te nimmen dat de storing fansels fuortgien is.
Weromset de basisline en ferifiearje dy
Ferbrek de ferbining fia de eigen kontrôles fan ’e klant ynstee fan it proses te deadzjen, en lês dan deselde trije opdrachten wer. De servers per keppeling, de beliedsitems en it antwurd foar dyn testnamme moatte weromkomme nei de basisline dy’tst earder opskreaud hast. In oerbleaun beliedsitem nei in skjinne ferbrekking is in echte defekt dat registrearje wurdich is, en dêrom binne hânmatige bewurkingen oan in generearre resolver-bestân in minne gewoante: it bestân wurdt oerskreaun en de bewurking ferdwynt, of de bewurking oerlibbet en pinet in resolver fêst dy’t gjin rûte mear hat.
Wurkje dizze list ien kear troch, yn oarder. Beslis hokker ûntwerp it profyl ymplemintearret foar’tst hokker resultaat dan ek beoardielest. Hâld namme, ark en efterheaksel fêst oer beide útfieringen. Skied de eksplisite opfraach fan ’e applikaasjesyk. Lês it effektive belied, net allinnich it antwurd. Leegje caches as lêste, neidat de ferliking opskreaun is. Ferifiearje mei de echte applikaasje, start dan ien kear opnij en befêstigje dat de ôfkoppele tastân noch skjin is.