Feil klokke på enheten kan stoppe VPN: sjekk tiden først

VPN slutter å koble til, loggen nevner et sertifikat, og den første innskytelsen er å bytte profilen. En enhetsklokke som er minutter eller timer feil gir nøyaktig den feilen, fordi sertifikatets gyldighet vurderes mot det lokale øyeblikket. Tidssonens etikett på skjermen er ikke problemet; den underliggende tiden er det. Sjekk klokken før du rører noe sertifikatmateriale.

Feilen ser ut som et sertifikatproblem, ikke et klokkeproblem

Et TLS-håndtrykk mislykkes når motpartens sertifikat faller utenfor sitt gyldighetsvindu relativt klokken til verifisereren. Den kontrollen kjører på klienten, så en feil klientklokke avviser et helt godt sertifikat. Feilteksten nevner sertifikatet, og derfor bytter folk det og ser den samme feilen igjen. Klokken er den billigere hypotesen og bør testes først.

En klokke som ligger foran realtiden avviser et gjeldende sertifikat som utløpt; en klokke som ligger bak avviser et nyere som ennå ikke gyldig. Begge meldingene peker på datoer, og begge oppstår uten noen kontakt med sertifikatmyndigheten. Det er tegnet: en ekte utløp rammer alle klienter, mens et klokkeproblem bare rammer den ene maskinen med feil tid.

Les øyeblikket, deretter sertifikatet

Skriv ut klokken i UTC og sertifikatets egne datoer før du endrer noe. Å sammenligne to absolutte øyeblikk fjerner tidssonespørsmålet helt fra undersøkelsen. Hvis sertifikatets vindu inneholder det gjeldende øyeblikket, er sertifikatet ikke din feil.

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

Hvis den lokale klokken er feil, sjekk om den er synkronisert og med hva. En maskin med synkronisering slått av, eller med en tidskilde den ikke når, driver til noe feiler. Statusutdataene nevner kilden og den siste vellykkede justeringen, noe som er nyttigere enn det gjeldende avviket alene. Et stort avvik uten konfigurert kilde er et annet problem enn et lite avvik mot en fungerende kilde.

timedatectl timesync-status
chronyc tracking

Stopp hvis sertifikatet faktisk er utløpt for alle klienter. Da er klokken i orden og sertifikatet trenger fornyelse, ikke justering.

Innloggingskoder mislykkes av en beslektet men annen grunn

Tidsbaserte engangspassord henter verdien sin fra det gjeldende tidstrinnet, vanligvis tretti sekunder. En enhet med klokke mer enn ett eller to trinn feil produserer koder serveren ikke godtar, selv om brukeren skrev de riktige sifrene. Feilen ser ut som et feil passord, noe som sender folk inn i en tilbakestillingsløkke som ikke kan rette en klokke.

Finn ut hvilken komponent som avviste forsøket, fordi VPN-klienten, gatewayen og identitetsleverandøren rapporterer ulike trinn. Hvis koden avvises men passordet godtas, er kontoen sannsynligvis i orden og klokken er den mistenkte. Hvis begge avvises, kan kontoen være låst og klokken er et blindspor. Følg leverandørens gjenopprettingsveiledning i stedet for å godkjenne forespørsler du ikke startet.

Ikke still klokken tilbake for å få en kode til å virke. Det skjuler årsaken og ødelegger den neste tidsbaserte kontrollen.

Rett kilden, ikke den viste timen

Synkronisering er en nettverkstjeneste, og tunnelen kan endre om tidskilden er tilgjengelig. En bedriftskilde kan kreve tunnelen, mens en offentlig kilde kan være blokkert av policy. Nettlesing kan fungere mens tidsjenestens egen rute feiler, og derfor er denne avhengigheten lett å overse. NTP er protokollen bak justeringen, og den trenger sin egen rute som enhver annen tjeneste.

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

Det er også et problem med oppstartsrekkefølgen: en svært feil klokke kan hindre en autentisert tunnel, og den eneste brukbare tidskilden kan ligge bak den tunnelen. En administrert flåte trenger en dokumentert prosedyre for den tilstanden, og å omgå sertifikatverifisering er ikke en slik prosedyre. På en personlig enhet, bruk operativsystemets egne tidskontroller og finn ut hvorfor klokken går tapt etter avslåing eller gjenoppretting. En maskin som driver ved hver oppstart har et maskinvare- eller konfigurasjonsproblem, ikke et VPN-problem.

Etter reparasjonen, prøv den opprinnelige tilkoblingen på nytt og les den nye feilen separat. En dårlig serveridentitet, et sertifikat som virkelig utløp og en avvist konto er tre forskjellige feil, og å blande dem er hvordan en enkel klokkekorreksjon blir en uke med profilbytter.