Caída horaria de OpenVPN: renegociación ou unha reconexión real?

Sesenta minutos, ou trinta, ou cento vinte: unha caída que cae nun intervalo redondo case nunca é a rede. OpenVPN renova segundo un temporizador o material de claves que protexe a canle de datos, e un temporizador máis curto có que supoñía vese exactamente como unha ligazón que falla unha e outra vez. Os usuarios informan dunha conexión rota mentres o rexistro informa dun intercambio de claves correcto. A guía seguinte separa esa renovación dun reinicio real, le o valor que realmente está en vigor e só o cambia despois de que o custo estea sobre a mesa.

Siga os pasos en orde, porque o primeiro decide se o resto da páxina lle afecta en absoluto. Se se adianta, pasará unha tarde axustando un temporizador por un fallo que non ten nada que ver con el.

Distinga un reinicio suave dun reinicio

A liña do rexistro é todo o diagnóstico. Unha renegociación escribe un reinicio suave e despois un intercambio de claves novo dentro do mesmo túnel: a interface conserva o seu enderezo, as rutas non se volven engadir e as sesións TCP establecidas adoitan sobrevivir cunha pausa. Un reinicio real rompe a sesión, reconstrúe a interface, pode entregar outro enderezo de cliente e mata toda conexión de longa duración. Ambos os sucesos son normais; só un explica unha 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 liña de versión importa porque a redacción do rexistro cambia entre versións, e unha mensaxe que recorda do 2.3 pode estar redactada doutro xeito no 2.6. Lea o seu propio rexistro en vez dun extracto de foro doutra persoa. Cite a liña exacta cando pide axuda, porque unha paráfrase perde o detalle que identifica o suceso. Se o enderezo da interface non cambia durante o suceso e a lista de sesións sobrevive, está a ver unha renovación e as seccións restantes aplícanse.

Lea o temporizador efectivo, non o seu ficheiro

reneg-sec é o número de segundos entre renegociacións da canle de datos e o seu valor por defecto é 3600. Cada par leva o seu propio valor, e o menor dos dous é o que realmente desencadea a renovación. Esa única regra explica a maioría dos informes: un perfil de cliente que fixa un número grande segue reiniciándose cada hora mentres o servidor mantén o valor por defecto.

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

Lea tamén a configuración efectiva do servidor, incluído todo o que empurra, antes de sacar conclusións do ficheiro do cliente. Despois suba a verbosidade e observe un intervalo de principio a fin: o nivel 3 xa mostra as liñas de renegociación, e as marcas de tempo din se o suceso se repite cada 3600 segundos ou segue a actividade.

Cámbieo onde realmente se empurra

O remedio que circula é unha soa liña no perfil do cliente, e é o lugar equivocado aproximadamente a metade das veces. Como gaña o valor máis baixo dos pares, un cliente que pon o temporizador a cero aínda pode ser renegociado por un servidor que non cambiou.

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

Cando os perfís se xeran de forma central, edite o modelo e non a copia despregada, ou a seguinte execución de aprovisionamento restaurará o valor que acaba de quitar. Verifíqueo observando dous intervalos, non un: unha hora tranquila tamén encaixa cun temporizador posto a 7200.

Decida tamén que ocorre nun despregamento mixto. Se estende o cambio primeiro aos clientes, queda unha xanela na que o servidor aínda desencadea a renovación; é inofensivo pero confuso se mira os rexistros buscando confirmación. Cambie primeiro o lado que ten o valor menor e o síntoma desaparece no punto que espera.

Que cede ao desactivar a renegociación

A renegociación periódica limita canto tempo un só conxunto de claves da canle de datos protexe o tráfico. Desactivar o temporizador non rompe o túnel, e nun router doméstico ou unha porta de enlace de oficina pequena a exposición práctica é modesta. Segue sendo un intercambio, e paga a pena enunciado antes de facelo. O que cambia é canto tempo un conxunto de claves protexe unha sesión, non se o túnel funciona en absoluto.

O caso razoable para desactivalo é un reinicio que rompe algo que non se pode retomar: unha chamada que cae, unha sesión de escritorio remoto que hai que restablecer, unha copia de seguridade que comeza desde o principio. Se a pausa é invisible para os usuarios, manter o valor por defecto non custa nada e conserva a rotación de claves que lle deron.

Prefira arranxar a causa cando o patrón o permite. Unha renovación que falla a metade de camiño mentres o primeiro saldo de mans tivo éxito apunta ao camiño e non ao temporizador: busque un problema de tamaño de paquete no intercambio maior da canle de control, unha devasa con estado que descarta o fluxo ou unha proposta que só ten éxito ao primeiro intento. Cada un deixa un rastro no mesmo rexistro que acaba de ler. Desactivar o temporizador oculta esa evidencia.

Cando o intervalo apunta a outro sitio

Dous veciños na configuración producen síntomas parecidos e arranxos distintos. ping-restart reinicia o túnel cando non chega nada durante un período configurado, mentres que ping-exit baixa o cliente por completo. Unha caída inactiva sen ningunha renegociación no rexistro pertence a estes ou a un dispositivo NAT que fixo caducar a asignación UDP segundo o seu propio calendario.

Os routers de consumo, os puntos de acceso móbiles e o NAT de operador fan caducar as sesións UDP inactivas sen avisar a ninguén. Ese fallo segue a inactividade e non o reloxo, e esa é a pista: unha sesión que cae tras dez minutos tranquilos e sobrevive unha hora de tráfico constante non está renegociando.

Anote tres cousas antes de cambiar unha cuarta: o intervalo que mediu, o valor efectivo que atopou e o comando que o mostrou. Se o intervalo se move cando se move o temporizador, o mecanismo queda identificado e o arranxo é unha decisión sobre o intercambio anterior. Se non se move, devolva o axuste e siga mirando keepalives, estado de NAT e perda de paquetes.