VPN ferbûn, mar namme mislearje: wêr't DNS echt brekt

Tunnel oan, ikoan grien, en elk browser-tabblêd meldt in mislearring fan namme-oplossing. Trije ferskillende meganismen meitsje dat byld: de resolver kin net berikber wêze, de klant kin in resolver freegje dy't jo net ferwachte, of allinne de priveenammen kinne mislearje. Skied se foardat jo wat oan it tunnelprotokol feroarje, want elk wurdt op in oar plak reparearre. De folchoarder hjirûnder begjint mei de waarnimmingen dy't de trije skiede.

Wat in opsocht echt nedich hat

In opsocht hat trije dingen nedich: in resolver-adres, in rûte nei dat adres en in antwurd dat by de fraach past. Elk kin op himsels mislearje, en it sichtbere symptoom is deselde side dy't net laadt. Dêrom fertelt de flaterside jo hast neat oant jo witte hokker fan de trije brutsen is.

De klant leart syn resolver út it VPN-profyl, fan DHCP op 'e tunnel of út syn eigen konfiguraasje, en hokker boarne wint hinget fan it platfoarm ôf. Under Windows listet ipconfig /all de DNS-servers per adapter op, sadat jo sjen kinne oft de stjoerde wearde echt oankaam. In stjoerde wearde dy't nea it bestjoeringssysteem berikt hat, is in stil en faak foarkommend falen. Lês de konfigurearre wearde foardat jo it profyl oanreitsje.

Linux en macOS beantwurdzje deselde fraach mei oare opdrachten, en it antwurd fertsjinnet deselde lêzing: resolvectl status en scutil --dns beide listje de servers per ynterface. Ferlykje dy list mei it adres dat it profyl beweart te stjoeren. In ûnoerienstimming hjir ferklearret alles wat folget, dus regelje it foardat jo namme testen.

Test ien iepenbier en ien priveenamme

Freegje in gewoane iepenbiere hostnamme en de dokumintearre priveenamme fan itselde masine ôf, en skriuw op hokker server op elk antwurde. As beide mislearje, is de resolver of syn rûte brutsen. As allinne de priveenamme mislearret, hat de resolver antwurde en wurdt de fraach de sône of it rûtsjen. Fier de twa fragen binnen in minút fan inoar út, sadat in rûteferoaring it ferskil net ferklearje kin.

Hâld ynterne nammen bûten iepenbiere skermôfbilden en bûten iepenbiere resolvers. In tiidferrin en in antwurd oer in net-besteand domein binne ferskillende waarnimmingen: it earste seit dat der neat weromkaam, it twadde dat in autoriteit antwurde dat de namme net bestiet. As jo se as ien flater behannelje, komme jo op 'e ferkearde laach, en in sertifikaat-warskôging is wer in tredde ding, net in DNS-flater.

nslookup prints sawol de server dy't it frege hat as it antwurd dat it krige, en dat is krekt it pear dat jo nedich hawwe. Fier it twa kear yn deselde shell út en skriuw it antwurdzjende adres njonken elk antwurd.

nslookup example.com
nslookup host.corp.example 10.20.30.53

Befêstigje dat de klant dy server echt berikke kin

In priveeresolver dy't troch it profyl stjoerd wurdt, is allinne nuttich as de klant him berikke kin wylst de tunnel oan is. In adres dat der goed útsjocht sûnder rûte jout in tiidferrin, en de ferbûne steat fan 'e tunnel seit neat oer dy rûte. De kontrôle is in rûtesyk nei de resolver sels, net nei it VPN-einpunt.

Elk platfoarm beantwurdet dat yn ien rigel, en de ynterface neamd yn 'e útfier is it hiele antwurd. As it nei de fysike adapter wiist wylst de resolver efter de tunnel sit, stjoert it profyl gjin foarheaksel dat him dekt.

ip route get 10.20.30.53                      # Linux
route -n get 10.20.30.53                     # macOS
Find-NetRoute -RemoteIPAddress 10.20.30.53   # Windows PowerShell

By in split-tunnel-profyl kin de resolver bûten de stjoerde rûtes sitte, wat in profylprobleem is en gjin serverprobleem. Ferlykje it resolver-adres mei de stjoerde foarheaksels en befêstigje dat ien fan har him dekt. Deselde ûnoerienstimming ferklearret wêrom't DNS op ien netwurk wurket en op in oar mei in identyk profyl mislearret.

Tink derom dat browsers de systeemresolver omsile kinne

In browser mei feilige DNS oan kin fragen fia HTTPS nei in provider fan eigen kar stjoere en de resolver fan it bestjoeringssysteem hielendal negearje. Dan liket it systeem goed wylst de browser mislearret, of oarsom. Dat is in beliedsfraach foar de browser, net foar de tunnel.

Kontrolearje de feilige-DNS-ynstelling fan 'e browser en elk beheard belied dat dy regelet, en probearje dan in twadde applikaasje of browser mei de tunnel ûnferoare. As allinne ien applikaasje mislearret, heart de reparaasje by dy applikaasje. In priveefinster is gjin skjinne ferliking, want it kin ekstinsjes standert útskeakelje yn 'e iene browser en net yn 'e oare, en it omsilet nea beheard belied. Brûk ynstee in twadde browserprofyl of in oare applikaasje.

Liskje de cache en test de echte taak opnij

Nei't jo in ynstelling korrizjearre hawwe, liskje de lokale resolver-cache sadat in âld antwurd de reparaasje net oerlibbet. In koarte herstelling folge fan in nij falen betsjut dat de oarsaak der noch is, net dat it liskjen mislearre. Kies de rigel dy't by it masine past dêr't jo op sitte, want de trije caches binne apart.

ipconfig /flushdns                 # Windows
resolvectl flush-caches            # Linux
sudo killall -HUP mDNSResponder    # macOS

Werhelje dan de oarspronklike taak ynstee fan in syntetysk opsocht, want de taak is wat de brûker ynteressearret. Ferbynje jo ek ien kear opnij, sadat de werhelling de steat dekt wêryn't de brûker echt wêze sil. Microsoft syn nslookup-referinsje is de side om te hâlden foar de fraach-arguminten.

As nammen pas mislearje nei it ôfbrekken, hat de klant de foarige konfiguraasje net werombrocht, wat in libbenssyklusflater is om te melden ynstee fan in DNS-server om te ferfangen. In wurkjend opsocht is ek gjin lektest, want it útgeande lân fertelt jo neat oer hokker resolver antwurde.