Un reloj incorrecto puede detener la VPN: revise la hora primero

La VPN deja de conectarse, el registro menciona un certificado y el primer impulso es reemplazar el perfil. Un reloj del dispositivo desviado minutos u horas produce exactamente ese error, porque la validez del certificado se juzga contra el instante local. La etiqueta de zona horaria en pantalla no es el problema; la hora subyacente lo es. Revise el reloj antes de tocar cualquier material del certificado.

El error parece un problema de certificado, no un problema de reloj

El saludo TLS falla cuando el certificado del otro extremo queda fuera de su ventana de validez respecto del reloj del verificador. Esa comprobación se ejecuta en el cliente, así que un reloj de cliente incorrecto rechaza un certificado perfectamente bueno. El texto del error nombra el certificado, y por eso la gente lo reemplaza y vuelve a ver el mismo fallo. El reloj es la hipótesis más barata y debería probarse primero.

Un reloj adelantado respecto del tiempo real rechaza un certificado vigente como caducado; un reloj atrasado rechaza uno más nuevo como aún no válido. Ambos mensajes apuntan a fechas, y ambos se producen sin ningún contacto con la autoridad de certificación. Esa es la pista: una caducidad real afecta a todos los clientes, mientras que un problema de reloj afecta a la única máquina con la hora incorrecta.

Lea el instante y luego el certificado

Imprima el reloj en UTC y las fechas propias del certificado antes de cambiar nada. Comparar dos instantes absolutos elimina por completo la cuestión de la zona horaria de la investigación. Si la ventana del certificado contiene el instante actual, el certificado no es su fallo.

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 reloj local está mal, compruebe si está sincronizado y con qué. Una máquina con la sincronización desactivada, o con una fuente de hora que no puede alcanzar, deriva hasta que algo falla. La salida de estado nombra la fuente y el último ajuste correcto, lo que resulta más útil que la desviación actual por sí sola. Una desviación grande sin fuente configurada es un problema distinto de una desviación pequeña contra una fuente que funciona.

timedatectl timesync-status
chronyc tracking

Deténgase si el certificado ha caducado de verdad para todos los clientes. Entonces el reloj está bien y el certificado necesita renovación, no ajuste.

Los códigos de acceso fallan por una razón relacionada pero distinta

Las contraseñas de un solo uso basadas en el tiempo derivan su valor del paso de tiempo actual, normalmente treinta segundos. Un dispositivo cuyo reloj se desvía más de un paso o dos produce códigos que el servidor no aceptará, aunque el usuario haya escrito los dígitos correctos. El error parece una contraseña incorrecta, lo que empuja a la gente a un bucle de restablecimiento que no puede arreglar un reloj.

Averigüe qué componente rechazó el intento, porque el cliente de VPN, la puerta de enlace y el proveedor de identidad informan de etapas distintas. Si se rechaza el código pero se acepta la contraseña, la cuenta probablemente está bien y el reloj es el sospechoso. Si se rechazan ambos, la cuenta puede estar bloqueada y el reloj es una pista falsa. Siga las indicaciones de recuperación del proveedor en lugar de aprobar solicitudes que usted no inició.

No atrase el reloj para que funcione un código. Oculta la causa y rompe la siguiente comprobación basada en el tiempo.

Arregle la fuente, no la hora mostrada

La sincronización es un servicio de red, y el túnel puede cambiar si la fuente de hora es accesible. Una fuente corporativa puede requerir el túnel, mientras que una fuente pública puede estar bloqueada por la política. La navegación puede funcionar mientras la ruta propia del servicio de hora falla, y por eso esta dependencia se pasa por alto con facilidad. NTP es el protocolo que hay detrás del ajuste, y necesita su propia ruta como cualquier otro servicio.

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

También hay un problema de orden de arranque: un reloj muy incorrecto puede impedir un túnel autenticado, y la única fuente de hora utilizable puede estar detrás de ese túnel. Una flota gestionada necesita un procedimiento documentado para ese estado, y saltarse la verificación del certificado no lo es. En un dispositivo personal, use los controles de hora propios del sistema operativo y averigüe por qué se pierde el reloj tras apagar o restaurar. Una máquina que deriva en cada arranque tiene un problema de hardware o de configuración, no un problema de VPN.

Tras la reparación, reintente la conexión original y lea el nuevo error por separado. Una identidad de servidor defectuosa, un certificado que realmente caducó y una cuenta rechazada son tres fallos distintos, y mezclarlos es cómo una simple corrección del reloj se convierte en una semana de cambios de perfil.