L'età dell'handshake WireGuard non è un timeout di sessione

Un peer che smette di far passare traffico non perde per questo la sua chiave, e un handshake nuovo non dimostra che qualcuno abbia rinnovato il permesso di usarla. I timer di WireGuard mantengono le chiavi fresche e i pacchetti in movimento; non modellano un utente che esce dopo un numero fisso di minuti. Qui si confondono tre domande, e ciascuna ha prove diverse. La distinzione decide quale strumento si impugna.

Tre domande, un solo output di comando

Gli operatori chiedono se un peer è raggiungibile, se è stato attivo e se è ancora consentito. La prima è stato di protocollo, la seconda sono contatori di traffico e la terza è autorizzazione. Solo le prime due si leggono da un'interfaccia WireGuard, e vengono usate di routine per rispondere a tutte e tre.

Leggere le righe come tre indagini separate. Le prime due costano poco e si risolvono con i contatori dell'interfaccia stessa. La terza richiede la configurazione che concede l'accesso, che vive in un altro file o in un altro sistema. Scegliere la riga sbagliata significa chiedere a un timer di protocollo di fare il lavoro di una politica.

Che cosa governano davvero i timer

Il protocollo definisce costanti per il nuovo tentativo di handshake, la rotazione delle chiavi di trasporto e il rifiuto dei pacchetti protetti da una chiave vecchia. Rispondono al traffico e allo stato, non a un calendario né a una politica che dica che una persona può connettersi fino alle 17:00. Ecco perché un peer inattivo può sembrare fermo per ore e restare comunque autorizzato.

PersistentKeepalive viene spesso scambiato per il timeout mancante. Invia pacchetti vuoti autenticati per mantenere viva una mappatura NAT, e impostarlo a zero ferma quei pacchetti senza revocare nulla.

Leggere lo stato di esecuzione per peer, usando la chiave pubblica invece del commento:

wg show wg0 latest-handshakes
wg show wg0 transfer

Un handshake recente dice che un handshake è stato completato. Non dice che il servizio privato dietro il tunnel sia raggiungibile, e un timestamp vecchio può appartenere a un peer che è semplicemente silenzioso.

Perché un peer inattivo non è un peer disconnesso

WireGuard non ha un oggetto sessione con un inizio e una fine. Un peer è una chiave pubblica con indirizzi consentiti, e l'handshake che protegge il suo traffico viene sostituito quando serve senza alcun login visibile all'utente. Trattare l'assenza di traffico recente come una disconnessione rovescia il modello.

Se la lamentela vera è che una connessione fallisce dopo essere rimasta inattiva, la causa è di solito altrove: una mappatura NAT scaduta, un dispositivo che è andato in sospensione o un firewall che ha perso lo stato. Provare inviando traffico dal lato opposto e avviando un nuovo flusso, e confrontare che cosa cambia.

Mettere la scadenza dove vive l'autorizzazione

Se l'accesso deve finire a un'ora precisa, la scadenza appartiene a ciò che concede l'accesso. Un controller che emette configurazioni dei peer può richiedere un'approvazione rinnovata prima di consegnarne una nuova, e questa è una proprietà del controller e non un parametro nascosto sull'interfaccia.

Per i peer gestiti a mano, la rimozione deve arrivare in due posti: l'interfaccia in esecuzione e la configurazione salvata. Rimuovere il peer solo a runtime viene annullato da un riavvio o da un ciclo di riconciliazione, che ripristina l'identità che si credeva scaduta:

sudo wg set wg0 peer <public-key> remove
sudo wg-quick save wg0

Poi provare il confine invece dell'etichetta. Confermare che il peer viene rifiutato dopo la scadenza, confermare che il percorso di rinnovo funziona e confermare che lo stato sopravvive a un ricaricamento del gestore. L'età di un handshake è un segnale operativo utile, e non è un registro degli accessi.