Fehler 868 mit einer IP-Adresse? Was Windows zuerst auflöst
Der Dialog nennt einen Suchfehler, obwohl das Profil numerisch aussieht. Lesen Sie das tatsächliche Profilfeld und trennen Sie dann ein Namensproblem von einem alten Wiederverbindungsfehler.
Der Dialog meldet, der Servername sei nicht auflösbar, und das Profilfeld, auf das Sie starren, ist eine Adresse. Diese Kombination ist kein Widerspruch: Der Client löst etwas anderes auf als den Wert, von dem Sie glauben, dass er ihn liest. Finden Sie heraus, was er tatsächlich anwählt, bevor Sie schließen, dass DNS defekt ist. Die Reihenfolge der eigenen Schritte des Clients zeigt Ihnen, wo Sie nachsehen müssen.
Der Client löst einen Namen auf, bevor er wählt
Eine native Windows-VPN-Verbindung liest ihr Profil, löst die Serveradresse auf, startet den Tunnel und authentifiziert erst danach. Fehler 868 gehört zum zweiten Schritt. Weil die späteren Schritte nie laufen, kann der Dialog wie ein Anmeldedatenproblem aussehen, obwohl die Auflösung zuerst fehlschlug.
Diese Reihenfolge ist nützlich, weil sie die zu prüfende Ebene eingrenzt. Wenn dasselbe Profil aus einem Netz funktioniert und aus einem anderen scheitert, liegt der Unterschied meist in der Namensauflösung und nicht im Tunneltyp oder Konto. Testen Sie die Auflösung dort, wo der Fehler auftritt, nicht dort, wo das Profil erstellt wurde.
Welcher Name, wenn das Feld eine Adresse zeigt
Lesen Sie den gespeicherten Wert statt des Anzeigenamens. Die Bezeichnung einer Verbindung ist nicht ihre Serveradresse, und zwei Einträge mit ähnlichen Bezeichnungen schicken Sie hinter dem falschen her:
Get-VpnConnection -Name "Work VPN" |
Select-Object Name, ServerAddress, TunnelType
Wurde das Profil für alle Benutzer bereitgestellt, fragen Sie diesen Bereich ebenfalls ab mit -AllUserConnection. Lösen Sie dann genau den Wert auf, den der Befehl ausgegeben hat, und zwar aus dem Netz, in dem der Fehler auftritt. Verwenden Sie das dokumentierte Gateway des Betreibers, nicht den internen Anwendungsnamen, der erst auflösbar ist, wenn der Tunnel steht. Diese zweite Abfrage scheitert aus einem erwartbaren Grund und sagt Ihnen nichts über die Wahl:
Resolve-DnsName vpn.example.com
Wenn der gespeicherte Wert wirklich numerisch ist, suchen Sie eine zweite Stelle, an der der Client einen Namen liest. Eine EAP-Konfiguration kann auf einen Server verweisen, ein aus einem anderen Werkzeug importiertes Profil kann einen eigenen Wert mitbringen, und ein früheres Installationsprogramm kann einen doppelten Eintrag hinterlassen. Das Feld im Dialog ist nicht immer die einzige Eingabe.
Das Wiederverbindungsmuster von Windows 7
Der Thread hinter diesem Fehler beschreibt Rechner, die sich einmal verbanden und bei einem späteren Versuch mit 868 scheiterten, ohne dass sich am Profil etwas änderte. Beitragende berichteten, dass ein Neustart des Dienstes Remote Access Connection Manager oder Ab- und wieder Anmelden die Verbindung vorübergehend wiederherstellte. Das sind Behelfe, keine belegte Ursache.
Behandeln Sie dieses Muster als eigene Hypothese. Ein Neustart setzt den Clientzustand zurück, ein vorübergehender Erfolg danach beweist also nicht, dass der DNS-Eintrag falsch war:
| Observation | Points toward | What to do next |
|---|---|---|
| Fails from one network, works from another | Name resolution on that path | Resolve the stored name from both networks |
| Fails after a disconnect, works after service restart | Client state, not DNS | Record the sequence for the vendor |
| Fails only on a newly provisioned machine | Profile content or scope | Compare ServerAddress and TunnelType |
Lesen Sie die Tabelle als eine Reihe unterscheidender Beobachtungen, nicht als Diagnose. Die erste Zeile ist ein Namensproblem, die zweite der Clientzustand und die dritte ein Profil, das nie korrekt war. Jede führt zu einer anderen Person und einer anderen Korrektur.
Was Sie für den Administrator sammeln sollten
Notieren Sie den Profilnamen, die gespeicherte Adresse, den Tunneltyp, das Netz, in dem der Client war, und ob der Fehler nach einer Trennung auftrat. Diese Aufzeichnung trennt einen echten Auflösungsfehler vom historischen Wiederverbindungsverhalten, ohne dass jemand raten muss. Heben Sie auch das Client-Ereignisprotokoll rund um den Versuch auf.
Der Behelf aus älteren Builds ist ein Beleg dafür, dass das Verhalten existierte, kein Versprechen, dass derselbe Dienstneustart einen aktuellen Rechner repariert. Einen dokumentierten Hostnamen durch eine wörtliche Adresse zu ersetzen ist ebenfalls keine Reparatur.
Manche Profile erwarten eine Serveridentität, die zum konfigurierten Namen passt, sodass ein numerischer Behelf einen Fehler gegen einen anderen tauschen kann. Muss der Name bleiben, reparieren Sie den Auflösungsweg statt des Profiltexts. Notieren Sie in jedem Fall, was Sie geändert haben und warum.