Backtrack de reprodução do OpenVPN no log: o que a linha não prova

A linha diz PID_ERR replay-window backtrack occurred, e todos os resultados de busca a explicam como pacotes descartados e um túnel quebrado. No caminho UDP do Community OpenVPN 2.6, essa mensagem é escrita enquanto a função de recepção ainda decide o que fazer com o pacote. Ela registra um novo máximo de backtrack, e então a mesma função compara a distância com a janela e com o estado registrado antes de aceitar ou rejeitar. Ler o rótulo do log como o veredito é o erro que esta lista de verificação existe para evitar.

Parada um: identifique o que é a linha

É um diagnóstico sobre distância de sequência, não uma decisão sobre uma conexão. Aparece na implementação do ID de pacote no ponto em que um máximo de backtrack recém-observado é anotado. Esse ponto fica antes do ramo de aceitar ou rejeitar, por isso um pacote que o provoca ainda pode ser entregue.

Confirme qual host a escreveu e com que nível de detalhe. Um servidor e um cliente podem ambos emitir mensagens de ID de pacote, e uma mensagem de um lado não diz nada sobre o estado de recepção do outro.

Parada dois: encontre o resultado desse pacote

Leia as linhas depois do diagnóstico em vez de apenas o diagnóstico. A mesma função continua para as verificações de janela e duplicados, então o resultado para aquele pacote específico é decidido poucas instruções depois e pode muito bem ser aceitação. Um trecho de log que termina na linha assustadora não diz nada sobre o resultado. Procure uma janela ao redor dela, não a linha em si:

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

Se o log não mostra nenhuma rejeição para aquele par naquele momento, pare de tratar esta linha como a causa da queda. Passe para o caminho da aplicação, que é onde a maioria dos relatos de conectado mas sem tráfego realmente termina.

Parada três: decida se a reordenação é real

A reordenação é uma propriedade do caminho, e um diagnóstico é uma única amostra dela. Procure mensagens repetidas para o mesmo par numa janela curta e compare com uma captura nas duas pontas antes de concluir que a rede reordena agressivamente.

Um punhado de mensagens durante uma reconexão não tem nada de especial. Um fluxo contínuo junto com tempos limite reais da aplicação merece investigação, e essa combinação é evidência, não um rótulo.

Parada quatro: os parâmetros da janela, e o que não são

replay-window aceita um tamanho de sequência e um valor de tempo opcional, então ampliá-lo muda duas tolerâncias diferentes ao mesmo tempo. Aumentar o número admite pacotes mais distantes da ordem; o valor de tempo limita por quanto tempo um pacote ainda pode ser considerado. Ampliar é uma mudança de política com um custo de segurança, e não fortalece uma cifra nem desativa a detecção de duplicados. As duas tolerâncias se movem juntas, quer você tenha pretendido ou não.

Um pacote autenticado antigo ainda pode ser uma repetição indesejada, por isso o receptor mantém essas verificações. Aceitar mais reordenação significa aceitar mais desse risco.

Silenciar o aviso com mute muda o que você vê, não o que o daemon faz. Se o objetivo é um log mais silencioso durante um evento conhecido, é uma escolha operacional legítima; se o objetivo é consertar um túnel, silenciar esconde a evidência.

mute 20
replay-window 64 15

Mudar o transporte externo para TCP altera o comportamento de entrega e recuperação e acrescenta os seus próprios custos de bloqueio de cabeça de fila. É uma decisão de projeto, não uma primeira resposta a um rótulo de log. Reinstalar o servidor é pior, porque apaga a distinção entre uma estatística e a fronteira que realmente falhou.

Parada cinco: teste o caminho que importa ao usuário

Com o túnel conectado, execute o teste próprio da aplicação e leia a rota selecionada, o estado de encaminhamento e o caminho de retorno. Um túnel que transporta pacotes só numa direção não produz nenhuma mensagem de backtrack, e isso é muito mais comum do que uma reordenação grave.

Anote o que você mediu em cada parada. O registro é o que impede o próximo relatório de começar de novo na linha assustadora e trabalhar para fora a partir dali.

A implementação do ID de pacote mostra a ordem da estatística e da decisão, e o manual descreve o escopo de sequência e de tempo da janela. Ler as duas juntas é o que transforma uma linha de log assustadora numa grandeza conhecida. Nenhuma das duas diz nada sobre o seu caminho específico, por isso as medições acima ainda importam.