Waarom ’n bedienernaam ná inbel na sy VPN-adres oplos

’n Kantoorlêerbediener antwoord die hele oggend op sy LAN-adres, dan bel ’n afstandgebruiker in en die naam begin eerder na ’n tonneladres oplos. Niks is met die hand in DNS gewysig nie, en dit is die leidraad: die rekord is deur die masjien self gepubliseer. Drie voorwaardes bepaal of jy die registreerder, die rekord of die kliënt se siening regmaak, en as jy die volgorde verkeerd kry, kom die rekord ná die volgende verbinding terug.

Twee adresse, een naam, drie voorwaardes

’n Windows-bediener met meer as een koppelvlak kan ’n LAN-adres, een of meer inbeladresse en soms ’n tweede netwerkkaart hê. Elke koppelvlak kan sy eie adresse in DNS registreer as dinamiese registrasie daarvoor toegelaat word. Wanneer die PPP-koppelvlak registreer, kry dieselfde gasheernaam ’n adres wat net die tonnelport kan bereik, en LAN-kliënte ontvang dit as ’n geldige antwoord.

Drie voorwaardes bepaal die herstel. Eerstens, is die ekstra adres bereikbaar vir die kliënte wat dit ontvang? Tweedens, is daar nog enige verbruiker wat van daardie registrasie afhanklik is? Derdens, is die rekord dinamies en dus in staat om terug te kom, of staties en dus ’n doelbewuste inskrywing?

Beantwoord dit voordat jy iets aanraak. As die adres onbereikbaar is vanaf die netwerk wat navraag doen, maak geen mate van kliëntkas skoonmaak dit vir lank reg nie. As iets daarvan afhanklik is, soos ’n bestuurspad wat die tonnelport self gebruik, breek die verwydering daardie pad eerder. En ’n dinamiese rekord wat verwyder word sonder om die uitgewer daarvan aan te spreek, sal by die volgende registrasiegebeurtenis weer verskyn.

Lees die rekord voordat jy die registreerder verander

Vra die presiese volledig gekwalifiseerde naam uit vanaf die netwerk wat die probleem rapporteer, en vergelyk die antwoorde met die bediener se werklike koppelvlakke en luisteraars. ’n Enkele naam wat verskeie adresse teruggee is normaal; die vraag is of elkeen daarvan bruikbaar is vir die kliënt wat dit ontvang.

dig +short files.corp.example A
dig @10.20.0.10 +short files.corp.example A
Resolve-DnsName files.corp.example -Server 10.20.0.10 -Type A

Die eerste navraag gebruik die plaaslike oplosser, die tweede vra ’n spesifieke DNS-bediener direk, en die derde doen dieselfde vanuit PowerShell op Windows. Deur hulle te vergelyk skei jy ’n verouderde kliëntkas van ’n gesaghebbende antwoord. As die direkte navraag reeds die tonneladres teruggee, is die probleem gepubliseerde data eerder as plaaslike kas.

Skryf die rekord se tydstempel neer en of die DNS-konsole dit as dinamies wys. Daardie enkele eienskap sê vir jou watter van die drie voorwaardes hierbo van toepassing is, en dit is die verskil tussen ’n opruiming van vyf minute en ’n herstel wat hou.

Maak die uitgewer reg, of maak die rekord reg, maar weet watter

As die rekord dinamies en ongewens is, is die blywende oplossing om daardie koppelvlak te keer om te registreer. Windows bied registrasie-instellings per koppelvlak, en die DNS-kliëntdiens publiseer weer by die volgende verbinding of adresverandering. Om registrasie vir die inbelkoppelvlak af te skakel, laat die LAN-koppelvlak se registrasie ongeskonde, wat gewoonlik is wat jy wil hê.

Wees versigtig met skakelaars wat vir die hele masjien geld. ’n Globale instelling wat dinamiese opdatering deaktiveer, raak elke koppelvlak op daardie gasheer, insluitend die een wie se registrasie ander kliënte vertrou. Op ’n domeinbeheerder geld dieselfde versigtigheid met meer krag, want die gasheer kan ook diensliggingsrekords besit waarvan kliënte vir aanmelding afhanklik is.

As die rekord staties is, is dit doelbewus daar geplaas en die gesprek is met diegene wat dit geplaas het. Om ’n statiese rekord te verwyder omdat dit vandag ongerieflik is, verwyder die enigste bewys van waarom dit bestaan. In beide gevalle, verwyder die verouderde antwoord eers nadat die uitgewer hanteer is, en teken aan wat jy verander het sodat die volgende persoon ’n doelbewuste inskrywing van ’n ongeluk kan onderskei.

Verifieer vanaf die kliëntnetwerk wat gefaal het

Verifikasie hoort op die netwerk wat die simptoom gerapporteer het, nie op die bediener nie. Maak die kliënt se oplosserkas skoon deur sy ondersteunde meganisme, en herhaal dan die oorspronklike opsoek en die oorspronklike diensverbinding by naam.

ipconfig /flushdns
ipconfig /displaydns | findstr /i files.corp.example

Die eerste opdrag maak die Windows-oplosserkas skoon, en die tweede wys of die naam weer gekas is en watter adres gestoor is. ’n Suksesvolle verbinding van die bediener na homself bewys niks oor ’n LAN-kliënt nie, en die verwydering van ’n roete na die ongewenste adres korrigeer nie wat DNS publiseer nie.

Herhaal laastens die gebeurtenis wat die adres vroeër ingebring het: verbind die VPN-kliënt weer, of hernu die inbelsessie. Kyk weer na die gepubliseerde naam ná daardie lewensiklusverandering. ’n Herstel wat net tot die volgende verbinding hou, was ’n opruiming, nie ’n regmaking nie, en om te weet watter een jy gedoen het, is die verskil tussen die kaartjie sluit en dit volgende week weer oopmaak.