Un orologio del dispositivo sbagliato può fermare la VPN: controllate prima l’ora

La VPN smette di connettersi, il registro menziona un certificato e il primo istinto è sostituire il profilo. Un orologio del dispositivo sbagliato di minuti o ore produce esattamente quell’errore, perché la validità del certificato è giudicata rispetto all’istante locale. L’etichetta del fuso orario sullo schermo non è il problema; lo è l’ora sottostante. Controllate l’orologio prima di toccare qualsiasi materiale del certificato.

L’errore sembra un problema di certificato, non di orologio

L’handshake TLS fallisce quando il certificato dell’altra parte cade fuori dalla sua finestra di validità rispetto all’orologio del verificatore. Quel controllo gira sul client, quindi un orologio client sbagliato rifiuta un certificato perfettamente valido. Il testo dell’errore nomina il certificato, ed è per questo che le persone lo sostituiscono e rivedono lo stesso guasto. L’orologio è l’ipotesi meno costosa e va verificata per prima.

Un orologio avanti rispetto al tempo reale rifiuta un certificato corrente come scaduto; un orologio indietro rifiuta uno più recente come non ancora valido. Entrambi i messaggi indicano date, ed entrambi vengono prodotti senza alcun contatto con l’autorità di certificazione. Questo è l’indizio: una vera scadenza colpisce ogni client, mentre un problema di orologio colpisce l’unica macchina con l’ora sbagliata.

Leggete l’istante, poi il certificato

Stampate l’orologio in UTC e le date del certificato stesso prima di cambiare qualcosa. Confrontare due istanti assoluti elimina del tutto la questione del fuso orario dall’indagine. Se la finestra del certificato contiene l’istante attuale, il certificato non è il vostro guasto.

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 l’orologio locale è sbagliato, controllate se è sincronizzato e con cosa. Una macchina con la sincronizzazione disattivata, o con una fonte di tempo che non riesce a raggiungere, deriva finché qualcosa non fallisce. L’output di stato nomina la fonte e l’ultimo aggiustamento riuscito, che è più utile del solo scostamento attuale. Uno scostamento grande senza fonte configurata è un problema diverso da uno scostamento piccolo rispetto a una fonte funzionante.

timedatectl timesync-status
chronyc tracking

Fermatevi se il certificato è davvero scaduto per ogni client. Allora l’orologio è a posto e il certificato ha bisogno di un rinnovo, non di un aggiustamento.

I codici di accesso falliscono per una ragione correlata ma diversa

Le password monouso basate sul tempo derivano il loro valore dal passo di tempo corrente, di solito trenta secondi. Un dispositivo il cui orologio è sfasato di più di un passo o due produce codici che il server non accetterà, anche se l’utente ha digitato le cifre giuste. L’errore sembra una password sbagliata, cosa che spinge le persone in un ciclo di reimpostazione che non può riparare un orologio.

Capite quale componente ha rifiutato il tentativo, perché il client VPN, il gateway e il provider di identità riportano fasi diverse. Se il codice viene rifiutato ma la password accettata, l’account è probabilmente a posto e l’orologio è il sospetto. Se entrambi vengono rifiutati, l’account può essere bloccato e l’orologio è una pista falsa. Seguite le indicazioni di recupero del provider invece di approvare richieste che non avete avviato.

Non riportate indietro l’orologio per far funzionare un codice. Nasconde la causa e rompe il successivo controllo basato sul tempo.

Riparate la fonte, non l’ora visualizzata

La sincronizzazione è un servizio di rete, e il tunnel può cambiare se la fonte di tempo è raggiungibile. Una fonte aziendale può richiedere il tunnel, mentre una fonte pubblica può essere bloccata da una policy. La navigazione può funzionare mentre il percorso proprio del servizio di tempo fallisce, ed è per questo che questa dipendenza sfugge facilmente. NTP è il protocollo dietro l’aggiustamento, e ha bisogno del proprio percorso come qualsiasi altro servizio.

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

C’è anche un problema di ordine di avvio: un orologio molto sbagliato può impedire un tunnel autenticato, e l’unica fonte di tempo utilizzabile può stare dietro quel tunnel. Una flotta gestita ha bisogno di una procedura documentata per quello stato, e aggirare la verifica del certificato non lo è. Su un dispositivo personale, usate i controlli dell’ora del sistema operativo e scoprite perché l’orologio si perde dopo lo spegnimento o il ripristino. Una macchina che deriva a ogni avvio ha un problema hardware o di configurazione, non un problema di VPN.

Dopo la riparazione, riprovate la connessione originale e leggete separatamente il nuovo errore. Un’identità del server scadente, un certificato davvero scaduto e un account rifiutato sono tre guasti diversi, e mescolarli è il modo in cui una semplice correzione dell’orologio diventa una settimana di cambi di profilo.