VPN verbind, maar name faal: waar DNS werklik breek

Tonnel aan, ikoon groen, en elke blaaier-oortjie rapporteer 'n mislukking in naamoplossing. Drie verskillende meganismes skep hierdie prentjie: die resolver is dalk onbereikbaar, die kliënt vra dalk 'n resolver wat jy nie verwag het nie, of net die private name misluk. Skei hulle voordat jy enigiets aan die tonnelprotokol verander, want elkeen word op 'n ander plek herstel. Die volgorde hieronder begin met die waarnemings wat die drie van mekaar skei.

Wat 'n opsoek werklik nodig het

'n Opsoek het drie dinge nodig: 'n resolver-adres, 'n roete na daardie adres en 'n antwoord wat by die vraag pas. Elkeen kan op sy eie misluk, en die sigbare simptoom is dieselfde bladsy wat nie laai nie. Daarom sê die foutbladsy byna niks vir jou voordat jy weet watter van die drie gebreek het.

Die kliënt leer sy resolver uit die VPN-profiel, uit DHCP op die tonnel of uit sy eie konfigurasie, en watter bron wen, hang van die platform af. Op Windows lys ipconfig /all die DNS-bediener per adapter, sodat jy kan sien of die gestuurde waarde werklik aangekom het. 'n Gestuurde waarde wat nooit die bedryfstelsel bereik het nie, is 'n stil en algemene fout. Lees die gekonfigureerde waarde voordat jy aan die profiel raak.

Linux en macOS antwoord dieselfde vraag met ander opdragte, en die antwoord verdien dieselfde lees: resolvectl status en scutil --dns lys albei die bedieners per koppelvlak. Vergelyk daardie lys met die adres wat die profiel beweer om te stuur. 'n Wanverhouding hier verduidelik alles stroomaf, so maak dit eers reg voordat jy name toets.

Toets een openbare en een private naam

Vra 'n gewone openbare gasheernaam en die gedokumenteerde private gasheernaam vanaf dieselfde masjien, en teken aan watter bediener elkeen beantwoord het. As albei misluk, is die resolver of sy roete stukkend. As net die private naam misluk, het die resolver geantwoord en word die vraag die sone of die roetering. Voer die twee navrae binne 'n minuut van mekaar uit, sodat 'n roeteverandering nie die verskil kan verduidelik nie.

Hou interne name uit openbare skermkiekies en uit openbare resolvers. 'n Tydverstreke en 'n antwoord van 'n nie-bestaande domein is verskillende waarnemings: die eerste sê niks het teruggekom, die tweede sê 'n gesag het geantwoord dat die naam nie bestaan nie. Om hulle as een fout te behandel, stuur jou na die verkeerde laag, en 'n sertifikaatwaarskuwing is weer 'n derde ding en nie 'n DNS-fout nie.

nslookup wys albei die bediener wat dit gevra het en die antwoord wat dit ontvang het, en dit is presies die paar wat jy nodig het. Voer dit twee keer in dieselfde dop uit en skryf die responderende adres langs elke antwoord.

nslookup example.com
nslookup host.corp.example 10.20.30.53

Bevestig dat die kliënt daardie bediener werklik kan bereik

'n Private resolver wat deur die profiel gestuur word, is net nuttig as die kliënt dit kan bereik terwyl die tonnel aan is. 'n Adres wat korrek lyk sonder 'n roete lewer 'n tydverstreke, en die verbinde toestand van die tonnel sê niks oor daardie roete nie. Die toets is 'n roetesoek gerig op die resolver self, nie op die VPN-eindpunt nie.

Elke platform antwoord dit in een reël, en die koppelvlak wat in die uitset genoem word, is die hele antwoord. As dit na die fisiese adapter wys terwyl die resolver agter die tonnel sit, stuur die profiel nie 'n voorvoegsel wat dit dek nie.

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

Op 'n split-tonnel-profiel kan die resolver buite die gestuurde roetes sit, wat 'n profielprobleem is eerder as 'n bedienerprobleem. Vergelyk die resolver-adres met die gestuurde voorvoegsels en bevestig dat een van hulle dit dek. Dieselfde wanverhouding verduidelik waarom DNS op een netwerk werk en op 'n ander met 'n identiese profiel misluk.

Onthou dat blaaiers die stelselresolver kan omseil

'n Blaaier met veilige DNS geaktiveer kan navrae per HTTPS na 'n verskaffer van sy eie keuse stuur en die bedryfstelsel se resolver heeltemal ignoreer. Dan lyk die stelsel korrek terwyl die blaaier misluk, of omgekeerd. Dit is 'n beleidsvraag vir die blaaier, nie vir die tonnel nie.

Kontroleer die blaaier se veilige-DNS-instelling en enige bestuurde beleid wat dit beheer, en probeer dan 'n tweede toepassing of blaaier met die tonnel onveranderd. As net een toepassing misluk, hoort die regstelling in daardie toepassing. 'n Privaat venster is nie 'n skoon vergelyking nie, want dit kan in een blaaier by verstek uitbreidings deaktiveer en in 'n ander nie, en dit omseil nooit bestuurde beleid nie. Gebruik eerder 'n tweede blaaierprofiel of 'n ander toepassing.

Leeg die kas en toets die werklike taak weer

Nadat jy 'n instelling reggemaak het, leeg die plaaslike resolver-kas sodat 'n ou antwoord nie die regstelling oorleef nie. 'n Kort herstel gevolg deur 'n volgende mislukking beteken die oorsaak is steeds daar, nie dat die leegmaak gefaal het nie. Kies die reël wat by die masjien pas waarop jy is, want die drie kasse is apart.

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

Herhaal dan die oorspronklike taak eerder as 'n sintetiese opsoek, want die taak is wat die gebruiker interesseer. Herverbind ook een keer, sodat die hertoets die toestand dek waarin die gebruiker werklik sal wees. Microsoft se nslookup-verwysing is die bladsy om te hou vir die navraagargumente.

As name eers ná ontkoppeling misluk, het die kliënt nie die vorige konfigurasie herstel nie, wat 'n lewensiklusfout is om aan te meld eerder as 'n DNS-bediener om te vervang. 'n Werkende opsoek is ook nie 'n lektoets nie, want die uitgangsland sê niks oor watter resolver geantwoord het nie.