Monitorare una VPN del router senza fidarsi di una sola spia di stato

La pagina di stato dice connesso, la spia è verde e l'ufficio non raggiunge il file server. Uno di questi fatti riguarda il tunnel e l'altro il percorso che lo attraversa. Monitorare entrambi è la differenza tra un avviso su cui potete agire e uno che imparate a ignorare.

Cinque controlli, in ordine, dal peer verso l'esterno.

Controllo 1: stato del peer o dell'associazione

Ogni protocollo espone il proprio stato. WireGuard mostra l'ultimo handshake e i contatori di trasferimento per peer tramite wg show. OpenVPN scrive lo stato della sessione nel file di stato o nell'interfaccia di gestione, e IPsec espone le associazioni di sicurezza tramite strumenti come ipsec statusall. La trappola è leggere un timestamp come verdetto: un peer WireGuard inattivo senza nulla da inviare non farà un handshake recente, e non è un'interruzione.

Confrontate il timestamp con il traffico atteso e le impostazioni keepalive prima di chiamare qualcuno.

Controllo 2: la rotta selezionata

Un'interfaccia tunnel può esistere mentre nulla vi viene instradato. Controllate la tabella di inoltro per la destinazione che vi interessa, non per la sottorete del tunnel stesso. Se il prefisso manca o punta altrove, lo stato del peer è irrilevante.

Quel controllo intercetta il guasto che una spia di stato non mostra mai.

Un secondo controllo utile confronta anche l'indirizzo di origine. ip route get 10.20.5.10 restituisce il salto successivo, l'interfaccia e l'origine preferita, e un'origine sbagliata basta a rompere il traffico di ritorno all'estremità remota. Annotate la terna attesa una volta, poi allarmate quando un elemento cambia. Quella singola riga intercetta cambi di NAT, instabilità dell'interfaccia ed errori di instradamento basato su policy.

Controllo 3: un percorso applicativo consentito

Provate qualcosa che rappresenti il requisito reale. Un ping originato dal router parte dall'indirizzo e dalla policy del router stesso, che possono differire dal traffico LAN inoltrato, e molti host limitano ICMP. Se il requisito è un servizio privato, provate quel servizio sulla sua porta reale.

Mantenete modesto il volume della sonda. Un ciclo di monitoraggio non deve diventare il traffico che misura.

Controllo 4: cosa è cambiato e quando

Correlate cambi WAN, rinnovi di chiavi, ritiri di rotte e guasti applicativi su un'unica linea temporale. Distinguete un guasto del tunnel da una rotta di riserva che ripristina in silenzio l'accesso Internet ordinario, perché entrambi producono segnalazioni utente identiche e diagnosi opposte. Gli errori di fuso orario invertiranno l'ordine, quindi normalizzate prima di confrontare. La linea temporale è ciò che trasforma quattro controlli in una causa.

Conservate i log per le transizioni, non per il payload.

Controllo 5: l'allarme deve nominare il confine

Un allarme che dice VPN giù manda qualcuno nel posto sbagliato metà delle volte. Uno che dice handshake del peer scaduto da dodici minuti, rotta verso 10.20.0.0/16 assente o sonda sulla porta 445 fallita indica un controllo specifico.

Tenete contatori operativi invece di sfogliare payload. I contatori rispondono alla domanda di monitoraggio senza raccogliere contenuti che non vi servono.

E lasciate che la policy di commutazione decida cosa succede dopo. Il monitoraggio deve identificare quale confine ha fallito, non autorizzare un aggiramento ampio ogni volta che una sonda fallisce. Il manuale di OpenVPN 2.6 documenta il file di stato e l'interfaccia di gestione che rendono il primo controllo programmabile.