Come verificare se un tunnel VPN su Linux è davvero attivo

Cron riavvia ogni dieci minuti un VPN perfettamente sano, e lo stesso compito lascia uno morto in funzione per una settimana. Entrambi i guasti nascono dal trattare «attivo» come un fatto unico quando ne vale almeno quattro. Un dispositivo può essere abilitato amministrativamente, instradato correttamente, cifrato del tutto e comunque non trasportare nulla di utile. Separate prima le osservazioni, e la verifica si scrive quasi da sola.

I flag del collegamento descrivono il dispositivo, non il percorso

La verifica che tutti copiano cerca un indirizzo hardware di soli zeri. Quel trucco separa un'interfaccia vera da un segnaposto in alcuni driver e non dimostra nulla negli altri, perché un dispositivo tun non ha alcun MAC da riportare. ip -brief link show tun0 offre invece dei flag: UP significa che un amministratore ha abilitato il dispositivo, e LOWER_UP significa che il driver considera il collegamento utilizzabile. Letti insieme, dicono che il dispositivo esiste e non è amministrativamente spento. Nessuno dei due dice che un pacchetto abbia dove andare.

OpenVPN crea il proprio dispositivo tun prima che le rotte siano installate, quindi i flag possono sembrare perfetti mentre nulla è instradato. Trattateli come una precondizione, mai come la risposta.

Chiedete dove andrebbe un pacchetto

La ricerca di rotta risponde alla domanda che i flag non possono. ip route get 10.8.0.1 from 10.8.0.2 nomina l'interfaccia, l'indirizzo di origine e la tabella che il kernel userebbe, ed è esattamente ciò contro cui un tunnel diviso deve essere verificato. Senza l'indirizzo di origine state chiedendo altro, e con l'instradamento basato su politiche la risposta può variare per origine. È la prova onesta più economica, perché consulta le stesse regole che userà il vostro traffico.

Per WireGuard, aggiungete lo handshake. wg show stampa una marca temporale dell'ultimo handshake per peer, e una marca che ha smesso di avanzare significa che il peer è sparito, qualunque cosa dicano i flag dell'interfaccia. Un'interfaccia configurata senza handshake recente è uno dei falsi positivi più comuni nel monitoraggio fatto in casa.

La tabella 220 racconta la storia di IPsec

strongSwan installa le rotte per i selettori negoziati nella tabella 220 quando l'installazione delle rotte è abilitata. ip route list table 220 quindi separa il negoziato dall'instradato: una tabella vuota accanto a una connessione caricata significa che le SA IKE e CHILD sono salite mentre nessun traffico vi è diretto. Verificate ip xfrm state accanto, poiché elenca le associazioni di sicurezza installate e i loro endpoint.

Una politica trappola è il caso a cui fare attenzione. Attende traffico interessante invece di instradarlo, così la tabella resta vuota finché qualcosa non avvia il tunnel.

Lo stato del gestore e lo stato del demone sono elenchi diversi

NetworkManager elenca solo le connessioni che possiede. nmcli -t -f NAME,TYPE connection show --active non restituisce nulla per un tunnel avviato direttamente da wg-quick o da un demone OpenVPN.

Questa distinzione conta quando uno script deve decidere a quale dei due gestori chiedere. Scegliete quello che possiede davvero il tunnel su questo host e ignorate il silenzio dell'altro. Se esistono entrambi, decidete quale è autorevole e disattivate il secondo, perché due gestori che riscrivono rotte su una sola interfaccia producono guasti che nessuno può riprodurre. Una voce assente è informazione sul gestore, non sul tunnel.

Vincolate il passo successivo alla sonda che gli serve

Sondare una porta UDP non dimostra nulla sulla prontezza, perché UDP non ha handshake e nc -u riesce appena il pacchetto esce. Sondate ciò che il passo successivo consuma davvero: una connessione TCP alla porta inoltrata, una richiesta a un host dentro il tunnel, un nome che si risolve solo lì. Limitate l'attesa con un timeout e un numero di tentativi, e fallite rumorosamente quando si esaurisce.

Gli hook battono il sondaggio quando il client li offre. --up e --down gli script di OpenVPN vengono eseguiti dopo che l'interfaccia cambia stato, il che elimina del tutto la corsa, ma girano con i privilegi che il demone ha trattenuto. Se OpenVPN è sceso a un account non privilegiato tramite user e group, l'hook gira come quell'account. Riavviare un servizio di sistema richiede allora sudo per consentire esattamente quel comando. Affidate il nuovo tentativo al gestore dei servizi invece che a un ciclo cron: una politica di riavvio limitata con un limite di avvii fa emergere un tunnel rotto, mentre un ciclo illimitato lo nasconde all'infinito.