OpenVPN es uno de los servidores de VPN más populares en nuestro mundo de Linux. En mi caso lo vengo utilizando hace unos 15 años, quizá más.

El día de ayer un cliente amigo (dueño de una PYME) me contactó que las conexiones hacia el servidor de VPN que le instalé hace varios años en su empresa le había comenzado a fallar. Lo que reportaba era que cada pocos minutos, a veces un minuto, a veces un poquito más, la conexión se le cerraba y tenía que volver a reconectarse.

Me llamó mucho la atención pues es un servidor que la verdad no toco, entro infrecuentemente al servidor, poquitas veces al año. Es un servidor puramente dedicado a OpenVPN, no realizan ninguna actividad en él. El servidor simplemente está ahi atendiendo las poquitas conexiones de VPN que maneja.

Es una persona muy proactiva y me envió el log de su cliente de VPN, copio aquí la parte más relevante:

Mon Jan 15 18:36:43 2024 us=578145 Initialization Sequence Completed
Mon Jan 15 18:36:43 2024 us=578145 MANAGEMENT: >STATE:1705361803,CONNECTED,SUCCE
SS,10.8.0.42,1.2.3.4,1194,,
Mon Jan 15 18:40:43 2024 us=841400 [server] Inactivity timeout (--ping-restart),
restarting
Mon Jan 15 18:40:43 2024 us=842159 TCP/UDP: Closing socket
Mon Jan 15 18:40:43 2024 us=842662 SIGUSR1[soft,ping-restart] received, process restarting
Mon Jan 15 18:40:43 2024 us=842662 MANAGEMENT: >STATE:1705362043,RECONNECTING,ping-restart,,,,,
Mon Jan 15 18:40:43 2024 us=842662 Restart pause, 5 second(s)

Encontré muchos comentarios en Internet con posibles soluciones, desde que los algoritmos de cifrado, hasta algo que me interesó mucho y era que el ping del cliente no coincidía con el ping del servidor, o que se debía usar keepalived. En verdad tiene muchas razones.

Pero hay una razón más, que me parece importante, y es que este problema también sale cuando hay una diferencia de hora entre el OpenVPN cliente y el OpenVPN servidor. Incluso si la diferencia de hora es pequeña (en el orden de segundos). Esto puede suceder.

Y me pareció la explicación más lógica porque es un equipo al que no se le hacen mayores cambios. La configuración que se usa es la misma durante varios años, por lo que si fuera un problema de configuración, hubiera sucedido ya hace mucho tiempo.

Alternativas de mitigación

Una propuesta de mitigación que encontré es configurar al servidor para que renegocie el canal (reneg-sec) en un periodo de tiempo más extendido. Por ejemplo, para que se renegocie el canal cada 8 horas. Así al menos la conexión, una vez negociada, duraría quizá 8 horas.

Por defecto el parámetro reneg-sec está en una hora, por lo que la sesión se renegocia cada una hora si esta no está definida.

El problema con reneg-sec es que debe ajustarse tanto en el cliente como en el servidor, ya que OpenVPN usará el menor valor definido en ambos extremos. Por ejemplo, podemos poner reneg-sec 86400 (un día) en el servidor, pero si tenemos reneg-sec 7200 (2 horas) en el cliente, entonces la renegociación ocurrirá cada 2 horas, el valor menor.

Imagínate si tuvieras decenas de clientes en diferentes partes del país, o en diferentes países, cómo cambiarías el reneg-sec en ellos?

Además, como indicaba la persona que proponía el cambio es que esto realmente es una mitigación porque no resuelve el problema, sino que lo dilata para que ocurra una vez cada 8 horas.

Solución propuesta

Y un problema adicional: mi amigo no tiene el parámetro reneg-sec configurado ni en clientes ni en servidor. Por lo tanto el periodo de renegociación es el valor por defecto de 3600 segundos. Y no sé si recuerdan que mencioné que realmente él no podía casi ni navegar, el OpenVPN se le desconectaba cada pocos minutos (1 o 2 minutos).

Entonces noto que la hora del servidor estaba desplazada, estaba adelantada más de 7 segundos respecto a la hora oficial.

Instalé y activé el servicio de NTPd en el servidor y una vez que el servidor tuvo la hora correcta, el problema ya no ocurrió más!

Lo más probable es que este servidor no se había apagado en varios años, pero, en vista de los apagones que han estado sucediendo en el país, posiblemente le pusieron un UPS que no está entregando una frecuencia estable, quizá no está a 60hz y al servidor lentamente la hora se le ha ido corriendo. Esta es mi opinión, puede ser por muchas razones más, pero creo que está relacionada con el problema energético ya que esto le comenzó a suceder recientemente luego de muchos años trabajando normalmente.

Conclusiones

Es importante tener este posible problema en cuenta. En este caso el problema estaba en el servidor. Pero debemos también pensar que puede ocurrir en uno de los clientes. En este último caso el problema se manifestaría solamente en un cliente.

Sugerimos que se instale y mantenga activo un servicio de tiempo (NTPd o Chrony) en nuestros servidores, todos, ya que como podemos ver, el mantener la hora correcta en nuestros servidores es fundamental por muchas razones.