Un reloxo incorrecto pode deter a VPN: revise a hora primeiro

A VPN deixa de conectar, o rexistro menciona un certificado e o primeiro impulso é substituír o perfil. Un reloxo do dispositivo desviado minutos ou horas produce exactamente ese erro, porque a validez do certificado xúlgase contra o instante local. A etiqueta de zona horaria na pantalla non é o problema; a hora subxacente si. Revise o reloxo antes de tocar calquera material do certificado.

O erro parece un problema de certificado, non un problema de reloxo

O saúdo TLS falla cando o certificado da outra parte queda fóra da súa xanela de validez respecto do reloxo do verificador. Ese comprobación execútase no cliente, así que un reloxo de cliente incorrecto rexeita un certificado perfectamente bo. O texto do erro nomea o certificado, e por iso a xente substitúeo e volve ver o mesmo fallo. O reloxo é a hipótese máis barata e debería probarse primeiro.

Un reloxo adiantado respecto do tempo real rexeita un certificado vixente como caducado; un reloxo atrasado rexeita un máis novo como aínda non válido. Ambas mensaxes apuntan a datas, e ambas se producen sen ningún contacto coa autoridade de certificación. Esa é a pista: unha caducidade real afecta todos os clientes, mentres que un problema de reloxo afecta a única máquina coa hora incorrecta.

Lea o instante e despois o certificado

Imprima o reloxo en UTC e as datas propias do certificado antes de cambiar nada. Comparar dous instantes absolutos elimina por completo a cuestión da zona horaria da investigación. Se a xanela do certificado contén o instante actual, o certificado non é o seu 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

Se o reloxo local está mal, comprobe se está sincronizado e con que. Unha máquina coa sincronización desactivada, ou cunha fonte de hora que non pode acadar, deriva ata que algo falla. A saída de estado nomea a fonte e o último axuste correcto, o que é máis útil que o desvío actual por si só. Un desvío grande sen fonte configurada é un problema distinto dun desvío pequeno contra unha fonte que funciona.

timedatectl timesync-status
chronyc tracking

Deterase se o certificado caducou de verdade para todos os clientes. Entón o reloxo está ben e o certificado necesita renovación, non axuste.

Os códigos de acceso fallan por unha razón relacionada pero distinta

Os contrasinais dun só uso baseados no tempo derivan o seu valor do paso de tempo actual, normalmente trinta segundos. Un dispositivo cuxo reloxo se desvía máis dun paso ou dous produce códigos que o servidor non aceptará, aínda que o usuario escribise os díxitos correctos. O erro parece un contrasinal incorrecto, o que empuxa a xente a un bucle de restablecemento que non pode arranxar un reloxo.

Averigüe que compoñente rexeitou o intento, porque o cliente de VPN, a pasarela e o provedor de identidade informan de etapas distintas. Se se rexeita o código pero se acepta o contrasinal, a conta probablemente está ben e o reloxo é o sospeitoso. Se se rexeitan ambos, a conta pode estar bloqueada e o reloxo é unha pista falsa. Siga as indicacións de recuperación do provedor en lugar de aprobar solicitudes que vostede non iniciou.

Non atrase o reloxo para que funcione un código. Oculta a causa e rompe a seguinte comprobación baseada no tempo.

Arranxe a fonte, non a hora mostrada

A sincronización é un servizo de rede, e o túnel pode cambiar se a fonte de hora é accesible. Unha fonte corporativa pode requirir o túnel, mentres que unha fonte pública pode estar bloqueada pola política. A navegación pode funcionar mentres a ruta propia do servizo de hora falla, e por iso esta dependencia pasa desapercibida con facilidade. NTP é o protocolo que hai detrás do axuste, e necesita a súa propia ruta como calquera outro servizo.

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

Tamén hai un problema de orde de arranque: un reloxo moi incorrecto pode impedir un túnel autenticado, e a única fonte de hora utilizábel pode estar detrás dese túnel. Unha frota xestionada necesita un procedemento documentado para ese estado, e saltar a verificación do certificado non o é. Nun dispositivo persoal, use os controis de hora propios do sistema operativo e descubra por que se perde o reloxo tras apagar ou restaurar. Unha máquina que deriva en cada arranque ten un problema de hardware ou de configuración, non un problema de VPN.

Tras a reparación, tente de novo a conexión orixinal e lea o novo erro por separado. Unha identidade de servidor defectuosa, un certificado que realmente caducou e unha conta rexeitada son tres fallos distintos, e mesturalos é como unha simple corrección do reloxo se converte nunha semana de cambios de perfil.