Drei verschiedene Komponenten auf einem Domänencontroller mit mehreren Netzwerkkarten können dieselbe VPN-Adresse in DNS eintragen, und sie versagen unabhängig voneinander. Vergleichen Sie, was jede davon veröffentlicht, statt dem Kontrollkästchen des Adapters zu vertrauen, das nur eine davon steuert. Das Symptom ist in jedem Fall identisch: Ein Client löst den Namen auf, erhält die Tunneladresse und kann den Domänencontroller nicht erreichen. Wer den Eintrag veröffentlicht hat, entscheidet darüber, wie er zu stoppen ist.

Eine Einstellung, ein Dienst und eine Rolle; drei Veröffentlicher, drei Schalter.

Erst der Eintrag, dann das Kontrollkästchen

Fragen Sie den vollständigen Namen des betroffenen Servers über den DNS-Server ab, den die Clients tatsächlich verwenden, und notieren Sie jede zurückgegebene Adresse. Halten Sie jede zurückgegebene Adresse gegen die tatsächlichen LAN- und Tunnel-Schnittstellen des Servers und gegen die Netze, in denen die Clients sitzen. Eine Adresse kann lokal völlig gültig und für die relevanten Clients unerreichbar sein. Zeitweise auftretende Authentifizierungsfehler sind ein häufiges Symptom, weil Clients bei verschiedenen Versuchen unterschiedliche Adressen erhalten oder auswählen.

Dass die Maschine ihren eigenen Namen korrekt auflöst, beweist sehr wenig. Der entscheidende Test läuft aus den Client-Netzen.

Der Adapter ist nur eine der Stellen

Die TCP/IP-Eigenschaften des Adapters enthalten ein Kontrollkästchen, mit dem die Adresse dieser Verbindung registriert wird, und das Entfernen des Hakens stellt genau eine Stelle still. Die anderen stoppt es nicht, weshalb der Eintrag nach einem Neustart wieder auftauchen kann. Läuft auf dem Domänencontroller auch der DNS-Dienst, hat dieser Dienst seine eigene Lauschkonfiguration und seine eigenen Namensserver-Einträge. Microsofts Empfehlung für Umgebungen mit mehreren Netzwerkkarten behandelt das Schnittstellenverhalten, den DNS-Dienst und Netlogon als getrennte relevante Stellen.

Drei Schalter, drei Zuständigkeiten, und nur eine davon sitzt auf der Eigenschaftsseite des Adapters.

Der DNS-Dienst hat eigene Adressen

Ein DNS-Server, der angewiesen wurde, auf einer VPN-Adresse zu lauschen, veröffentlicht sie weiterhin in seinen eigenen Einträgen, unabhängig davon, was das Kontrollkästchen des Adapters behauptet. Bringen Sie die Lauschadressen des Dienstes mit den vorgesehenen Schnittstellen in Einklang und prüfen Sie gleichzeitig die Namensserver-Einträge der Zone. Änderungen an den Lauschadressen können Clients unterbrechen, die gerade eine Adresse nutzen, die Sie entfernen, klären Sie daher zuerst, wer von welcher abhängt. Eine Lauschadresse nur deshalb zu löschen, weil sie eine VPN-Adresse ist, kann die Clients abschneiden, denen Sie helfen wollten.

Netlogon und die Ermittlung von Domänencontrollern im Allgemeinen registrieren ebenfalls Adressen im Rahmen ihrer eigenen Aufgaben. Unterdrücken Sie Registrierungen nicht domänenweit, und kopieren Sie keinen alten Registrierungseingriff für den Fernzugriff, ohne zu prüfen, ob er für Ihre Version und Rolle gilt.

Zuständigkeit vor der Bereinigung

Beheben Sie die Ursache, bevor Sie den Eintrag entfernen, sonst setzt ihn das nächste Registrierungsereignis wieder ein, und die Übung beginnt von vorn. Entfernen Sie veraltete Einträge über den Prozess des DNS-Verantwortlichen und berücksichtigen Sie Caching und Alterung. Prüfen Sie aus den Client-Netzen, einschließlich Domänenermittlung und der Anwendung, die ursprünglich versagt hat, und lösen Sie dann dasselbe VPN-Ereignis aus, das die Adresse zuerst erzeugt hat.

Am Ende wollen Sie einen bekannten Satz veröffentlichter Adressen und Lauschadressen, während die alltägliche Domänenregistrierung weiterhin ihre Aufgabe erfüllt. Eine Maschine, deren Name zufällig direkt nach einer manuellen Bereinigung korrekt auflöst, ist das nicht.

Notieren Sie, welche Stelle verantwortlich war, welche Einträge geändert wurden und welche Clients getestet wurden. Der nächste Server mit mehreren Netzwerkkarten hat dieselben drei Verdächtigen.

Ähnliche Artikel