Én bruker får ikke logget på VPN: en ordnet diagnose

Når én person ikke får koblet til mens resten av teamet fortsetter å jobbe, er det nyttige spørsmålet ikke hva som er ødelagt, men hvilket lag som ikke var enig. Pålogging er en kjede: klienten starter, gatewayen svarer, en identitet hevdes, en annen faktor oppfylles, policy evalueres, og først da flyter trafikken. En brist hvor som helst i den kjeden når deg som den samme setningen fra brukeren, så den første oppgaven er å finne leddet som faktisk feilet.

Behandle rapporten som et utgangspunkt og ikke som en diagnose. Kontrollene nedenfor går fra den billigste først, og hver av dem er skrevet for å avslutte undersøkelsen når den feiler.

Fastslå fasen og tidsstempelet

Skriv ned fire ting før du rører noen konfigurasjon: klienten og versjonen, den nøyaktige ordlyden på skjermen, minuttet for forsøket og nettverket personen var på. Ordlyden bærer reell informasjon, fordi avviste påloggingsdata, en gateway som ikke svarer og en fullført pålogging som fortsatt ikke kan åpne en intern side er tre forskjellige problemer med tre forskjellige eiere. Legg merke til om klienten produserte en lokal logglinje, siden en klient som aldri sendte en pakke ikke har noe å tilføye til et søk på serversiden. Med tidsstempelet registrert blir hvert senere oppslag et søk i stedet for en jakt.

Slutt å gjette passord på dette punktet. Hvor kontoen har en grense for nye forsøk, kan en byge av raske forsøk låse den og legge til en andre, kunstig feil oppå den ekte. Registrer hvor mange forsøk som allerede er gjort, slik at en låsing ikke senere forveksles med et nytt symptom. En låst konto fjerner også evnen din til å skille et feil passord fra en avvist policy, siden begge kommer som en avvisning.

Les identitetshendelsen for det ene forsøket

Be administratoren hente autentiseringsposten som samsvarer med minuttet du registrerte. I en Windows NPS-utrulling dokumenterer Microsofts feilsøkingsveiledning for NPS avvisningshendelse 6273 sammen med årsakskoden som følger med, og det skiller vanligvis en ukjent bruker, dårlige påloggingsdata, en policy-avvik og et anrop som ble droppet av en urelatert grunn.

Et tomt resultat er også informasjon. Hvis ingenting nådde identitetstjenesten, døde forsøket tidligere: en utdatert gatewayadresse i profilen, en lytter som klienten ikke når, eller en vert som ble tatt ut av drift mens profilen fortsatte å leve. Hvis posten finnes og rapporterer suksess, er ikke påloggingsdataene problemet, og argumentet flytter seg til autorisasjon eller til ruting bak gatewayen. Disse to utfallene peker i motsatte retninger, derfor må loggsøket skje før noen installerer en klient på nytt.

Behold årsakskoden i saken. Det ene feltet gjør neste forekomst til et søk på fem minutter i stedet for en gjentatt undersøkelse. Par det med klientversjonen, fordi en kode som vises i én bygg er en annen samtale enn en som vises i hver bygg.

Endre én betingelse om gangen, innenfor policyen

Fristelsen er å installere klienten på nytt, tilbakestille passordet og flytte laptopen til et annet nettverk i én omgang. Det retter noen ganger symptomet og ødelegger alltid bevisene. Velg i stedet én tillatt utskifting: samme person på en annen registrert enhet, eller en godkjent testidentitet på samme enhet. Hver utskifting svarer på nøyaktig ett spørsmål, så en suksess snevrer feilen inn til siden du endret i stedet for å klandre VPN-en som helhet.

Lån ikke en kollegas påloggingsdata for denne sammenligningen. Bruk en testidentitet gjennom den støttede prosessen, og kopier aldri en enhetsnøkkel eller hopp over registreringen fordi det ville være raskere. Hvor policyen helt forbyr en utskifting, er den begrensningen en del av systemet som testes og hører hjemme i registreringen, ikke i en omvei.

Bekreft reparasjonen på den opprinnelige veien

Når det ødelagte leddet er identifisert, reparer bare det leddet og gjenta det opprinnelige forsøket: samme person, samme enhet, samme nettverk, samme program. En testkonto som kobler til fra admin-VLAN-et beviser at gatewayen lever, og den beviser ingenting om brukerens tirsdag morgen. Be brukeren utføre handlingen som feilet i stedet for en enklere, siden en vellykket ping sier lite om en avvist fil deling.

Lukk saken med hva som ble utelukket og hva som endret seg. Den noten er forskjellen mellom en engangsredning og noe den neste vakthavende ingeniøren kan gjenbruke.