Én bruger kan ikke logge ind på VPN’en: en ordnet diagnose
Kør kontrollen i rækkefølge: præcis fejlfase, identitetshændelse, én tilladt udskiftning, derefter politik. Stop ved det første trin, der ikke holder.
Når én person ikke kan oprette forbindelse, mens resten af teamet fortsætter med at arbejde, er det nyttige spørgsmål ikke, hvad der er i stykker, men hvilket lag der ikke var enig. Login er en kæde: klienten starter, gatewayen svarer, en identitet hævdes, en anden faktor opfyldes, politik evalueres, og først derefter flyder trafikken. Et brud hvor som helst i den kæde når dig som den samme sætning fra brugeren, så den første opgave er at finde det led, der faktisk fejlede.
Behandl rapporten som et udgangspunkt og ikke som en diagnose. Kontrollen nedenfor kører billigst først, og hver af dem er skrevet til at afslutte undersøgelsen, når den fejler.
Fastlæg fasen og tidsstemplet
Skriv fire ting ned, før du rører ved nogen konfiguration: klienten og dens version, den præcise ordlyd på skærmen, minuttet for forsøget og det netværk, personen var på. Ordlyden bærer reel information, fordi afviste legitimationsoplysninger, en gateway der ikke svarer, og et gennemført login, der stadig ikke kan åbne en intern side er tre forskellige problemer med tre forskellige ejere. Bemærk, om klienten producerede en lokal loglinje, da en klient, der aldrig har sendt en pakke, ikke har noget at tilføje til en søgning på serversiden. Med tidsstemplet registreret bliver hver senere forespørgsel et opslag i stedet for en jagt.
Stop med at gætte adgangskoder på dette tidspunkt. Hvor kontoen har en grænse for gentagne forsøg, kan en byge af hurtige forsøg låse den og tilføje en anden, kunstig fejl oven på den rigtige. Registrér, hvor mange forsøg der allerede er gjort, så en låsning ikke senere forveksles med et nyt symptom. En låst konto fjerner også din evne til at skelne en forkert adgangskode fra en afvist politik, da begge ankommer som en afvisning.
Læs identitetshændelsen for det enkelte forsøg
Bed administratoren om at trække den godkendelsespost frem, der matcher det minut, du registrerede. I en Windows NPS-udrulning dokumenterer Microsofts fejlfindingsvejledning til NPS afvisningshændelse 6273 sammen med den årsagskode, der følger med den, og det skiller normalt en ukendt bruger, dårlige legitimationsoplysninger, en politisk uoverensstemmelse og et opkald, der blev droppet af en urelateret grund.
Et tomt resultat er også information. Hvis intet nåede identitetstjenesten, døde forsøget tidligere: en forældet gatewayadresse i profilen, en listener som klienten ikke kan nå, eller en vært, der blev taget ud af drift, mens profilen fortsatte med at leve. Hvis posten findes og rapporterer succes, er legitimationsoplysningerne ikke problemet, og argumentet flytter sig til autorisation eller til routing bag gatewayen. De to udfald peger i modsatte retninger, og derfor skal logsøgningen ske, før nogen geninstallerer en klient.
Gem årsagskoden i sagen. Det ene felt gør den næste forekomst til et opslag på fem minutter i stedet for en gentaget undersøgelse. Par det med klientversionen, fordi en kode, der vises på ét build, er en anden samtale end en, der vises på hvert build.
Ændr én betingelse ad gangen, inden for politikken
Fristelsen er at geninstallere klienten, nulstille adgangskoden og flytte laptoppen til et andet netværk i én omgang. Det retter nogle gange symptomet og ødelægger altid beviserne. Vælg i stedet én tilladt udskiftning: den samme person på en anden registreret enhed, eller en godkendt testidentitet på samme enhed. Hver udskiftning besvarer præcis ét spørgsmål, så en succes indsnævrer fejlen til den side, du ændrede, i stedet for at give VPN’en som helhed skylden.
Lån ikke en kollegas legitimationsoplysninger til denne sammenligning. Brug en testidentitet gennem den understøttede proces, og kopiér aldrig en enhedsnøgle eller spring tilmelding over, fordi det ville være hurtigere. Hvor politikken helt forbyder en udskiftning, er den begrænsning en del af det system, der testes, og hører i registreringen snarere end i en omvej.
Bekræft reparationen på den oprindelige vej
Når det brudte led er identificeret, reparer kun det led og gentag det oprindelige forsøg: samme person, samme enhed, samme netværk, samme program. En testkonto, der forbinder fra admin-VLAN’et, beviser, at gatewayen lever, og den beviser intet om brugerens tirsdag morgen. Bed brugeren udføre den handling, der fejlede, i stedet for en enklere, da en vellykket ping siger lidt om en afvist filshare.
Luk sagen med, hvad der blev udelukket, og hvad der ændrede sig. Den note er forskellen mellem en engangsredning og noget, som den næste vagthavende ingeniør kan genbruge.