Relógio errado no dispositivo pode parar a VPN: verifique a hora primeiro

A VPN deixa de conectar, o log menciona um certificado e o primeiro impulso é substituir o perfil. Um relógio do dispositivo adiantado ou atrasado em minutos ou horas produz exatamente esse erro, porque a validade do certificado é julgada contra o instante local. O rótulo do fuso horário no ecrã não é o problema; a hora subjacente é. Verifique o relógio antes de tocar em qualquer material do certificado.

O erro parece um problema de certificado, não de relógio

O aperto de mão TLS falha quando o certificado da outra parte fica fora da sua janela de validade em relação ao relógio do verificador. Essa verificação corre no cliente, portanto um relógio de cliente errado rejeita um certificado perfeitamente bom. O texto do erro nomeia o certificado, e é por isso que as pessoas o substituem e veem a mesma falha de novo. O relógio é a hipótese mais barata e deve ser testado primeiro.

Um relógio adiantado em relação ao tempo real rejeita um certificado atual como expirado; um relógio atrasado rejeita um mais novo como ainda não válido. Ambas as mensagens apontam para datas, e ambas são produzidas sem qualquer contacto com a autoridade certificadora. Essa é a pista: uma expiração real afeta todos os clientes, enquanto um problema de relógio afeta a única máquina com a hora errada.

Leia o instante, depois o certificado

Imprima o relógio em UTC e as datas do próprio certificado antes de mudar qualquer coisa. Comparar dois instantes absolutos elimina por completo a questão do fuso horário da investigação. Se a janela do certificado contém o instante atual, o certificado não é a sua falha.

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 relógio local estiver errado, verifique se está sincronizado e com o quê. Uma máquina com a sincronização desativada, ou com uma fonte de hora que não consegue alcançar, deriva até que algo falhe. A saída de estado nomeia a fonte e o último ajuste bem-sucedido, o que é mais útil do que o desvio atual sozinho. Um desvio grande sem fonte configurada é um problema diferente de um desvio pequeno contra uma fonte que funciona.

timedatectl timesync-status
chronyc tracking

Pare se o certificado realmente expirou para todos os clientes. Então o relógio está certo e o certificado precisa de renovação, não de ajuste.

Os códigos de acesso falham por uma razão relacionada mas diferente

As palavras-passe de uso único baseadas em tempo derivam o seu valor do passo de tempo atual, geralmente trinta segundos. Um dispositivo cujo relógio está desviado mais de um ou dois passos produz códigos que o servidor não aceitará, mesmo que o utilizador tenha escrito os dígitos certos. O erro parece uma palavra-passe errada, o que empurra as pessoas para um ciclo de reposição que não consegue corrigir um relógio.

Descubra que componente rejeitou a tentativa, porque o cliente de VPN, a gateway e o fornecedor de identidade relatam fases diferentes. Se o código for rejeitado mas a palavra-passe aceite, a conta provavelmente está bem e o relógio é o suspeito. Se ambos forem rejeitados, a conta pode estar bloqueada e o relógio é uma pista falsa. Siga as orientações de recuperação do fornecedor em vez de aprovar pedidos que não iniciou.

Não atrase o relógio para fazer um código funcionar. Isso esconde a causa e quebra a verificação seguinte baseada em tempo.

Corrija a fonte, não a hora exibida

A sincronização é um serviço de rede, e o túnel pode mudar se a fonte de hora é alcançável. Uma fonte empresarial pode exigir o túnel, enquanto uma fonte pública pode estar bloqueada por política. A navegação pode funcionar enquanto o caminho próprio do serviço de hora falha, e é por isso que esta dependência passa facilmente despercebida. NTP é o protocolo por trás do ajuste, e precisa do seu próprio caminho como qualquer outro serviço.

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

Há também um problema de ordem de arranque: um relógio muito errado pode impedir um túnel autenticado, e a única fonte de hora utilizável pode estar atrás desse túnel. Uma frota gerida precisa de um procedimento documentado para esse estado, e contornar a verificação do certificado não é um. Num dispositivo pessoal, use os controlos de hora do sistema operativo e descubra porque é que o relógio se perde após desligar ou restaurar. Uma máquina que deriva em cada arranque tem um problema de hardware ou de configuração, não um problema de VPN.

Após a reparação, tente novamente a ligação original e leia o novo erro em separado. Uma identidade de servidor má, um certificado que realmente expirou e uma conta rejeitada são três falhas diferentes, e misturá-las é como uma simples correção de relógio se torna uma semana de trocas de perfil.