Warum ein Servername nach dem Dial-in auf seine VPN-Adresse auflöst

Ein Dateiserver im Büro antwortet den ganzen Vormittag über seine LAN-Adresse, dann wählt sich ein Remote-Benutzer ein, und der Name wird stattdessen auf eine Tunneladresse aufgelöst. In DNS wurde nichts von Hand bearbeitet, und das ist der Hinweis: Der Eintrag wurde von der Maschine selbst veröffentlicht. Drei Bedingungen entscheiden, ob Sie den Registrar, den Eintrag oder die Sicht des Clients reparieren, und die falsche Reihenfolge bedeutet, dass der Eintrag nach der nächsten Verbindung zurückkehrt.

Zwei Adressen, ein Name, drei Bedingungen

Ein Windows-Server mit mehreren Schnittstellen kann eine LAN-Adresse, eine oder mehrere Dial-in-Adressen und manchmal eine zweite Netzwerkkarte besitzen. Jede Schnittstelle kann ihre eigenen Adressen in DNS registrieren, wenn die dynamische Registrierung für sie erlaubt ist. Wenn der PPP-Adapter registriert, erhält derselbe Hostname eine Adresse, die nur der Tunnelpartner erreichen kann, und LAN-Clients bekommen sie als gültige Antwort.

Drei Bedingungen entscheiden über die Reparatur. Erstens, ist die zusätzliche Adresse von den Clients erreichbar, die sie erhalten? Zweitens, hängt noch irgendein Nutzer von dieser Registrierung ab? Drittens, ist der Eintrag dynamisch und kann daher zurückkehren, oder statisch und daher ein bewusster Eintrag?

Beantworten Sie das, bevor Sie etwas anfassen. Ist die Adresse aus dem abfragenden Netz nicht erreichbar, hilft kein Leeren des Client-Caches für längere Zeit. Hängt etwas davon ab, etwa ein Verwaltungspfad, den die Tunnelpartner selbst nutzen, bricht das Entfernen stattdessen diesen Pfad. Und ein dynamischer Eintrag, der ohne Behandlung seines Herausgebers gelöscht wird, erscheint beim nächsten Registrierungsereignis wieder.

Lesen Sie den Eintrag, bevor Sie den Registrar ändern

Fragen Sie den genauen vollqualifizierten Namen aus dem Netz ab, das das Problem meldet, und vergleichen Sie die Antworten mit den tatsächlichen Schnittstellen und Listenern des Servers. Dass ein Name mehrere Adressen zurückgibt, ist normal; die Frage ist, ob jede davon für den Client nutzbar ist, der sie erhält.

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 erste Abfrage nutzt den lokalen Resolver, die zweite fragt direkt einen bestimmten DNS-Server, und die dritte tut dasselbe aus PowerShell unter Windows. Der Vergleich trennt einen veralteten Client-Cache von einer autoritativen Antwort. Liefert die direkte Abfrage bereits die Tunneladresse, liegt das Problem in veröffentlichten Daten und nicht im lokalen Caching.

Notieren Sie den Zeitstempel des Eintrags und ob die DNS-Konsole ihn als dynamisch anzeigt. Dieses eine Merkmal sagt Ihnen, welche der drei Bedingungen oben zutrifft, und es ist der Unterschied zwischen einer fünfminütigen Bereinigung und einer Reparatur, die hält.

Beheben Sie den Herausgeber oder den Eintrag, aber wissen Sie, welchen

Ist der Eintrag dynamisch und unerwünscht, ist die dauerhafte Lösung, diese Schnittstelle an der Registrierung zu hindern. Windows bietet Registrierungseinstellungen pro Schnittstelle, und der DNS-Clientsdienst veröffentlicht bei der nächsten Verbindung oder Adressänderung erneut. Wer die Registrierung für den Dial-in-Adapter abschaltet, lässt die Registrierung des LAN-Adapters unangetastet, was in der Regel gewünscht ist.

Seien Sie vorsichtig mit Schaltern, die für die ganze Maschine gelten. Eine globale Einstellung, die die dynamische Aktualisierung deaktiviert, betrifft jede Schnittstelle auf diesem Host, auch diejenige, auf deren Registrierung andere Clients angewiesen sind. Auf einem Domänencontroller gilt dieselbe Vorsicht mit größerer Kraft, weil der Host außerdem Standortdatensätze für Dienste besitzen kann, von denen Clients bei der Anmeldung abhängen.

Ist der Eintrag statisch, wurde er absichtlich dort platziert, und das Gespräch ist mit demjenigen, der ihn platziert hat. Einen statischen Eintrag zu löschen, weil er heute unbequem ist, entfernt den einzigen Beweis dafür, warum er existiert. Löschen Sie in beiden Fällen die veraltete Antwort erst, nachdem der Herausgeber behandelt wurde, und halten Sie fest, was Sie geändert haben, damit die nächste Person einen bewussten Eintrag von einem Unfall unterscheiden kann.

Prüfen Sie aus dem Client-Netz, das versagt hat

Die Prüfung gehört in das Netz, das das Symptom gemeldet hat, nicht auf den Server. Leeren Sie den Resolver-Cache des Clients über den unterstützten Mechanismus und wiederholen Sie dann die ursprüngliche Abfrage und die ursprüngliche Dienstverbindung per Name.

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

Der erste Befehl leert den Windows-Resolver-Cache, und der zweite zeigt, ob der Name erneut zwischengespeichert ist und welche Adresse gespeichert wurde. Eine erfolgreiche Verbindung des Servers zu sich selbst beweist nichts über einen LAN-Client, und das Entfernen einer Route zur unerwünschten Adresse korrigiert nicht, was DNS veröffentlicht.

Wiederholen Sie schließlich das Ereignis, das die Adresse früher eingebracht hat: Verbinden Sie den VPN-Client erneut oder erneuern Sie die Dial-in-Sitzung. Prüfen Sie den veröffentlichten Namen nach dieser Lebenszyklusänderung erneut. Eine Reparatur, die nur bis zur nächsten Verbindung hält, war eine Bereinigung und keine Reparatur, und zu wissen, welche der beiden Sie durchgeführt haben, ist der Unterschied zwischen dem Schließen des Tickets und seiner erneuten Öffnung nächste Woche.