La línia diu PID_ERR replay-window backtrack occurred, i tots els resultats de cerca ho expliquen com a paquets descartats i un túnel trencat. Al camí UDP de Community OpenVPN 2.6, aquest missatge s'escriu mentre la funció de recepció encara decideix què fer amb el paquet. Registra un nou màxim de retrocés, i després la mateixa funció compara la distància amb la finestra i l'estat registrat abans d'acceptar o rebutjar. Llegir l'etiqueta del registre com a veredicte és l'error que aquesta llista de comprovació vol evitar.

Parada u: identifiqueu què és la línia

És un diagnòstic sobre la distància de seqüència, no una decisió sobre una connexió. Apareix a la implementació de l'ID de paquet en el punt on es registra un màxim de retrocés recentment observat. Aquest punt se situa abans de la branca d'acceptar o rebutjar, i per això un paquet que el provoca encara es pot lliurar.

Confirmeu quin amfitrió el va escriure i amb quina verbositat. Un servidor i un client poden emetre tots dos missatges d'ID de paquet, i un missatge d'una banda no diu res sobre l'estat de recepció de l'altra.

Parada dos: trobeu el resultat d'aquell paquet

Llegiu les línies posteriors al diagnòstic, no només el diagnòstic. La mateixa funció continua cap a les comprovacions de finestra i duplicats, així que el resultat d'aquell paquet concret es decideix unes quantes instruccions després i pot molt bé ser l'acceptació. Un extracte de registre que acaba a la línia esfereïdora no us diu res sobre el resultat. Cerqueu una finestra al voltant, no la línia mateixa:

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

Si el registre no mostra cap rebuig per a aquell parell en aquell moment, deixeu de tractar aquesta línia com la causa de la caiguda. Passeu al camí de l'aplicació, que és on la majoria d'informes de connectat però sense trànsit acaben de fet.

Parada tres: decidiu si la reordenació és real

La reordenació és una propietat del camí, i un diagnòstic n'és una sola mostra. Cerqueu missatges repetits per al mateix parell en una finestra curta i compareu-los amb una captura als dos extrems abans de concloure que la xarxa reordena agressivament.

Un grapat de missatges durant una reconnexió no és res d'estrany. Un flux continu amb temps d'espera reals de l'aplicació val la pena investigar-lo, i aquesta combinació és evidència, no una etiqueta.

Parada quatre: els paràmetres de la finestra i què no són

replay-window pren una mida de seqüència i un valor de temps opcional, així que ampliar-lo canvia dues toleràncies diferents alhora. Pujar el nombre admet paquets més allunyats de l'ordre; el valor de temps limita quant de temps es pot considerar encara un paquet. Ampliar és un canvi de política amb un cost de seguretat, i no reforça cap xifrat ni desactiva la detecció de duplicats. Les dues toleràncies es mouen juntes, tant si ho volíeu com si no.

Un paquet autenticat antic encara pot ser una repetició no desitjada, i per això el receptor manté aquestes comprovacions. Acceptar més reordenació significa acceptar més d'aquest risc.

Silenciar l'avís amb mute canvia el que veieu, no el que fa el dimoni. Si l'objectiu és un registre més tranquil durant un esdeveniment conegut, és una opció operativa legítima; si l'objectiu és arreglar un túnel, silenciar amaga l'evidència.

mute 20
replay-window 64 15

Canviar el transport exterior a TCP canvia el comportament de lliurament i recuperació i afegeix els seus propis costos de bloqueig de cap de cua. És una decisió de disseny, no una primera resposta a una etiqueta del registre. Reinstal·lar el servidor és pitjor, perquè esborra la distinció entre una estadística i la frontera que realment va fallar.

Parada cinc: proveu el camí que importa a l'usuari

Amb el túnel connectat, executeu la prova pròpia de l'aplicació i llegiu la seva ruta seleccionada, l'estat de reenviament i el camí de retorn. Un túnel que només transporta paquets en una direcció no produeix cap missatge de retrocés, i és molt més comú que una reordenació greu.

Anoteu què vau mesurar a cada parada. El registre és el que impedeix que l'informe següent torni a començar a la línia esfereïdora i treballi cap enfora des d'allà.

La implementació de l'ID de paquet mostra l'ordre de l'estadística i la decisió, i el manual descriu l'abast de seqüència i de temps de la finestra. Llegir les dues coses juntes és el que converteix una línia de registre esfereïdora en una quantitat coneguda. Cap de les dues no diu res sobre el vostre camí concret, i per això les mesures anteriors encara importen.

Articles relacionats