Ein Benutzer kann sich nicht am VPN anmelden: eine geordnete Diagnose

Wenn eine Person keine Verbindung herstellen kann, während der Rest des Teams weiterarbeitet, lautet die nützliche Frage nicht, was kaputt ist, sondern welche Schicht nicht übereingestimmt hat. Die Anmeldung ist eine Kette: Der Client startet, das Gateway antwortet, eine Identität wird behauptet, ein zweiter Faktor wird erfüllt, eine Richtlinie wird ausgewertet, und erst dann fließt Verkehr. Ein Bruch an irgendeiner Stelle dieser Kette erreicht Sie als derselbe Satz vom Benutzer, also ist die erste Aufgabe, das Glied zu finden, das tatsächlich versagt hat.

Behandeln Sie den Bericht als Ausgangspunkt und nicht als Diagnose. Die folgenden Prüfungen laufen von der billigsten an, und jede ist so geschrieben, dass sie die Untersuchung beendet, wenn sie fehlschlägt.

Stufe und Zeitstempel festlegen

Notieren Sie vier Dinge, bevor Sie irgendeine Konfiguration anfassen: den Client und seine Version, den genauen Wortlaut auf dem Bildschirm, die Minute des Versuchs und das Netzwerk, in dem die Person war. Der Wortlaut trägt echte Information, denn abgelehnte Anmeldedaten, ein Gateway, das nicht antwortet, und eine abgeschlossene Anmeldung, die dennoch keine interne Seite öffnen kann sind drei verschiedene Probleme mit drei verschiedenen Zuständigkeiten. Vermerken Sie, ob der Client eine lokale Logzeile erzeugt hat, denn ein Client, der nie ein Paket gesendet hat, hat einer serverseitigen Suche nichts hinzuzufügen. Mit festgehaltenem Zeitstempel wird jede spätere Abfrage zu einem Nachschlagen statt zu einer Jagd.

Hören Sie an dieser Stelle auf, Passwörter zu raten. Wo das Konto ein Wiederholungslimit hat, kann ein Schwall schneller Versuche es sperren und einen zweiten, künstlichen Fehler auf den echten legen. Halten Sie fest, wie viele Versuche bereits gemacht wurden, damit eine Sperre später nicht für ein neues Symptom gehalten wird. Ein gesperrtes Konto nimmt Ihnen zudem die Möglichkeit, ein falsches Passwort von einer abgelehnten Richtlinie zu unterscheiden, da beides als Ablehnung ankommt.

Lesen Sie das Identitätsereignis für diesen einen Versuch

Bitten Sie den Administrator, den Authentifizierungseintrag herauszuziehen, der zu der notierten Minute passt. In einer Windows-NPS-Bereitstellung dokumentiert Microsofts NPS-Fehlerbehebungsanleitung das Ablehnungsereignis 6273 zusammen mit dem zugehörigen Ursachencode, der meist einen unbekannten Benutzer, falsche Anmeldedaten, eine Richtlinienabweichung und einen aus unabhängigem Grund abgebrochenen Anruf trennt.

Ein leeres Ergebnis ist ebenfalls Information. Wenn nichts den Identitätsdienst erreicht hat, ist der Versuch früher gestorben: eine veraltete Gateway-Adresse im Profil, ein Listener, den der Client nicht erreicht, oder ein Host, der außer Betrieb genommen wurde, während das Profil weiterlebte. Wenn der Eintrag existiert und Erfolg meldet, sind die Anmeldedaten nicht das Problem, und die Argumentation wandert zur Autorisierung oder zum Routing hinter dem Gateway. Diese beiden Ausgänge weisen in entgegengesetzte Richtungen, weshalb die Logsuche geschehen muss, bevor jemand einen Client neu installiert.

Behalten Sie den Ursachencode im Ticket. Dieses eine Feld macht das nächste Auftreten zu einem Nachschlagen in fünf Minuten statt zu einer erneuten Untersuchung. Paaren Sie ihn mit der Clientversion, denn ein Code, der in einem Build auftritt, ist ein anderes Gespräch als einer, der in jedem Build auftritt.

Ändern Sie jeweils eine Bedingung, im Rahmen der Richtlinie

Die Versuchung ist, den Client neu zu installieren, das Passwort zurückzusetzen und das Notebook in einem Durchgang in ein anderes Netzwerk zu bewegen. Das behebt manchmal das Symptom und zerstört immer die Beweise. Wählen Sie stattdessen einen erlaubten Tausch: dieselbe Person auf einem zweiten registrierten Gerät oder eine genehmigte Testidentität auf demselben Gerät. Jeder Tausch beantwortet genau eine Frage, sodass ein Erfolg den Fehler auf die Seite eingrenzt, die Sie geändert haben, statt das VPN als Ganzes zu beschuldigen.

Leihen Sie sich für diesen Vergleich keine Zugangsdaten eines Kollegen. Verwenden Sie eine Testidentität über den unterstützten Prozess, und kopieren Sie niemals einen Geräteschlüssel oder überspringen Sie die Registrierung, weil es schneller ginge. Wo die Richtlinie einen Tausch gänzlich verbietet, ist diese Einschränkung Teil des geprüften Systems und gehört in die Aufzeichnung statt in einen Umweg.

Bestätigen Sie die Reparatur auf dem ursprünglichen Weg

Wenn das defekte Glied identifiziert ist, reparieren Sie nur dieses Glied und wiederholen Sie den ursprünglichen Versuch: dieselbe Person, dasselbe Gerät, dasselbe Netzwerk, dieselbe Anwendung. Ein Testkonto, das sich aus dem Admin-VLAN verbindet, beweist, dass das Gateway lebt, und es beweist nichts über den Dienstagmorgen des Benutzers. Bitten Sie den Benutzer, die fehlgeschlagene Aktion auszuführen und nicht eine einfachere, da ein erfolgreicher Ping wenig über eine abgelehnte Dateifreigabe aussagt.

Schließen Sie das Ticket damit, was ausgeschlossen wurde und was sich geändert hat. Diese Notiz ist der Unterschied zwischen einer einmaligen Rettung und etwas, das der nächste Bereitschaftsingenieur wiederverwenden kann.