VPN sluttar å kople til, loggen nemner eit sertifikat, og den første innskytelsen er å byta profilen. Ei einingsklokke som er minutt eller timar feil gjev nøyaktig den feilen, fordi gyldet til sertifikatet vert vurdert mot den lokale augneblinken. Tidssoneetiketten på skjermen er ikkje problemet; den underliggjande tida er det. Sjekk klokka før du rører noko sertifikatmateriale.

Feilen ser ut som eit sertifikatproblem, ikkje eit klokkeproblem

Eit TLS-handtrykk mislukkast når sertifikatet til motparten fell utanfor gyldevindauget sitt relativt til klokka til verifiseraren. Den kontrollen køyrer på klienten, så ei feil klientklokke avviser eit heilt godt sertifikat. Feilteksten nemner sertifikatet, og difor byter folk det og ser den same feilen att. Klokka er den billegare hypotesen og bør testast først.

Ei klokke som ligg framfor røynd tid avviser eit gjeldande sertifikat som utlope; ei klokke som ligg bak avviser eit nyare som enno ikkje gyldig. Begge meldingane peikar på datoar, og begge oppstår utan nokon kontakt med sertifikatstyresmakta. Det er teiknet: ein ekte utløp råkar alle klientar, medan eit klokkeproblem berre råkar den eine maskina med feil tid.

Les augneblinken, deretter sertifikatet

Skriv ut klokka i UTC og sertifikatet sine eigne datoar før du endrar noko. Å samanlikne to absolutte augneblinkar fjernar tidssonespørsmålet heilt frå undersøkinga. Viss vindauget til sertifikatet inneheld den gjeldande augneblinken, er sertifikatet ikkje feilen din.

date -u
timedatectl
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -dates

Viss den lokale klokka er feil, sjekk om ho er synkronisert og med kva. Ei maskin med synkronisering slått av, eller med ei tidskjelde ho ikkje når, driv til noko feilar. Statusutskrifta nemner kjelda og den siste vellukka justeringa, noko som er nyttigare enn den gjeldande avviket åleine. Eit stort avvik utan konfigurert kjelde er eit anna problem enn eit lite avvik mot ei fungerande kjelde.

timedatectl timesync-status
chronyc tracking

Stopp viss sertifikatet faktisk er utlope for alle klientar. Då er klokka i orden og sertifikatet treng fornying, ikkje justering.

Innloggingskoder mislukkast av ein skyldig men annan grunn

Tidsbaserte eingongspassord hentar verdien sin frå det gjeldande tidstrinnet, vanlegvis tretti sekund. Ei eining med klokka meir enn eitt eller to trinn feil lagar koder som tenaren ikkje godtek, sjølv om brukaren skreiv dei rette sifra. Feilen ser ut som eit feil passord, noko som sender folk inn i ei nullstillingsløkke som ikkje kan rette ei klokke.

Finn ut kva komponent som avviste forsøket, fordi VPN-klienten, gatewayen og identitetsleverandøren rapporterer ulike trinn. Viss koden vert avvist men passordet godteke, er kontoen truleg i orden og klokka er den mistenkte. Viss begge vert avviste, kan kontoen vere låst og klokka er eit blindspor. Følg rettleiinga til leverandøren for attoppretting i staden for å godkjenne førespurnader du ikkje starta.

Ikkje still klokka tilbake for å få ein kode til å verke. Det skjuler årsaka og øydelegg den neste tidsbaserte kontrollen.

Rett kjelda, ikkje den viste timen

Synkronisering er ei nettverksteneste, og tunnelen kan endre om tidskjelda er tilgjengeleg. Ei bedriftskjelde kan krevje tunnelen, medan ei offentleg kjelde kan vere blokkert av policy. Netlesing kan fungere medan ruta til tidstenesta sjølv feilar, og difor er denne avhengnaden lett å oversjå. NTP er protokollen bak justeringa, og han treng si eiga rute som kvar annan teneste.

sudo systemctl status systemd-timesyncd
sudo chronyc sources -v
ping -c1 203.0.113.20

Det er også eit problem med oppstartsrekkjefølgja: ei særs feil klokke kan hindre ein autentisert tunnel, og den einaste brukbare tidskjelda kan liggje bak den tunnelen. Ein styrt flåte treng ein dokumentert prosedyre for den tilstanden, og å omgå sertifikatverifisering er ikkje ein slik prosedyre. På ei personleg eining, bruk tidskontrollane til operativsystemet sjølv og finn ut kvifor klokka går tapt etter avslåing eller attoppretting. Ei maskin som driv ved kvar oppstart har eit maskinvare- eller konfigurasjonsproblem, ikkje eit VPN-problem.

Etter reparasjonen, prøv den opphavlege tilkoplinga på nytt og les den nye feilen separat. Ein dårleg tenaridentitet, eit sertifikat som verkeleg utløp og ein avvist konto er tre ulike feil, og å blande dei er korleis ei enkel klokkekorrigering vert ei veke med profilbytar.

Relaterte artiklar