Verkeerde toestelklok kan 'n VPN stop: kyk eers na die tyd
'n Sertifikaat word teen die oomblik beoordeel, nie teen die tydsone-etiket nie. Lees die klok, die sertifikaatdatums en die tydbron se roete voordat jy iets vervang.
Die VPN stop met verbind, die logboek noem 'n sertifikaat, en die eerste instink is om die profiel te vervang. 'n Toestelklok wat minute of ure verkeerd is, lewer presies daardie fout, want sertifikaatgeldigheid word teen die plaaslike oomblik beoordeel. Die tydsone-etiket op die skerm is nie die probleem nie; die onderliggende tyd is. Kontroleer die klok voordat jy aan enige sertifikaatmateriaal raak.
Die fout lyk soos 'n sertifikaatprobleem, nie 'n klokprobleem nie
Die TLS-handshake misluk wanneer die eweknie se sertifikaat buite sy geldigheidsvenster val relatief tot die verifieerder se klok. Daardie kontrole loop op die kliënt, so 'n kliëntklok wat verkeerd is, verwerp 'n heeltemal goeie sertifikaat. Die foutteks noem die sertifikaat, en daarom vervang mense dit en sien dieselfde mislukking weer. Die klok is die goedkoper hipotese en moet eerste getoets word.
'n Klok wat voor die werklike tyd loop, verwerp 'n huidige sertifikaat as verval; 'n klok wat agter is, verwerp 'n nuwer een as nog nie geldig nie. Beide boodskappe wys na datums, en albei word geproduseer sonder enige kontak met die sertifikaatowerheid. Dit is die aanduiding: 'n egte vervaldatum raak elke kliënt, terwyl 'n klokprobleem net die een masjien met die verkeerde tyd raak.
Lees die oomblik, dan die sertifikaat
Druk die klok in UTC en die sertifikaat se eie datums voordat jy iets verander. Om twee absolute oomblikke te vergelyk verwyder die tydsonevraag heeltemal uit die ondersoek. As die sertifikaatvenster die huidige oomblik bevat, is die sertifikaat nie jou fout nie.
date -u
timedatectl
openssl s_client -connect vpn.example.com:443 -servername vpn.example.com </dev/null 2>/dev/null | openssl x509 -noout -dates
As die plaaslike klok verkeerd is, kyk of dit gesinkroniseer is en waarmee. 'n Masjien met sinchronisasie afgeskakel, of met 'n tydbron wat dit nie kan bereik nie, dryf totdat iets misluk. Die statusuitvoer noem die bron en die laaste suksesvolle aanpassing, wat nuttiger is as die huidige afwyking alleen. 'n Groot afwyking sonder 'n gekonfigureerde bron is 'n ander probleem as 'n klein afwyking teen 'n werkende bron.
timedatectl timesync-status
chronyc tracking
Stop as die sertifikaat werklik vir elke kliënt verval het. Dan is die klok reg en het die sertifikaat vernuwing nodig, nie aanpassing nie.
Aanmeldkodes misluk om 'n verwante maar ander rede
Tydgebaseerde eenmalige wagwoorde put hul waarde uit die huidige tydstap, gewoonlik dertig sekondes. 'n Toestel wie se klok met meer as 'n stap of twee verkeerd is, produseer kodes wat die bediener nie sal aanvaar nie, selfs al het die gebruiker die regte syfers getik. Die fout lyk soos 'n verkeerde wagwoord, wat mense in 'n herstel-lus stuur wat nie 'n klok kan regmaak nie.
Bepaal watter komponent die poging verwerp het, want die VPN-kliënt, die gateway en die identiteitsverskaffer rapporteer verskillende fases. As die kode verwerp word maar die wagwoord aanvaar word, is die rekening waarskynlik reg en is die klok die verdagte. As albei verwerp word, kan die rekening gesluit wees en is die klok 'n dwaalspoor. Volg die verskaffer se herstelriglyne eerder as om versoeke goed te keur wat jy nie begin het nie.
Moenie die klok terugstel om 'n kode te laat werk nie. Dit verberg die oorsaak en breek die volgende tydgebaseerde kontrole.
Maak die bron reg, nie die vertoonde uur nie
Sinchronisasie is 'n netwerkdiens, en die tonnel kan verander of die tydbron bereikbaar is. 'n Korporatiewe bron kan die tonnel vereis, terwyl 'n publieke bron deur beleid geblokkeer kan word. Browsing kan werk terwyl die tyddiens se eie pad misluk, en daarom is hierdie afhanklikheid maklik om te mis. NTP is die protokol agter die aanpassing, en dit het sy eie pad nodig soos enige ander diens.
sudo systemctl status systemd-timesyncd
sudo chronyc sources -v
ping -c1 203.0.113.20
Daar is ook 'n bootstrap-volgordeprobleem: 'n erg verkeerde klok kan 'n geauthentiseerde tonnel verhinder, en die enigste bruikbare tydbron kan agter daardie tonnel sit. 'n Bestuurde vloot het 'n gedokumenteerde prosedure vir daardie toestand nodig, en om sertifikaatverifikasie te omseil is nie een nie. Op 'n persoonlike toestel, gebruik die bedryfstelsel se eie tydbeheer en vind uit waarom die klok verlore gaan na afskakeling of herstel. 'n Masjien wat by elke opstart dryf, het 'n hardeware- of konfigurasieprobleem, nie 'n VPN-probleem nie.
Probeer na die herstel weer die oorspronklike verbinding en lees die nuwe fout apart. 'n Slegte bedieneridentiteit, 'n sertifikaat wat werklik verval het en 'n verwerpte rekening is drie verskillende mislukkings, en om hulle te vermeng is hoe 'n eenvoudige klokregstelling 'n week van profielvervangings word.