Een verkeerde klok op het apparaat kan de VPN stoppen: controleer eerst de tijd

De VPN stopt met verbinden, het log noemt een certificaat en de eerste reactie is het profiel vervangen. Een klok op het apparaat die minuten of uren verkeerd staat, levert precies die fout op, omdat de geldigheid van het certificaat tegen het lokale moment wordt beoordeeld. Het tijdzonelabel op het scherm is niet het probleem; de onderliggende tijd is dat. Controleer de klok voordat je certificaatmateriaal aanraakt.

De fout lijkt een certificaatprobleem, geen klokprobleem

Een TLS-handshake mislukt wanneer het certificaat van de andere partij buiten zijn geldigheidsvenster valt ten opzichte van de klok van de verificateur. Die controle draait op de client, dus een verkeerde clientklok wijst een volkomen goed certificaat af. De fouttekst noemt het certificaat, en daarom vervangen mensen het en zien ze dezelfde fout opnieuw. De klok is de goedkopere hypothese en moet eerst worden getest.

Een klok die voorloopt op de echte tijd wijst een geldig certificaat af als verlopen; een klok die achterloopt wijst een nieuwer certificaat af als nog niet geldig. Beide berichten wijzen naar datums, en beide ontstaan zonder enig contact met de certificaatautoriteit. Dat is de aanwijzing: een echte afloop treft elke client, terwijl een klokprobleem alleen de ene machine met de verkeerde tijd treft.

Lees het moment en dan het certificaat

Druk de klok in UTC af en de eigen datums van het certificaat voordat je iets wijzigt. Twee absolute momenten vergelijken haalt de tijdzonevraag volledig uit het onderzoek. Als het venster van het certificaat het huidige moment bevat, is het certificaat niet je fout.

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

Als de lokale klok verkeerd staat, controleer of die gesynchroniseerd is en waarmee. Een machine met synchronisatie uitgeschakeld, of met een tijdbron die ze niet bereikt, drift totdat iets faalt. De statusuitvoer noemt de bron en de laatste geslaagde aanpassing, wat nuttiger is dan alleen de huidige afwijking. Een grote afwijking zonder ingestelde bron is een ander probleem dan een kleine afwijking ten opzichte van een werkende bron.

timedatectl timesync-status
chronyc tracking

Stop als het certificaat echt voor elke client is verlopen. Dan is de klok in orde en moet het certificaat worden vernieuwd, niet aangepast.

Inlogcodes mislukken om een verwante maar andere reden

Op tijd gebaseerde eenmalige wachtwoorden halen hun waarde uit de huidige tijdstap, meestal dertig seconden. Een apparaat waarvan de klok meer dan een stap of twee verkeerd staat, maakt codes die de server niet accepteert, ook al heeft de gebruiker de juiste cijfers getypt. De fout lijkt op een verkeerd wachtwoord, waardoor mensen in een resetlus belanden die een klok niet kan repareren.

Zoek uit welk onderdeel de poging heeft geweigerd, want de VPN-client, de gateway en de identiteitsprovider melden verschillende fasen. Als de code wordt geweigerd maar het wachtwoord wordt geaccepteerd, is het account waarschijnlijk in orde en is de klok de verdachte. Als beide worden geweigerd, kan het account vergrendeld zijn en is de klok een dwaalspoor. Volg de herstelrichtlijnen van de provider in plaats van verzoeken goed te keuren die je niet hebt gestart.

Zet de klok niet terug om een code te laten werken. Dat verbergt de oorzaak en breekt de volgende tijdsgebaseerde controle.

Repareer de bron, niet het getoonde uur

Synchronisatie is een netwerkdienst, en de tunnel kan veranderen of de tijdbron bereikbaar is. Een bedrijfsbron kan de tunnel vereisen, terwijl een publieke bron door beleid kan worden geblokkeerd. Browsen kan werken terwijl het eigen pad van de tijddienst faalt, en daarom is deze afhankelijkheid makkelijk te missen. NTP is het protocol achter de aanpassing, en het heeft zijn eigen pad nodig zoals elke andere dienst.

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

Er is ook een probleem met de opstartvolgorde: een sterk verkeerde klok kan een geauthenticeerde tunnel verhinderen, en de enige bruikbare tijdbron kan achter die tunnel liggen. Een beheerde vloot heeft een gedocumenteerde procedure voor die toestand nodig, en het omzeilen van certificaatverificatie is dat niet. Op een persoonlijk apparaat, gebruik de eigen tijdinstellingen van het besturingssysteem en zoek uit waarom de klok verloren gaat na afsluiten of herstellen. Een machine die bij elke opstart drift, heeft een hardware- of configuratieprobleem, geen VPN-probleem.

Probeer na de reparatie de oorspronkelijke verbinding opnieuw en lees de nieuwe fout apart. Een slechte serveridentiteit, een certificaat dat echt is verlopen en een geweigerd account zijn drie verschillende fouten, en ze door elkaar halen is hoe een eenvoudige klokcorrectie een week vol profielwissels wordt.