Caduta oraria di OpenVPN: rinegoziazione o una vera riconnessione?

Sessanta minuti, o trenta, o centoventi: una caduta che arriva su un intervallo tondo quasi mai è la rete. OpenVPN rinnova secondo un timer il materiale di chiavi che protegge il canale dati, e un timer più corto di quello che davate per scontato sembra esattamente un collegamento che fallisce di continuo. Gli utenti segnalano una connessione rotta mentre il log segnala uno scambio di chiavi riuscito. La guida qui sotto separa quel rinnovo da un vero riavvio, legge il valore realmente in vigore e lo cambia solo dopo che il costo è sul tavolo.

Seguite i passi in ordine, perché il primo decide se il resto della pagina vi riguarda davvero. Saltate avanti e passerete una serata a regolare un timer per un guasto che non ha nulla a che vedere con esso.

Distinguete un riavvio morbido da un riavvio

La riga di log è tutta la diagnosi. Una rinegoziazione scrive un riavvio morbido e poi uno scambio di chiavi nuovo dentro lo stesso tunnel: l’interfaccia conserva il suo indirizzo, le rotte non vengono riaggiunte e le sessioni TCP stabilite di solito sopravvivono con una pausa. Un vero riavvio strappa la sessione, ricostruisce l’interfaccia, può assegnare un altro indirizzo di client e uccide ogni connessione di lunga durata. Entrambi gli eventi sono ordinari; solo uno spiega una chiamata caduta.

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'soft reset|Connection reset|reneg|TLS Error'
openvpn --version | head -n 1

La riga della versione conta perché la formulazione del log cambia tra le release, e un messaggio che ricordate dal 2.3 può essere formulato diversamente nel 2.6. Leggete il vostro log invece di un estratto di forum di qualcun altro. Citare la riga esatta quando chiedete aiuto, perché una parafrasi perde il dettaglio che identifica l’evento. Se l’indirizzo dell’interfaccia non cambia durante l’evento e la lista delle sessioni sopravvive, state guardando un rinnovo e le sezioni restanti si applicano.

Leggete il timer effettivo, non il vostro file

reneg-sec è il numero di secondi tra le rinegoziazioni del canale dati e il suo valore predefinito è 3600. Ogni peer porta il proprio valore, e il minore dei due è quello che innesca davvero il rinnovo. Quella singola regola spiega la maggior parte delle segnalazioni: un profilo client che imposta un numero grande viene comunque reimpostato ogni ora mentre il server mantiene il valore predefinito.

grep -Rn --include='*.conf' -E 'reneg-sec|reneg-bytes' /etc/openvpn
# server side, including included files
grep -Rn -E '^reneg-sec' /etc/openvpn/server/

Leggete anche la configurazione effettiva del server, compreso tutto ciò che spinge, prima di trarre conclusioni dal file del client. Poi alzate la verbosità e osservate un intervallo dall’inizio alla fine: il livello 3 mostra già le righe di rinegoziazione, e le marche temporali dicono se l’evento si ripete ogni 3600 secondi o segue invece l’attività.

Cambiatelo dove viene davvero spinto

Il rimedio che circola è una sola riga nel profilo del client, ed è il posto sbagliato circa metà delle volte. Poiché vince il valore più basso dei peer, un client che mette il timer a zero può ancora essere rinegoziato da un server che non è cambiato.

# on both ends, or on the side that owns the pushed configuration
reneg-sec 0

Dove i profili sono generati centralmente, modificate il modello e non la copia distribuita, altrimenti la prossima esecuzione di provisioning ripristinerà il valore appena rimosso. Verificate osservando due intervalli, non uno: un’ora tranquilla è compatibile anche con un timer impostato a 7200.

Decidete anche cosa succede in un rilascio misto. Se distribuite la modifica prima ai client, resta una finestra in cui il server innesca ancora il rinnovo; è innocuo ma confonde se state guardando i log per conferma. Cambiate prima il lato che ha il valore minore e il sintomo scompare nel punto che vi aspettate.

A cosa rinunciate disattivando la rinegoziazione

La rinegoziazione regolare limita per quanto tempo un solo insieme di chiavi del canale dati protegge il traffico. Spegnere il timer non rompe il tunnel, e su un router domestico o un gateway di piccolo ufficio l’esposizione pratica è modesta. È comunque uno scambio, e vale la pena dichiararlo prima di farlo. Ciò che cambia è per quanto tempo un insieme di chiavi protegge una sessione, non se il tunnel funziona affatto.

Il caso ragionevole per disattivarlo è un riavvio che rompe qualcosa che non può riprendere: una chiamata che cade, una sessione di desktop remoto da ristabilire, un backup che riparte dall’inizio. Se la pausa è invisibile agli utenti, mantenere il valore predefinito non costa nulla e conserva la rotazione delle chiavi che vi è stata data.

Preferite correggere la causa quando lo schema lo consente. Un rinnovo che fallisce a metà mentre il primo handshake è riuscito punta al percorso e non al timer: cercate un problema di dimensione dei pacchetti nello scambio più grande del canale di controllo, un firewall con stato che scarta il flusso, o una proposta che riesce solo al primo tentativo. Ognuno di questi lascia una traccia nello stesso log che avete appena letto. Disattivare il timer nasconde quella prova.

Quando l’intervallo punta altrove

Due vicini nella configurazione producono sintomi simili e correzioni diverse. ping-restart riavvia il tunnel quando non arriva nulla per un periodo configurato, mentre ping-exit abbatte del tutto il client. Una caduta in inattività senza alcuna rinegoziazione nel log appartiene a questi, o a un dispositivo NAT che ha lasciato scadere la mappatura UDP secondo il proprio calendario.

I router di consumo, gli hotspot mobili e il NAT di livello operatore lasciano scadere le sessioni UDP inattive senza avvisare nessuno. Quel guasto segue l’inattività e non l’orologio, e questo è l’indizio: una sessione che cade dopo dieci minuti tranquilli e sopravvive un’ora di traffico costante non sta rinegoziando.

Annotate tre cose prima di cambiarne una quarta: l’intervallo misurato, il valore effettivo trovato e il comando che l’ha mostrato. Se l’intervallo si sposta quando si sposta il timer, il meccanismo è identificato e la correzione è una decisione sullo scambio di sopra. Se non si sposta, rimettete l’impostazione e continuate a guardare keepalive, stato del NAT e perdita di pacchetti.