Queda horária do OpenVPN: renegociação ou uma reconexão real?

Sessenta minutos, ou trinta, ou cento e vinte: uma queda que cai num intervalo redondo quase nunca é a rede. OpenVPN renova segundo um temporizador o material de chaves que protege o canal de dados, e um temporizador mais curto do que o que assumiu parece exatamente uma ligação que falha repetidamente. Os utilizadores relatam uma ligação quebrada enquanto o registo relata uma troca de chaves bem-sucedida. O guia abaixo separa essa renovação de um reinício real, lê o valor que está realmente em vigor e só o altera depois de o custo estar em cima da mesa.

Siga os passos por ordem, porque o primeiro decide se o resto da página se aplica a si de todo. Se avançar, passará uma noite a afinar um temporizador por uma falha que nada tem a ver com ele.

Distinga um reinício suave de um reinício

A linha do registo é todo o diagnóstico. Uma renegociação escreve um reinício suave e depois uma troca de chaves nova dentro do mesmo túnel: a interface mantém o endereço, as rotas não são readicionadas e as sessões TCP estabelecidas geralmente sobrevivem com uma pausa. Um reinício real destrói a sessão, reconstrói a interface, pode atribuir outro endereço de cliente e mata todas as ligações de longa duração. Ambos os eventos são normais; apenas um explica uma chamada cortada.

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'soft reset|Connection reset|reneg|TLS Error'
openvpn --version | head -n 1

A linha de versão importa porque a redação do registo muda entre versões, e uma mensagem que recorda da 2.3 pode estar redigida de outra forma na 2.6. Leia o seu próprio registo em vez de um extrato de fórum de outra pessoa. Cite a linha exata quando pede ajuda, porque uma paráfrase perde o detalhe que identifica o evento. Se o endereço da interface não mudar durante o evento e a lista de sessões sobreviver, está a ver uma renovação e as secções restantes aplicam-se.

Leia o temporizador efetivo, não o seu ficheiro

reneg-sec é o número de segundos entre renegociações do canal de dados e o valor predefinido é 3600. Cada par transporta o seu próprio valor, e o menor dos dois é o que realmente desencadeia a renovação. Essa única regra explica a maioria dos relatos: um perfil de cliente que define um número grande continua a ser reiniciado de hora a hora enquanto o servidor mantém o valor predefinido.

grep -Rn --include='*.conf' -E 'reneg-sec|reneg-bytes' /etc/openvpn
# server side, including included files
grep -Rn -E '^reneg-sec' /etc/openvpn/server/

Leia também a configuração efetiva do servidor, incluindo tudo o que ele empurra, antes de tirar conclusões do ficheiro do cliente. Depois aumente a verbosidade e observe um intervalo do início ao fim: o nível 3 já mostra as linhas de renegociação, e as marcas temporais dizem se o evento se repete a cada 3600 segundos ou segue a atividade.

Altere-o onde é realmente empurrado

O remédio que circula é uma única linha no perfil do cliente, e é o local errado cerca de metade das vezes. Como o valor mais baixo dos pares vence, um cliente que põe o temporizador a zero ainda pode ser renegociado por um servidor que não mudou.

# on both ends, or on the side that owns the pushed configuration
reneg-sec 0

Quando os perfis são gerados centralmente, edite o modelo e não a cópia implementada, senão a próxima execução de aprovisionamento restaura o valor que acabou de remover. Verifique observando dois intervalos, não um: uma hora calma também é compatível com um temporizador definido para 7200.

Decida também o que acontece numa implementação mista. Se lançar a alteração primeiro nos clientes, fica uma janela em que o servidor ainda desencadeia a renovação; é inofensivo mas confuso se estiver a ver os registos à procura de confirmação. Altere primeiro o lado que tem o valor menor e o sintoma desaparece no ponto que espera.

O que abdica ao desativar a renegociação

A renegociação regular limita quanto tempo um único conjunto de chaves do canal de dados protege o tráfego. Desligar o temporizador não quebra o túnel, e num router doméstico ou numa porta de ligação de escritório pequeno a exposição prática é modesta. Continua a ser uma troca, e a troca merece ser enunciada antes de a fazer. O que muda é quanto tempo um conjunto de chaves protege uma sessão, não se o túnel funciona de todo.

O caso razoável para o desativar é um reinício que quebra algo que não pode ser retomado: uma chamada que cai, uma sessão de ambiente de trabalho remoto que tem de ser restabelecida, uma cópia de segurança que recomeça do início. Se a pausa for invisível para os utilizadores, manter o valor predefinido não custa nada e conserva a rotação de chaves que lhe foi dada.

Prefira corrigir a causa quando o padrão o permite. Uma renovação que falha a meio caminho enquanto o primeiro aperto de mão teve sucesso aponta para o caminho e não para o temporizador: procure um problema de tamanho de pacote na troca maior do canal de controlo, uma firewall com estado que descarta o fluxo, ou uma proposta que só tem sucesso à primeira tentativa. Cada um deles deixa um rasto no mesmo registo que acabou de ler. Desativar o temporizador esconde essa evidência.

Quando o intervalo aponta para outro sítio

Dois vizinhos na configuração produzem sintomas semelhantes e correções diferentes. ping-restart reinicia o túnel quando nada chega durante um período configurado, enquanto ping-exit derruba o cliente por completo. Uma queda inativa sem qualquer renegociação no registo pertence a estes, ou a um dispositivo NAT que deixou a atribuição UDP expirar segundo o seu próprio calendário.

Os routers de consumo, os hotspots móveis e o NAT de operadora deixam todas as sessões UDP inativas expirarem sem avisar ninguém. Essa falha segue a inatividade e não o relógio, e essa é a pista: uma sessão que cai após dez minutos calmos e sobrevive uma hora de tráfego constante não está a renegociar.

Anote três coisas antes de mudar uma quarta: o intervalo que mediu, o valor efetivo que encontrou e o comando que o mostrou. Se o intervalo se mover quando o temporizador se move, o mecanismo está identificado e a correção é uma decisão sobre a troca acima. Se não se mover, reponha a definição e continue a olhar para keepalives, estado do NAT e perda de pacotes.