Keepalive no es una reconexión: elige según el fallo que tengas

Los keepalives y las reconexiones se configuran al mismo tiempo y resuelven problemas distintos, por eso ajustar uno rara vez arregla el otro. Un keepalive envía tráfico pequeño para mantener viva una entrada de estado o para notar que un par dejó de responder. Una reconexión derriba lo que está roto y vuelve a construir la relación, incluidas claves, direcciones y rutas. Elige el mecanismo que encaja con el fallo, no el que ya conoces de memoria. Dos preguntas lo deciden: ¿está muerto el camino o algo entre los pares lo está olvidando?

Cuando el mapeo es el problema

Un túnel que muere solo tras minutos de silencio suele perder una entrada de traducción y no un par. El PersistentKeepalive de WireGuard existe para el estado de NAT y cortafuegos, y las notas del propio proyecto lo presentan así, no como una comprobación de salud. Un intervalo de unas decenas de segundos mantiene la entrada caliente, mientras que un paquete cada segundo es una decisión de batería y no de fiabilidad. OpenVPN llega al mismo sitio mediante ping y ping-restart , que notan primero el silencio y después actúan.

Esos ajustes tampoco son intercambiables entre protocolos. Una política de par muerto de IKEv2, un temporizador ping de OpenVPN y un keepalive de WireGuard responden a la misma pregunta con tres sintaxis y tres valores por defecto distintos, así que copiar un número entre ellos es adivinar disfrazado de ajuste.

Cuando la relación se ha ido

Si el par cambia de dirección, la credencial caduca o el extremo remoto se reinicia, los paquetes pequeños no son la reparación. La reconexión tiene que reconstruir el estado : obtener una dirección, reinstalar las rutas, renegociar las claves y, en algunos despliegues, reautenticar a un usuario.

Los clientes que se reconectan sin supervisión guardan un certificado o un secreto almacenado. Un cliente que preguntaría a una persona falla justo cuando no hay nadie, que es el escenario en el que la reconexión importaba. Eso es una decisión de diseño tomada meses antes, no un ajuste que puedas cambiar durante una caída.

Lo que ninguno de los dos demuestra

Un túnel puede estar reconectado, con claves y rutas, mientras el servicio que hay detrás está caído, y un keepalive puede mantener abierto un mapeo para una sesión cuyo servidor lleva horas desaparecido. Ambos mecanismos pueden informar de éxito mientras lo que de verdad te importa no está disponible.

Por eso la prueba termina en una petición real. Envía algo por el túnel después del intervalo que te importa y luego provoca por separado el fallo para el que diseñaste: un periodo de inactividad para el caso del mapeo, un reinicio o un cambio de dirección para el caso de la reconexión.

Bloquear el tráfico directo es una decisión aparte

Un bucle de reconexión puede estar perfectamente sano mientras una aplicación usa en silencio la ruta ordinaria, y eso es una fuga, no un fallo. Si el requisito es que nada salga fuera del túnel, dilo explícitamente en la configuración del cliente y demuéstralo bajando el túnel y mirando qué sigue conectando. Ninguno de los dos mecanismos implica ese comportamiento y ninguna disciplina de reintentos lo establece.

Anota qué mecanismo se ejecutó y si después funcionó una petición nueva. Esos dos hechos son lo que necesita el siguiente ingeniero, y ninguno se ve en un icono de estado. Una línea de registro que dice que el cliente se reconectó no es lo mismo que una petición que funcionó.

Escribe la política, no solo el número

Pon el par en una frase: el intervalo de inactividad, el umbral de vitalidad, qué desencadena una reconstrucción , y qué hace el cliente mientras reintenta. Sin esa frase, cada incidente futuro reabre la misma discusión sobre si el keepalive es demasiado corto o la reconexión demasiado lenta.

Las notas de WireGuard sobre limitaciones son un recordatorio útil de que el keepalive es una solución provisional para middleboxes y no un diseño general de vitalidad. Lee esa limitación antes de subir la frecuencia en respuesta a un problema que no puede resolver.