Waarom een servernaam na dial-in naar zijn VPN-adres verwijst

Een kantoorfileserver antwoordt de hele ochtend op zijn LAN-adres, dan belt een externe gebruiker in en begint de naam in plaats daarvan naar een tunneladres te verwijzen. Er is niets met de hand in DNS bewerkt, en dat is de aanwijzing: het record is door de machine zelf gepubliceerd. Drie voorwaarden bepalen of u de registrar, het record of het beeld van de client repareert, en de verkeerde volgorde betekent dat het record na de volgende verbinding terugkomt.

Twee adressen, één naam, drie voorwaarden

Een Windows-server met meerdere interfaces kan een LAN-adres, een of meer dial-in-adressen en soms een tweede netwerkkaart hebben. Elke interface kan zijn eigen adressen in DNS registreren als dynamische registratie daarvoor is toegestaan. Wanneer de PPP-adapter registreert, krijgt dezelfde hostnaam een adres dat alleen de tunnelpartner kan bereiken, en LAN-clients ontvangen het als een geldig antwoord.

Drie voorwaarden bepalen de reparatie. Ten eerste, is het extra adres bereikbaar vanaf de clients die het ontvangen? Ten tweede, is er nog een gebruiker afhankelijk van die registratie? Ten derde, is het record dynamisch en dus in staat terug te komen, of statisch en dus een bewuste vermelding?

Beantwoord dat voordat u iets aanraakt. Als het adres niet bereikbaar is vanaf het netwerk dat navraagt, lost het leegmaken van de clientcache het niet lang op. Als iets ervan afhankelijk is, zoals een beheerpad dat de tunnelpartners zelf gebruiken, breekt verwijderen in plaats daarvan dat pad. En een dynamisch record dat wordt verwijderd zonder de uitgever aan te pakken, verschijnt bij de volgende registratiegebeurtenis weer.

Lees het record voordat u de registrar wijzigt

Vraag de exacte volledig gekwalificeerde naam op vanuit het netwerk dat het probleem meldt, en vergelijk de antwoorden met de werkelijke interfaces en luisteraars van de server. Dat één naam meerdere adressen teruggeeft is normaal; de vraag is of elk daarvan bruikbaar is voor de client die het ontvangt.

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

De eerste query gebruikt de lokale resolver, de tweede vraagt rechtstreeks aan een specifieke DNS-server en de derde doet hetzelfde vanuit PowerShell op Windows. Ze vergelijken scheidt een verouderde clientcache van een gezaghebbend antwoord. Als de directe query al het tunneladres teruggeeft, ligt het probleem in gepubliceerde gegevens en niet in lokale caching.

Noteer de tijdstempel van het record en of de DNS-console het als dynamisch toont. Dat ene kenmerk vertelt u welke van de drie voorwaarden hierboven van toepassing is, en het is het verschil tussen een opruiming van vijf minuten en een reparatie die blijft.

Repareer de uitgever of het record, maar weet welke

Als het record dynamisch en ongewenst is, is de blijvende oplossing te voorkomen dat die interface registreert. Windows biedt registratie-instellingen per interface, en de DNS-clientservice publiceert opnieuw bij de volgende verbinding of adreswijziging. Registratie uitschakelen voor de dial-in-adapter laat de registratie van de LAN-adapter intact, wat meestal is wat u wilt.

Wees voorzichtig met schakelaars die voor de hele machine gelden. Een algemene instelling die dynamische updates uitschakelt, beïnvloedt elke interface op die host, inclusief degene op wiens registratie andere clients vertrouwen. Op een domeincontroller geldt dezelfde voorzichtigheid met meer kracht, omdat de host ook servicelocatierecords kan bezitten waarvan clients voor aanmelding afhankelijk zijn.

Als het record statisch is, is het opzettelijk daar geplaatst en het gesprek is met degene die het heeft geplaatst. Een statisch record verwijderen omdat het vandaag onhandig is, verwijdert het enige bewijs waarom het bestaat. Verwijder in beide gevallen het verouderde antwoord pas nadat de uitgever is aangepakt, en noteer wat u hebt gewijzigd zodat de volgende persoon een bewuste vermelding van een ongeluk kan onderscheiden.

Verifieer vanuit het clientnetwerk dat faalde

Verificatie hoort op het netwerk dat het symptoom meldde, niet op de server. Leeg de cache van de clientresolver via het ondersteunde mechanisme en herhaal daarna de oorspronkelijke opzoeking en de oorspronkelijke serviceverbinding op naam.

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

De eerste opdracht leegt de Windows-resolvercache, en de tweede toont of de naam opnieuw in de cache staat en welk adres is opgeslagen. Een geslaagde verbinding van de server met zichzelf bewijst niets over een LAN-client, en het verwijderen van een route naar het ongewenste adres corrigeert niet wat DNS publiceert.

Herhaal ten slotte de gebeurtenis die het adres vroeger introduceerde: verbind de VPN-client opnieuw of vernieuw de dial-insessie. Controleer de gepubliceerde naam opnieuw na die levenscycluswijziging. Een reparatie die alleen tot de volgende verbinding standhoudt, was een opruiming en geen reparatie, en weten welke van de twee u hebt uitgevoerd is het verschil tussen het ticket sluiten en het volgende week heropenen.