Por qué un túnel de Azure OpenVPN cae aproximadamente cada sesenta segundos

El túnel termina su negociación, transporta tráfico durante aproximadamente un minuto y luego se reconecta. Esa secuencia descarta al sospechoso habitual, porque un cortafuegos que bloqueara el puerto habría detenido la negociación y no la sesión. Lo que tienes es un desacuerdo sobre la vitalidad: un lado decidió que el otro se había quedado en silencio y derribó un túnel que funcionaba. La línea del registro dice qué lado, y eso elige la solución.

Lee esa línea antes de tocar ningún temporizador.

El mito: algo en la ruta bloquea el túnel

Si un puerto estuviera bloqueado, la conexión fallaría al principio y seguiría fallando. Un ciclo repetido significa que los mensajes de control fluyen, que las sesiones se establecen y que algo más adelante en la conversación no deja de caducar. El bloqueo produce silencio, y esto produce un ritmo.

El ritmo es la pista útil. Los temporizadores lo producen; la pérdida de paquetes rara vez.

Lee el motivo de la desconexión antes que el temporizador

OpenVPN nombra su motivo, y cada nombre apunta a un subsistema distinto. Session invalidated: KEEPALIVE_TIMEOUT es un temporizador que caduca, así que compara los valores de ping y ping-restart en ambos extremos. AUTH_FAILED son credenciales o el estado del certificado, y ningún cambio de temporizador ayudará. Un error TLS significa que los pares ni siquiera llegaron a la fase keepalive.

Anota la hora de conexión, la hora de desconexión y si el intervalo es estable al segundo. Esa única medición separa un horario configurado de una coincidencia.

Un intervalo estable es un temporizador. Uno que deriva es más probablemente un problema de ruta o una sesión desplazada.

Dos temporizadores keepalive que nunca se pusieron de acuerdo

Los perfiles exportados desde el portal a veces todavía llevan líneas como keepalive o ping-restart copiadas de una plantilla de servidor comunitario. La puerta de enlace ejecuta su propia detección de par muerto e impone sus propias expectativas, y los dos horarios no tienen que coincidir. Cuando discrepan, el cliente se reinicia según un horario que la puerta de enlace nunca aceptó.

Los dos valores no son el mismo control. ping es la frecuencia con la que el cliente envía un eco, y ping-restart es cuánto espera sin oír nada antes de derribar el túnel. Un perfil con un ping-restart corto y una puerta de enlace que responde despacio se reiniciarán en cada periodo de silencio, que es exactamente la forma de un ciclo de un minuto.

El cambio mínimo en el lado del cliente es neutralizar los temporizadores en el nivel superior del perfil, fuera de cada bloque en línea:

keepalive 0 0

Guarda, recarga el perfil, vuelve a conectar. Una sesión que ya está en memoria conserva los valores antiguos, y por eso a veces parece que la edición no hizo nada.

El nombre del certificado puede moverse bajo tus pies

La autenticación por certificado de Azure depende de que el cliente confíe en el nombre que la puerta de enlace presenta hoy. Una línea verify-x509-name en una descarga antigua puede fijar un nombre que una reconstrucción de la puerta de enlace o una renovación del certificado ha cambiado desde entonces, y el desajuste se manifiesta como un bucle de reconexión y no como un error claro. Borrar la línea restaura la conectividad, lo que la convierte en un buen diagnóstico y una mala solución permanente, porque también elimina la verificación. Cuando el túnel aguante, restaura la línea con el nombre que la puerta de enlace presenta realmente.

Prueba una segunda generación de cliente en la misma máquina antes de editar la puerta de enlace. Si un cliente entra en bucle y el otro aguanta, el problema no es el perfil.

Qué cambiar y en qué orden

Comprueba después si hay una sesión desplazada. Dos dispositivos que comparten un certificado pueden expulsarse mutuamente, y el resultado parece periódico porque ambos lados siguen reconectándose. Compara los registros de sesión de punto a sitio de la misma identidad que aparece una y otra vez.

Luego prueba la ruta inactiva ejecutando tráfico continuo durante varios minutos. Si las caídas se detienen mientras fluye el tráfico, el temporizador que importa pertenece a un dispositivo NAT o a un balanceador de carga de la ruta, no a OpenVPN.

Solo después de esas cuatro pruebas deberían cambiarse los ajustes de la puerta de enlace.