Un rellotge incorrecte pot aturar la VPN: comproveu l’hora primer

La VPN deixa de connectar-se, el registre esmenta un certificat i el primer impuls és substituir el perfil. Un rellotge del dispositiu que va uns minuts o unes hores desviat produeix exactament aquest error, perquè la validesa del certificat es jutja contra l’instant local. L’etiqueta de zona horària de la pantalla no és el problema; ho és l’hora subjacent. Comproveu el rellotge abans de tocar cap material del certificat.

L’error sembla un problema de certificat, no un problema de rellotge

L’apretada de mans TLS falla quan el certificat de l’altre extrem cau fora de la seva finestra de validesa respecte del rellotge del verificador. Aquesta comprovació s’executa al client, així que un rellotge de client incorrecte rebutja un certificat perfectament bo. El text de l’error anomena el certificat, i per això la gent el substitueix i torna a veure la mateixa fallada. El rellotge és la hipòtesi més barata i cal provar-la primer.

Un rellotge avançat respecte del temps real rebutja un certificat vigent com a caducat; un rellotge endarrerit rebutja un de més nou com a encara no vàlid. Tots dos missatges apunten a dates, i tots dos es produeixen sense cap contacte amb l’autoritat de certificació. Aquesta és la pista: una caducitat real afecta tots els clients, mentre que un problema de rellotge afecta l’única màquina amb l’hora incorrecta.

Llegiu l’instant i després el certificat

Imprimiu el rellotge en UTC i les dates pròpies del certificat abans de canviar res. Comparar dos instants absoluts elimina del tot la qüestió de la zona horària de la investigació. Si la finestra del certificat conté l’instant actual, el certificat no és la vostra fallada.

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

Si el rellotge local va malament, comproveu si està sincronitzat i amb què. Una màquina amb la sincronització desactivada, o amb una font d’hora que no pot assolir, deriva fins que alguna cosa falla. La sortida d’estat anomena la font i l’últim ajust correcte, cosa més útil que el desviament actual tot sol. Un desviament gran sense cap font configurada és un problema diferent d’un desviament petit contra una font que funciona.

timedatectl timesync-status
chronyc tracking

Atureu-vos si el certificat ha caducat de debò per a tots els clients. Aleshores el rellotge està bé i el certificat necessita renovació, no ajust.

Els codis d’accés fallen per una raó relacionada però diferent

Les contrasenyes d’un sol ús basades en el temps treuen el valor del pas de temps actual, normalment trenta segons. Un dispositiu amb el rellotge desviat més d’un pas o dos produeix codis que el servidor no acceptarà, encara que l’usuari hagi escrit els dígits correctes. L’error sembla una contrasenya incorrecta, cosa que porta la gent a un bucle de restabliment que no pot arreglar un rellotge.

Esbrineu quin component ha rebutjat l’intent, perquè el client de VPN, la passarel·la i el proveïdor d’identitat informen d’etapes diferents. Si es rebutja el codi però s’accepta la contrasenya, el compte probablement està bé i el sospitós és el rellotge. Si es rebutgen tots dos, el compte pot estar bloquejat i el rellotge és una pista falsa. Seguiu les indicacions de recuperació del proveïdor en lloc d’aprovar peticions que no heu iniciat.

No enrereu el rellotge per fer funcionar un codi. Amaga la causa i trenca la propera comprovació basada en el temps.

Arregleu la font, no l’hora mostrada

La sincronització és un servei de xarxa, i el túnel pot canviar si la font d’hora és abastable. Una font corporativa pot requerir el túnel, mentre que una font pública pot estar bloquejada per la política. La navegació pot funcionar mentre la ruta pròpia del servei d’hora falla, i per això aquesta dependència és fàcil de passar per alt. NTP és el protocol que hi ha darrere de l’ajust, i necessita la seva pròpia ruta com qualsevol altre servei.

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

També hi ha un problema d’ordre d’arrencada: un rellotge molt incorrecte pot impedir un túnel autenticat, i l’única font d’hora utilitzable pot estar darrere d’aquell túnel. Una flota gestionada necessita un procediment documentat per a aquest estat, i saltar-se la verificació del certificat no ho és. En un dispositiu personal, feu servir els controls d’hora propis del sistema operatiu i esbrineu per què es perd el rellotge després d’apagar o restaurar. Una màquina que deriva a cada arrencada té un problema de maquinari o de configuració, no un problema de VPN.

Després de la reparació, torneu a provar la connexió original i llegiu el nou error per separat. Una identitat de servidor dolenta, un certificat que realment ha caducat i un compte rebutjat són tres fallades diferents, i barrejar-les és com una simple correcció de rellotge es converteix en una setmana de canvis de perfil.