Eén gebruiker kan niet inloggen op de VPN: een geordende diagnose

Wanneer één persoon geen verbinding krijgt terwijl de rest van het team doorwerkt, is de nuttige vraag niet wat er kapot is, maar welke laag het niet eens was. Inloggen is een keten: de client start, de gateway antwoordt, een identiteit wordt beweerd, een tweede factor wordt vervuld, beleid wordt geëvalueerd, en pas dan stroomt het verkeer. Een breuk ergens in die keten bereikt je als dezelfde zin van de gebruiker, dus de eerste taak is de schakel vinden die echt heeft gefaald.

Behandel het rapport als uitgangspunt en niet als diagnose. De controles hieronder lopen van de goedkoopste eerst, en elk is geschreven om het onderzoek te beëindigen wanneer het mislukt.

Bepaal de fase en de tijdstempel

Schrijf vier dingen op voordat je een configuratie aanraakt: de client en zijn versie, de exacte formulering op het scherm, de minuut van de poging en het netwerk waarop de persoon zat. De formulering draagt echte informatie, want geweigerde inloggegevens, een gateway die niet antwoordt en een voltooide aanmelding die nog steeds geen interne pagina kan openen zijn drie verschillende problemen met drie verschillende eigenaren. Let op of de client een lokale logregel heeft gemaakt, want een client die nooit een pakket heeft verzonden heeft niets toe te voegen aan een zoekopdracht aan de serverkant. Met de tijdstempel vastgelegd wordt elke latere query een opzoeking in plaats van een jacht.

Stop op dit punt met het raden van wachtwoorden. Waar het account een limiet voor nieuwe pogingen heeft, kan een reeks snelle pogingen het vergrendelen en een tweede, kunstmatige fout bovenop de echte leggen. Noteer hoeveel pogingen al zijn gedaan, zodat een vergrendeling later niet voor een nieuw symptoom wordt aangezien. Een vergrendeld account neemt je ook het vermogen af om een verkeerd wachtwoord van een geweigerd beleid te onderscheiden, omdat beide als weigering aankomen.

Lees de identiteitsgebeurtenis voor die ene poging

Vraag de beheerder het authenticatierecord op te halen dat bij de genoteerde minuut past. In een Windows NPS-implementatie documenteert Microsofts NPS-probleemoplossingsgids de weigeringsgebeurtenis 6273 samen met de redencode die erbij hoort, en dat scheidt meestal een onbekende gebruiker, slechte inloggegevens, een beleidsafwijking en een oproep die om een niet-gerelateerde reden is weggevallen.

Een leeg resultaat is ook informatie. Als er niets de identiteitsdienst heeft bereikt, is de poging eerder gestorven: een verouderd gatewayadres in het profiel, een luisteraar die de client niet kan bereiken, of een host die buiten gebruik is gesteld terwijl het profiel bleef leven. Als het record bestaat en succes meldt, zijn de inloggegevens niet het probleem en verschuift het argument naar autorisatie of naar routering achter de gateway. Deze twee uitkomsten wijzen in tegengestelde richtingen, daarom moet het logonderzoek gebeuren voordat iemand een client opnieuw installeert.

Bewaar de redencode in het ticket. Dat ene veld maakt de volgende keer een zoekopdracht van vijf minuten in plaats van een herhaald onderzoek. Koppel het aan de clientversie, want een code die in één build verschijnt is een ander gesprek dan een die in elke build verschijnt.

Verander één voorwaarde tegelijk, binnen het beleid

De verleiding is om de client opnieuw te installeren, het wachtwoord opnieuw in te stellen en de laptop in één keer naar een ander netwerk te verplaatsen. Dat verhelpt soms het symptoom en vernietigt altijd het bewijs. Kies in plaats daarvan één toegestane uitwisseling: dezelfde persoon op een tweede geregistreerd apparaat, of een goedgekeurde testidentiteit op hetzelfde apparaat. Elke uitwisseling beantwoordt precies één vraag, dus een succes vernauwt de fout tot de kant die je hebt gewijzigd in plaats van de VPN als geheel de schuld te geven.

Leen geen inloggegevens van een collega voor deze vergelijking. Gebruik een testidentiteit via het ondersteunde proces, en kopieer nooit een apparaatsleutel of sla de registratie over omdat het sneller zou zijn. Waar het beleid een uitwisseling volledig verbiedt, is die beperking deel van het geteste systeem en hoort die in het verslag, niet in een omweg.

Bevestig de reparatie op het oorspronkelijke pad

Wanneer de gebroken schakel is geïdentificeerd, repareer alleen die schakel en herhaal de oorspronkelijke poging: dezelfde persoon, hetzelfde apparaat, hetzelfde netwerk, dezelfde toepassing. Een testaccount dat vanaf de admin-VLAN verbindt bewijst dat de gateway leeft, en het bewijst niets over de dinsdagochtend van de gebruiker. Vraag de gebruiker de handeling uit te voeren die mislukte en niet een eenvoudigere, want een geslaagde ping zegt weinig over een geweigerde bestandsshare.

Sluit het ticket met wat is uitgesloten en wat is veranderd. Die notitie is het verschil tussen een eenmalige redding en iets wat de volgende dienstdoende engineer opnieuw kan gebruiken.