Dos dispositivos, un certificado OpenVPN: el bucle de reconexión

Un túnel que sube y luego se reinicia cada medio minuto no suele ser un problema de cifrado ni de MTU. Es una identidad usada dos veces. El servidor ve un nombre común conocido, toma la sesión nueva como la más reciente, y el dispositivo más antiguo descubre que ha sido reemplazado. Desde el lado del cliente eso parece un tiempo de inactividad agotado y un reinicio, y por eso la investigación tantas veces empieza en el lugar equivocado.

Empieza por el intervalo de reinicio

El intervalo es una pista antes que nada. Una cadencia regular que coincide con la ventana ping-restart apunta a una sesión reemplazada más que a una ruta defectuosa, porque los fallos de ruta rara vez son tan regulares. Anota el intervalo exacto entre reinicios y la línea de motivo en el registro del cliente. Un tiempo agotado seguido de un reinicio cuenta una historia distinta de un handshake fallido.

Comprueba cuándo empezaron los reinicios respecto a un segundo dispositivo. Un portátil nuevo, un teléfono o un perfil copiado a una máquina de repuesto son los desencadenantes habituales, y el momento suele coincidir con el día en que alguien lo configuró.

Apunta el intervalo y el motivo. Ambos son pruebas, y ambos son baratos de recoger.

Lee lo que dijo el servidor sobre el segundo inicio de sesión

En un servidor que controlas, el registro nombra el nombre común y muestra una segunda conexión que llega. Sin duplicate-cn, esa llegada reemplaza la sesión existente para el mismo nombre, y el mensaje suele decirlo sin rodeos. Con duplicate-cn, las dos sesiones conviven y el síntoma cambia: los clientes siguen activos pero comparten un solo juego de ajustes por cliente y una sola decisión de revocación. Lee las dos entradas juntas, porque el reemplazo solo se ve en secuencia.

En un servicio alojado puede que no tengas ningún registro del servidor. La pista es entonces el momento: un túnel estable que cae cada vez que se conecta otra máquina, sin nada en el registro del cliente más allá del tiempo agotado.

Compara los bloques de certificado y clave en ambos perfiles, no solo el nombre de host remoto. Los perfiles copiados suelen diferir solo en el nombre del archivo.

Separa la identidad en el lado del servidor

Emite un certificado por dispositivo a través de la CA que firma para este servidor. Con Easy-RSA eso significa un nombre de cliente aparte para cada dispositivo, y el perfil se construye luego con ese certificado y su clave. El nombre común se convierte en la identidad del dispositivo, que es exactamente lo que le faltaba al servidor. Nómbralos por el dispositivo y no por la persona, para que un reemplazo produzca un nombre nuevo.

La clave compartida del canal de control es otra cosa. tls-crypt o tls-auth protege el canal de control de cada cliente y está pensado para compartirse. No es una identidad de cliente, y reemplazarla no arreglará un certificado duplicado.

Mantén el certificado, la clave y cualquier archivo de configuración por cliente con el mismo nombre común, o el mapeo se rompe en la siguiente conexión. Una discrepancia ahí produce un cliente que se autentica y luego no recibe nada.

Mantén direcciones y ajustes alineados tras la separación

Las direcciones fijas introducen una segunda forma de colisión. Si el servidor las asigna mediante ifconfig-pool-persist o un archivo por cliente, esos registros todavía apuntan al nombre antiguo. Dos dispositivos pueden acabar con la misma dirección de túnel incluso después de separar los certificados, y ese fallo se ve distinto del bucle original.

Actualiza el mapeo al mismo tiempo que el certificado, luego reconecta ambos dispositivos y compara sus direcciones asignadas. Una dirección duplicada se muestra como pérdida intermitente en lugar de una reconexión limpia.

Envía los ajustes que deban diferir por dispositivo mediante el archivo propio de ese dispositivo, no mediante una plantilla compartida. Una plantilla compartida también hace más difícil detectar el siguiente duplicado.

Retira la identidad antigua como es debido

Revoca el certificado cuando el hardware se retira o se pierde, en lugar de borrar el perfil de la máquina antigua. La revocación produce una CRL nueva, y el servidor necesita ese archivo donde apunta crl-verify. Con esa directiva en su sitio, una CRL ausente o ilegible hace que el servidor rechace a todos los clientes, así que prueba una cuenta conocida después de cada actualización.

Mantén un inventario que ate cada certificado a una persona o dispositivo, con fechas de emisión y de revocación. Ese inventario responde quién sigue teniendo acceso sin leer nombres de archivo, y evita que el siguiente perfil copiado reinicie el bucle.