En användare kan inte logga in på VPN: en ordnad diagnostik

När en person inte kan ansluta medan resten av teamet fortsätter arbeta, är den användbara frågan inte vad som är trasigt, utan vilket lager som inte var överens. Inloggning är en kedja: klienten startar, gatewayen svarar, en identitet hävdas, en andra faktor uppfylls, policy utvärderas, och först då flödar trafiken. Ett brott var som helst i den kedjan når dig som samma mening från användaren, så den första uppgiften är att hitta länken som faktiskt misslyckades.

Behandla rapporten som en utgångspunkt och inte som en diagnos. Kontrollerna nedan går från den billigaste först, och var och en är skriven för att avsluta utredningen när den misslyckas.

Fastställ fasen och tidsstämpeln

Skriv ned fyra saker innan du rör någon konfiguration: klienten och dess version, den exakta formuleringen på skärmen, minuten för försöket och nätverket personen var på. Formuleringen bär verklig information, eftersom avvisade inloggningsuppgifter, en gateway som inte svarar och en slutförd inloggning som fortfarande inte kan öppna en intern sida är tre olika problem med tre olika ägare. Notera om klienten producerade en lokal logglinje, eftersom en klient som aldrig skickat ett paket inte har något att tillföra en sökning på serversidan. Med tidsstämpeln registrerad blir varje senare fråga en sökning i stället för en jakt.

Sluta gissa lösenord vid denna punkt. Där kontot har en gräns för nya försök kan en skur av snabba försök låsa det och lägga till ett andra, konstgjort fel ovanpå det riktiga. Registrera hur många försök som redan gjorts, så att en låsning inte senare förväxlas med ett nytt symptom. Ett låst konto tar också bort din förmåga att skilja ett felaktigt lösenord från en avvisad policy, eftersom båda anländer som en avvisning.

Läs identitetshändelsen för det enda försöket

Be administratören hämta autentiseringsposten som matchar den registrerade minuten. I en Windows NPS-distribution dokumenterar Microsofts felsökningsguide för NPS avvisningshändelsen 6273 tillsammans med den orsakskod som följer med, och det skiljer vanligtvis en okänd användare, dåliga inloggningsuppgifter, en policyavvikelse och ett samtal som släppts av en orelaterad anledning.

Ett tomt resultat är också information. Om ingenting nådde identitetstjänsten dog försöket tidigare: en inaktuell gatewayadress i profilen, en lyssnare som klienten inte når, eller en värd som togs ur drift medan profilen fortsatte leva. Om posten finns och rapporterar framgång är inloggningsuppgifterna inte problemet och argumentet flyttar till auktorisering eller till routing bakom gatewayen. Dessa två utfall pekar i motsatta riktningar, därför måste loggsökningen ske innan någon installerar om en klient.

Behåll orsakskoden i ärendet. Det enda fältet gör nästa förekomst till en sökning på fem minuter i stället för en upprepad utredning. Para ihop det med klientversionen, eftersom en kod som visas i en bygge är ett annat samtal än en som visas i varje bygge.

Ändra ett villkor i taget, inom policyn

Frestelsen är att installera om klienten, återställa lösenordet och flytta laptopen till ett annat nätverk i en enda omgång. Det åtgärdar ibland symptomet och förstör alltid bevisen. Välj i stället ett enda tillåtet byte: samma person på en andra registrerad enhet, eller en godkänd testidentitet på samma enhet. Varje byte svarar på exakt en fråga, så en framgång snävar in felet till den sida du ändrade i stället för att skylla på VPN:en som helhet.

Låna inte en kollegas inloggningsuppgifter för denna jämförelse. Använd en testidentitet genom den stödda processen, och kopiera aldrig en enhetsnyckel eller hoppa över registreringen för att det skulle vara snabbare. Där policyn helt förbjuder ett byte är den begränsningen en del av systemet som testas och hör hemma i registreringen, inte i en omväg.

Bekräfta reparationen på den ursprungliga vägen

När den trasiga länken har identifierats, reparera bara den länken och upprepa det ursprungliga försöket: samma person, samma enhet, samma nätverk, samma program. Ett testkonto som ansluter från admin-VLAN:et bevisar att gatewayen lever, och det bevisar ingenting om användarens tisdagsmorgon. Be användaren utföra den handling som misslyckades och inte en enklare, eftersom en lyckad ping säger lite om en avvisad fil delning.

Stäng ärendet med vad som uteslöts och vad som ändrades. Den anteckningen är skillnaden mellan en engångsräddning och något som nästa jourhavande ingenjör kan återanvända.