Backtrack di riproduzione di OpenVPN nel registro: cosa non dimostra la riga

La riga dice PID_ERR replay-window backtrack occurred, e tutti i risultati di ricerca la spiegano come pacchetti scartati e un tunnel rotto. Nel percorso UDP di Community OpenVPN 2.6, quel messaggio viene scritto mentre la funzione di ricezione sta ancora decidendo cosa fare del pacchetto. Registra un nuovo massimo di backtrack, poi la stessa funzione confronta la distanza con la finestra e con lo stato registrato prima di accettare o rifiutare. Leggere l'etichetta del registro come verdetto è l'errore che questa lista di controllo esiste per evitare.

Tappa uno: identifica cos'è la riga

È una diagnostica sulla distanza di sequenza, non una decisione su una connessione. Compare nell'implementazione dell'ID di pacchetto nel punto in cui viene annotato un massimo di backtrack appena osservato. Quel punto si trova prima del ramo di accettazione o rifiuto, perciò un pacchetto che lo provoca può ancora essere consegnato.

Conferma quale host l'ha scritta e con quale livello di dettaglio. Un server e un client possono entrambi emettere messaggi di ID di pacchetto, e un messaggio di un lato non dice nulla sullo stato di ricezione dell'altro.

Tappa due: trova l'esito per quel pacchetto

Leggi le righe successive alla diagnostica invece della sola diagnostica. La stessa funzione prosegue nei controlli di finestra e duplicati, quindi l'esito per quel pacchetto specifico viene deciso poche istruzioni dopo e può benissimo essere l'accettazione. Un estratto di registro che termina alla riga spaventosa non dice nulla sull'esito. Cerca una finestra attorno ad essa, non la riga stessa:

journalctl -u openvpn-server@server --since "-10 min" | grep -n -A3 -B3 "backtrack occurred"

Se il registro non mostra alcun rifiuto per quel peer in quel momento, smetti di trattare questa riga come causa dell'interruzione. Passa al percorso dell'applicazione, perché è lì che la maggior parte dei rapporti di connesso ma senza traffico finisce davvero.

Tappa tre: decidi se il riordino è reale

Il riordino è una proprietà del percorso, e una diagnostica ne è un solo campione. Cerca messaggi ripetuti per lo stesso peer in una finestra breve e confrontali con una cattura su entrambe le estremità prima di concludere che la rete riordina in modo aggressivo.

Una manciata di messaggi durante una riconnessione non è niente di straordinario. Un flusso continuo accanto a veri timeout dell'applicazione merita un'indagine, e quella combinazione è una prova, non un'etichetta.

Tappa quattro: i parametri della finestra, e cosa non sono

replay-window accetta una dimensione di sequenza e un valore di tempo opzionale, quindi ampliarla cambia due tolleranze diverse insieme. Aumentare il numero ammette pacchetti più lontani dall'ordine; il valore di tempo limita per quanto tempo un pacchetto può ancora essere considerato. Ampliare è un cambio di politica con un costo di sicurezza, e non rafforza un cifrario né disattiva il rilevamento dei duplicati. Le due tolleranze si muovono insieme, che tu lo volessi o no.

Un vecchio pacchetto autenticato può ancora essere una ripetizione indesiderata, per questo il ricevente mantiene questi controlli. Accettare più riordino significa accettare di più di quel rischio.

Silenziare l'avviso con mute cambia ciò che vedi, non ciò che fa il demone. Se l'obiettivo è un registro più tranquillo durante un evento noto, è una scelta operativa legittima; se l'obiettivo è riparare un tunnel, il silenziamento nasconde la prova.

mute 20
replay-window 64 15

Passare il trasporto esterno a TCP cambia il comportamento di consegna e recupero e aggiunge i propri costi di blocco in testa alla coda. È una decisione di progettazione, non una prima risposta a un'etichetta del registro. Reinstallare il server è peggio, perché cancella la distinzione tra una statistica e il confine che ha davvero fallito.

Tappa cinque: prova il percorso che conta per l'utente

Con il tunnel connesso, esegui il test proprio dell'applicazione e leggi la sua rotta selezionata, lo stato di inoltro e il percorso di ritorno. Un tunnel che trasporta pacchetti solo in una direzione non produce alcun messaggio di backtrack, ed è molto più comune di un riordino grave.

Annota ciò che hai misurato a ogni tappa. La registrazione è ciò che impedisce al rapporto successivo di ricominciare dalla riga spaventosa e di lavorare verso l'esterno da lì.

L'implementazione dell'ID di pacchetto mostra l'ordine della statistica e della decisione, e il manuale descrive l'ambito di sequenza e di tempo della finestra. Leggere entrambe insieme è ciò che trasforma una riga di registro spaventosa in una grandezza nota. Nessuna delle due dice nulla sul tuo percorso specifico, per questo le misurazioni sopra contano ancora.