Perché un tunnel Azure OpenVPN cade all'incirca ogni sessanta secondi
Un tunnel che cade ogni sessanta secondi ha completato la stretta di mano, quindi nulla lo blocca. Leggi prima il motivo della disconnessione, poi confronta entrambi i timer keepalive.
Il tunnel completa la stretta di mano, trasporta traffico per circa un minuto e poi si riconnette. Questa sequenza esclude il sospetto abituale, perché un firewall che bloccasse la porta avrebbe fermato la stretta di mano e non la sessione. Quello che hai è un disaccordo sulla vitalità: un lato ha deciso che l'altro era ammutolito e ha abbattuto un tunnel funzionante. La riga del registro dice quale lato, ed è lei a scegliere la correzione.
Leggi quella riga prima di toccare qualsiasi timer.
Il mito: qualcosa sul percorso blocca il tunnel
Se una porta fosse bloccata, la connessione fallirebbe all'inizio e resterebbe fallita. Un ciclo che si ripete significa che i messaggi di controllo scorrono, che le sessioni si stabiliscono e che qualcosa più avanti nella conversazione continua a scadere. Il blocco produce silenzio, e questo produce un ritmo.
Il ritmo è l'indizio utile. I timer lo producono; la perdita di pacchetti raramente.
Leggi il motivo della disconnessione prima del timer
OpenVPN nomina il suo motivo, e ogni nome punta a un sottosistema diverso. Session invalidated: KEEPALIVE_TIMEOUT è un timer che scade, quindi confronta i valori di ping e ping-restart su entrambi i lati. AUTH_FAILED è lo stato delle credenziali o del certificato, e nessuna modifica ai timer aiuterà. Un errore TLS significa che i peer non hanno mai raggiunto la fase keepalive.
Annota l'ora di connessione, l'ora di disconnessione e se l'intervallo è stabile al secondo. Quella singola misura separa un orario configurato da una coincidenza.
Un intervallo stabile è un timer. Uno che va alla deriva è più probabilmente un problema di percorso o una sessione spostata.
Due timer keepalive che non si sono mai messi d'accordo
I profili esportati dal portale a volte portano ancora righe come keepalive o ping-restart copiate da un modello di server comunitario. Il gateway esegue la propria rilevazione del peer morto e impone le proprie aspettative, e i due orari non devono coincidere. Quando divergono, il client si riavvia secondo un orario che il gateway non ha mai accettato.
I due valori non sono lo stesso controllo. ping è la frequenza con cui il client invia un eco, e ping-restart è quanto attende senza sentire nulla prima di abbattere il tunnel. Un profilo con un ping-restart breve e un gateway che risponde lentamente si riavvieranno a ogni periodo di silenzio, che è esattamente la forma di un ciclo di un minuto.
La modifica minima sul lato client è neutralizzare i timer al livello superiore del profilo, fuori da ogni blocco inline:
keepalive 0 0Salva, ricarica il profilo, riconnettiti. Una sessione già in memoria conserva i vecchi valori, ed è per questo che a volte la modifica sembra non aver fatto nulla.
Il nome del certificato può spostarsi sotto i tuoi piedi
L'autenticazione con certificato di Azure dipende dal fatto che il client si fidi del nome che il gateway presenta oggi. Una riga verify-x509-name in un download più vecchio può fissare un nome che una ricostruzione del gateway o un rinnovo del certificato ha cambiato da allora, e la discrepanza si manifesta come un ciclo di riconnessione anziché come un errore chiaro. Eliminare la riga ripristina la connettività, il che la rende una buona diagnosi e una cattiva correzione permanente, perché rimuove anche la verifica. Una volta che il tunnel tiene, ripristina la riga con il nome che il gateway presenta davvero.
Prova una seconda generazione di client sulla stessa macchina prima di modificare il gateway. Se un client entra in ciclo e l'altro tiene, il profilo non è il problema.
Cosa cambiare, e in quale ordine
Controlla poi una sessione spostata. Due dispositivi che condividono un certificato possono espellersi a vicenda, e il risultato sembra periodico perché entrambi i lati continuano a riconnettersi. Confronta i record di sessione da punto a sito per la stessa identità che compare ancora e ancora.
Poi prova il percorso inattivo eseguendo traffico continuo per diversi minuti. Se le cadute si fermano mentre il traffico scorre, il timer che conta appartiene a un dispositivo NAT o a un bilanciatore di carico sul percorso, non a OpenVPN.
Le impostazioni del gateway dovrebbero cambiare solo dopo queste quattro prove.