VPN cai durante envios grandes: leia a fila primeiro

O túnel fica estável o dia todo e cai sempre que começa um envio grande. As requisições interativas travam primeiro, o cliente relata um tempo limite e a conexão volta quando a transferência termina. Esse padrão aponta para fila e processamento, não para um servidor remoto fora do ar, porque o servidor nunca teve a chance de responder a tempo. O trabalho é reproduzir isso sob carga controlada e ler os contadores certos.

Mude uma variável por execução e mantenha o endpoint fixo.

Monte uma comparação de carga reproduzível

Registre uma linha de base com o link ocioso: tempo de ida e volta, algumas requisições de aplicação e o log de eventos do próprio túnel. Depois inicie um envio de tamanho conhecido e repita exatamente essas medições enquanto ele roda. Mantenha o endpoint, o cliente e o destino do teste sem mudanças, porque alterar dois deles ao mesmo tempo não diz nada.

Observe qual evento aparece primeiro. Um tempo de ida e volta crescente antes de qualquer erro sugere fila; um tempo limite duro com latência estável sugere outra coisa, como uma rotação de chaves ou uma ação na conta. Os dois padrões levam a próximos passos diferentes. Escreva a observação antes de mudar qualquer coisa.

Salve a saída com carimbos de tempo para que as execuções sob carga e ociosa possam ser comparadas linha por linha.

Leia a fila, não a velocidade

Links de consumidor armazenam pacotes no equipamento do provedor, e uma fila de saída cheia atrasa tudo, incluindo os pequenos pacotes de controle que mantêm o túnel vivo. Um teste de velocidade que mostra um número alto diz pouco sobre esse atraso, e é por isso que um teste ocioso passa enquanto um link saturado falha.

ping -c 20 -i 0.2 203.0.113.10
mtr -rwc 20 203.0.113.10
tc -s qdisc show dev eth0
ss -ti dst 203.0.113.10
nstat -az | grep -E 'Retrans|Timeout'

Compare os números de latência sob carga com os ociosos. Um salto de dezenas de milissegundos para centenas, sem perda de pacotes, é fila; perda com latência estável aponta para outra falha.

Verifique o dispositivo e o caminho de controle

Criptografia e encaminhamento custam tempo de processador, e um roteador pequeno ou um notebook limitado termicamente pode descartar pacotes enquanto está ocupado. Acompanhe a carga geral e não a porcentagem de um processo, porque o encaminhamento no kernel e o tratamento de interrupções não aparecem onde as pessoas costumam olhar.

uptime
mpstat -P ALL 1 3
dmesg | grep -i -E 'thermal|throttl'
journalctl -u openvpn-server@server --since '10 min ago' | tail -20

Um tempo limite no cliente também pode coincidir com uma rotação de chaves agendada ou com um evento de política de sessão. Leia o log do próprio cliente para a ordem dos eventos, não apenas a mensagem de erro da aplicação.

Mude uma coisa e repita

Onde a plataforma permitir, limite a taxa de envio ou classifique o tráfego em massa abaixo do interativo para que a fila nunca encha. Depois repita a mesma carga de trabalho e compare os mesmos três números de antes. Uma mudança que melhora um teste de velocidade mas deixa o tempo limite no lugar não consertou nada.

Aumentar os tempos limite em geral e enfraquecer a criptografia são as duas mudanças que fazem o sintoma sumir sem identificar qual limite falhou. Nenhuma das duas é um conserto. Ambas empurram a falha para mais tarde, onde é mais difícil atribuí-la.

Termine testando uma requisição nova e o comportamento de reconexão com que o usuário realmente conta. A estabilidade sob a carga que causou a reclamação é o único resultado que vale registrar.