OpenVPN cade dopo un rinnovo DHCP: conserva la rotta dell’endpoint

Il tunnel si connette, poi un rinnovo del lease sul collegamento di accesso lo uccide, e il log incolpa un timeout invece di una rotta. Nella configurazione VPN non è cambiato nulla, ed è proprio questo l’indizio: qualcosa fuori è cambiato. Un evento DHCP ha riscritto l’indirizzo o il gateway, e la rotta host che manteneva raggiungibile l’endpoint del tunnel ora punta a un salto successivo che non esiste più. È un problema di proprietà prima di essere un problema di routing.

Confronta il sintomo con le rotte mezzo predefinite

Con redirect-gateway def1, OpenVPN installa 0.0.0.0/1 e 128.0.0.0/1 invece di sostituire la rotta predefinita. Insieme quelle due coprono l’intero spazio degli indirizzi, e battono 0.0.0.0/0 solo per la lunghezza del prefisso. Perciò qualsiasi destinazione senza una corrispondenza più specifica entra nel tunnel.

L’endpoint ha bisogno di un’eccezione. OpenVPN aggiunge una rotta host verso l’indirizzo del server attraverso il gateway di accesso originale prima che entrino le mezzo predefinite, così i pacchetti incapsulati possono uscire. Quando quell’eccezione scompare, o mantiene un salto successivo che non esiste più, i pacchetti esterni del tunnel stesso corrispondono a una mezzo predefinita e vengono rispediti dentro il tunnel. Il risultato è una connessione che muore al successivo keepalive o handshake, senza nulla nel log che somigli a un errore di routing.

Conferma la forma della tabella prima di toccare qualsiasi altra cosa. ip route show dovrebbe elencare entrambe le metà più una rotta host per l’indirizzo del server; quando manca la rotta host, il resto dell’indagine ha un punto di partenza ovvio.

Perché le mezzo predefinite vincono senza cambiare metrica

Una metrica più bassa non batte un prefisso più lungo. Le rotte /1 vincono perché il kernel confronta prima la rotta più specifica, quindi alzare una metrica sulla rotta predefinita non cambia nulla su dove va il traffico diretto al tunnel. Inseguire le metriche è la svolta sbagliata più comune in questa diagnosi.

Controlla la selezione con ip route get 203.0.113.10, sostituendolo con l’indirizzo reale del server. La risposta nomina l’interfaccia e il salto successivo che il kernel userebbe davvero, il che è più informativo che leggere una tabella e ragionarci sopra.

Esegui quel comando prima che il tunnel parta, mentre è attivo e dopo l’evento di lease. Tre risposte da un solo comando, e il punto di divergenza diventa visibile.

Prendi tre istantanee, non una

Raccogli l’indirizzo di accesso, il gateway di accesso, la destinazione dell’endpoint, la rotta scelta e qualsiasi regola di policy in tre momenti: dopo che il collegamento di accesso è configurato, dopo che la VPN si connette e dopo l’evento di lease o dell’operatore. Ogni istantanea è una manciata di comandi, e hanno senso solo insieme. Una singola istantanea dopo il guasto registra lo stato invece della transizione. Scrivi i comandi in un piccolo script così ogni istantanea viene presa allo stesso modo.

Tieni le istantanee in un unico file con timestamp, perché la domanda interessante dopo è l’ordine. L’evento DHCP è arrivato prima o dopo che OpenVPN ha aggiornato la sua rotta? La risposta decide chi deve sistemarlo. Un timestamp da un orologio sbagliato è peggio di nessuno, quindi prendilo dall’host che possiede la tabella di routing.

Quando l’endpoint è configurato come nome invece che come indirizzo, risolvilo anche in ogni istantanea. Un cambio DNS sul collegamento di accesso può spostare l’endpoint senza che nessuna rotta venga toccata.

Decidi quale componente aggiorna l’eccezione

Su un sistema dhcpcd, gli hook vengono eseguiti dalla directory degli hook e dall’hook di uscita, e la modalità manager differisce per ampiezza dalla modalità per interfaccia. Qualunque cosa faccia l’hook, deve essere idempotente, perché i rinnovi possono arrivare a raffiche.

Il proprietario affidabile è l’integrazione che conosce già entrambi i lati: un network manager che gestisce la connessione VPN, o un’unità ordinata dopo che il collegamento di accesso sale. Una rotta statica aggiunta da un hook funziona fino al successivo cambio di gateway, poi fallisce esattamente allo stesso modo. Se usi comunque un hook, fallo leggere il gateway corrente a runtime invece di codificare quello che hai visto oggi.

Registra il proprietario dentro la configurazione. La prossima persona che esegue il debug di una riconnessione deve sapere che è un hook, non la VPN, a essere responsabile della rotta di eccezione.

Testa il ciclo di vita, non solo la riconnessione

Forza un rinnovo con dhcpcd -n eth0 o rilasciando e rinnovando il lease, poi controlla di nuovo ip route get per l’endpoint. Fallo due volte, perché la seconda passata intercetta gli hook che aggiungono rotte duplicate. Poi riavvia, perché la persistenza è una proprietà diversa dalla correttezza.

Un tunnel che sopravvive a un rinnovo e a un riavvio ha un proprietario e un’eccezione funzionante. Quello che sopravvive solo a un riavvio manuale non ha né l’uno né l’altra, e fallirà al prossimo evento che non puoi pianificare.