Én enhed kan stadig ikke forbinde efter nulstilling af VPN-adgangskoden
Den nye adgangskode virker overalt undtagen på én klient. Find det lager, der stadig holder den gamle værdi, begræns forsøgene, og verificér med ét forsøg.
Du nulstillede adgangskoden, testede den i portalen, og en bærbar computer kan stadig ikke forbinde. Instinktet er at nulstille den igen, og det er netop sådan en konto bliver låst, og en forældet hemmelighed bliver en hændelse. En VPN-klient beder sjældent om en adgangskode hver gang; den beder én gang og gemmer svaret et sted, du ikke har valgt. At finde det sted er hele opgaven, og det er hurtigere end endnu en nulstilling.
Bekræft, hvad hver klient faktisk sender
Kontrollér konto, domæne og gateway på den fejlende klient, før du antager, at adgangskoden er problemet. Et webportallogin kan bruge et andet identitetssystem end selve VPN’en, så et vellykket portallogin siger intet om protokollens autentificering. Nogle installationer accepterer en e-mail i portalen og et andet brugernavn i tunnelen. Bekræft, hvilken identitet klienten er konfigureret til at præsentere, før du nulstiller noget.
Læs fejlteksten og klassificér den. En certifikatfejl, en udløbet udfordring eller en ikke-understøttet cipher er ikke en forældet adgangskode, og behandlingen af den som en sådan skaber en nulstillingsløkke uden effekt. Hvis tjenesten har en lockout-politik, så stop efter to eller tre mislykkede forsøg, og bekræft kontoens tilstand, før du fortsætter.
Optæl lagrene i stedet for at gætte
Fire lagre holder en VPN-hemmelighed, og tabellen nedenfor viser for hvert af dem, hvor værdien overlever, og hvad det egentlig betyder at rydde den. En indbygget OS-profil holder hemmeligheden i platformens legitimationslager, og derfor kan posten overleve det program, der skrev den. En klientkonfigurationsfil holder værdien, hvor klienten læser den, enten inline eller i en refereret auth-fil, så redigering af en anden fil ændrer intet. En browserportal-cookie og en politikleveret legitimation lever et sted, som enheden ikke rigtig ejer, og det afgør, hvem der må ændre dem.
| Store | Where it lives | How to clear it |
|---|---|---|
| Native OS profile | Windows Credentials, NetworkManager secrets | forget or edit the connection |
| Client configuration file | a referenced auth file or inline value | edit the file the client actually reads |
| Browser session | cookie for the portal SSO | sign out of the portal, not just close the tab |
| Managed policy | delivered by the management service | change it in the manager, not on the device |
Kontrollér dem i en fast rækkefølge: først OS’ets legitimationslager, fordi det er det, klienten konsulterer som standard, derefter klientens eget vault eller konfigurationsfil, så browsersessionen og til sidst politikken, som kan overskrive alle tre. Rækkefølgen er vigtig, fordi et senere lager stille kan gendanne et tidligere, og du vil have rettet det forkerte lag, mens fejlen fortsætter. Skriv ned, hvilket lager du ændrede, fordi den note er det, der gør den næste nulstilling til en opgave på to minutter i stedet for en eftermiddag.
Se i det lager, klienten faktisk bruger
Læs, før du sletter, så du ved, hvilken post der hørte til VPN’en. Kommandoerne nedenfor viser og undersøger i stedet for at fjerne, hvilket holder diagnosen reversibel.
# Windows credential store
cmdkey /list | findstr /i vpn# Windows native profile
Get-VpnConnection -Name "Work" | Select-Object -ExpandProperty Guid# macOS Keychain
security find-generic-password -s "Company VPN" -g# Linux NetworkManager
nmcli -s connection show "Work" | grep -i passwordPå Linux viser -s hemmeligheder, som NetworkManager ellers skjuler. På macOS udskriver Keychain-kommandoen det gemte element, så behandl terminalens scrollback som følsomt. Hvis den fejlende klient er en tredjepartsapp med sit eget vault, vil OS-lageret se korrekt ud, mens appen beholder sin egen kopi, og det vault er, hvor ændringen hører hjemme.
Håndter de enheder, der er offline
Bærbare computere, der vågner og genopretter forbindelse af sig selv vil fortsætte med at præsentere den gamle hemmelighed, så længe deres kopi findes. Planlæg opdateringen, så disse enheder er rettet, før de prøver igen i en byge, og overvej at deaktivere auto-forbindelse på den berørte profil, indtil hver enkelt har været gennem det understøttede flow.
For en administreret flåde ændres værdien der, hvor politikken er defineret. Redigering af en lokal kopi på en enhed, hvis legitimation leveres centralt, er i bedste fald midlertidig; den næste politikopdatering gendanner den gamle værdi, og fejlen vender tilbage uden forklaring.
Verificér med ét kontrolleret forsøg
Opdatér den tilsigtede post, forbind én gang igen, og bekræft, at tunnelen når noget konkret. Ét kontrolleret forsøg giver en brugbar fejl, hvis det fejler, mens tyve giver en låst konto og et mysterium. Hvis en klient stadig fejler, efter lageret er rettet, så fang én enkelt fejl uden hemmeligheder og stop. Gem den fejl sammen med enhedens navn, så næste vagt starter, hvor du sluttede.
En adgangskodeændring rører ikke certifikater, sessionstokens eller MFA-tilmelding, og det er separate identiteter med deres egen livscyklus. Et fornyet certifikat rettes ikke ved at rotere en adgangskode, og et token udstedt før nulstillingen kan stadig være gyldigt. Slut af med at skrive ned, hvilket lager der holdt den forældede værdi, fordi den næste nulstilling rammer den samme liste.