Drie uitgevers kunnen het VPN-adres van een domeincontroller in DNS zetten

Drie verschillende onderdelen op een domeincontroller met meerdere netwerkkaarten kunnen hetzelfde VPN-adres in DNS zetten, en ze falen onafhankelijk van elkaar. Vergelijk wat elk onderdeel publiceert in plaats van het selectievakje van de adapter te vertrouwen, dat er slechts één bestuurt. Het symptoom is in elk geval identiek: een client lost de naam op, ontvangt het tunneladres en kan de domeincontroller niet bereiken. Wie het heeft gepubliceerd bepaalt hoe u het stopt.

Eén instelling, één service en één rol; drie uitgevers, drie schakelaars.

Begin bij de record, niet bij het selectievakje

Vraag de volledige naam van de betrokken server op via de DNS-server die de clients werkelijk gebruiken, en noteer elk adres dat terugkomt. Leg elk teruggegeven adres naast de werkelijke LAN- en tunnelinterfaces van de server en naast de netwerken waarop de clients zitten. Een adres kan lokaal volkomen geldig en toch onbereikbaar zijn voor de clients die ertoe doen. Periodieke authenticatiefouten zijn een veelvoorkomend symptoom, omdat clients bij verschillende pogingen verschillende adressen ontvangen of kiezen.

Dat de machine haar eigen naam correct oplost, bewijst heel weinig. De test die ertoe doet, wordt vanaf de clientnetwerken uitgevoerd.

De adapter is slechts één uitgever

De TCP/IP-eigenschappen van de adapter bevatten een selectievakje om het adres van die verbinding te registreren, en het uitvinken brengt precies één uitgever tot zwijgen. Het stopt de andere niet, en daarom kan de record na een herstart terugkomen. Als de domeincontroller ook de DNS-service draait, heeft die service haar eigen luisterconfiguratie en haar eigen naamserverrecords. De richtlijnen van Microsoft voor omgevingen met meerdere netwerkkaarten behandelen het interfacegedrag, de DNS-service en Netlogon als afzonderlijke relevante uitgevers.

Drie schakelaars, drie eigenaren, en slechts één ervan staat op de eigenschappenpagina van de adapter.

De DNS-service heeft eigen adressen

Een DNS-server die de opdracht krijgt op een VPN-adres te luisteren, blijft het in zijn eigen records publiceren, wat het selectievakje van de adapter ook beweert. Lijn de luisteradressen van de service uit met de bedoelde interfaces en bekijk tegelijk de naamservergegevens van de zone. Het wijzigen van luisteraars kan clients onderbreken die op dit moment een adres gebruiken dat u verwijdert, dus stel eerst vast wie van welke afhankelijk is. Een luisteraar verwijderen alleen omdat het een VPN-adres is, kan de clients afsnijden die u wilde helpen.

Netlogon, en het ontdekken van domeincontrollers in het algemeen, registreert ook adressen als onderdeel van zijn eigen taken. Onderdruk registraties niet domeinbreed en kopieer geen oude registratieoplossing voor externe toegang zonder te bevestigen dat die voor uw versie en rol geldt.

Eigendom vóór opruimen

Repareer de uitgever voordat u de record verwijdert, anders zet de volgende registratiegebeurtenis hem terug en herhaalt de oefening zich. Verwijder verouderde vermeldingen via het proces van de DNS-eigenaar en houd rekening met caching en veroudering. Controleer vanaf de clientnetwerken, inclusief domeinontdekking en de toepassing die oorspronkelijk faalde, en lok dan dezelfde VPN-gebeurtenis uit die het adres de eerste keer produceerde.

Wat u uiteindelijk wilt, is een bekende reeks gepubliceerde adressen en luisteraars, terwijl gewone domeinregistratie nog steeds zijn werk doet. Een machine waarvan de naam toevallig direct na handmatig opruimen correct wordt opgelost, is dat niet.

Noteer welke uitgever verantwoordelijk was, welke records zijn gewijzigd en welke clients zijn getest. De volgende server met meerdere netwerkkaarten heeft dezelfde drie verdachten.