Kort interne name misluk op VPN: die agtervoegsel wat jy nooit sien nie
’n Kort naam werk net omdat ’n soek-agtervoegsel dit voltooi. Vergelyk die volle naam en die kort een om ’n gaping in die agtervoegsel van ’n mislukking by die resolver te onderskei.
Die kort naam het in die kantoor gewerk en misluk op die VPN, terwyl die volle naam foutloos opgelos word. Niks is stukkend nie. ’n Kaal naam soos intranet is nie ’n volledige naam nie; die kliënt voeg ’n agtervoegsel uit sy soeklys by en vra vir die resultaat. As die VPN-profiel nie daardie agtervoegsel verskaf nie, hou die bekende kort vorm op om te bestaan.
Dit is die hele mite. DNS het nie gebreek nie, die soekbeleid het verander.
’n Kaal naam is nie ’n naam nie
Wanneer jy ’n enkele etiket tik, moet die resolver besluit waarvoor om te vra. Dit probeer die naam soos gegee, en voeg dan een vir een inskrywings uit die soeklys by totdat iets antwoord. Op Linux beheer resolv.conf daardie volgorde met die search- en ndots-instellings. Op Windows doen die agtervoegsellys en die naamresolusiebeleid dieselfde. Verwyder die agtervoegsel en die resolver het niks om by te voeg nie.
’n Werkende kort naam is dus bewys van ’n beleid, nie bewys van ’n gesonde DNS-bediener nie.
Wat die agtervoegsellys en die resolver-adres elkeen doen
Hierdie twee word voortdurend verwar. Die resolver-adres sê wie om te vra; die agtervoegsellys sê oor watter naam om te vra. ’n VPN kan vir jou ’n private resolver gee en geen agtervoegsel nie, of ’n agtervoegsel en die verkeerde resolver. Net een van daardie foute lyk soos ’n DNS-onderbreking.
Kontroleer hulle afsonderlik, want om die verkeerde een reg te maak mors ’n ondersteuningsvenster.
| What you see | Likely cause |
|---|---|
| Full name resolves, short name fails | Suffix or search list missing |
| Neither resolves | Resolver unreachable or wrong domain rule |
| Both resolve, resource fails | Route or service permission |
Drie simptome, drie verskillende eienaars.
Toets eers die volle naam
Vra vir die administrateur se gedokumenteerde volkwalifiseerde naam, nie ’n raaiskoot nie. ’n Werkende FQDN bewys dat die resolver bereikbaar is en dat die rekord bestaan, wat die helfte van die moontlike oorsake in een navraag uitskakel. Gebruik ’n hulpmiddel wat wys watter bediener geantwoord het, sodat jy nie ’n gekaste resultaat lees nie.
Hou die toets privaat. Om interne variante na ’n publieke resolver te stuur openbaar name en toets ’n beleid wat niemand bedoel het nie.
Waar die regstelling hoort
Korrigeer die eienaarprofiel of die bestuurstelsel wat dit genereer. ’n Handmatige wysiging aan die plaaslike resolver-konfigurasie verdwyn gewoonlik met die eerste herverbinding, of dit geld vir elke netwerk waarmee die masjien verbind, wat erger is.
Op Windows, inspekteer die effektiewe beleid eerder as die regmerkie wat jy onthou. Get-DnsClientNrptPolicy wys die naamresolusie-reëls wat werklik van krag is.
Op macOS druk scutil --dns die resolver-konfigurasie per omvang-koppelvlak uit, insluitend die soekdomeine wat die VPN gestoot het.
Op Linux, lees die search-lyn in /etc/resolv.conf, maar kyk of ’n VPN-kliënt dit herskryf het. As die lêer bestuur word, wysig die bron van waarheid eerder as die gerenderde lêer. ’n Verouderde search-lyn wat van ’n vorige netwerk oorgebly het, is ’n algemene oorsaak.
Wat om by die profiel te hou
Bewaar die gekorrigeerde volle naam, die agtervoegsellys en die resolver-adres langs die kliëntprofiel. Die volgende persoon wat rapporteer dat die intranet-webwerf af is, kan drie bekende waardes vergelyk in plaas daarvan om van ’n skoon bladsy te begin.
En as net die kort vorm misluk, sê dit in die kaartjie. Daardie sin spaar die resolver-span ’n middag.