¿Clave estática o TLS para un enlace OpenVPN entre dos pares?

Dos máquinas que solo hablan entre sí pueden conservar esa topología y aun así obtener claves de tráfico negociadas. La forma de la red y el modo de protección son decisiones independientes, y confundirlas es lo que lleva a la gente a intentar rotar un secreto estático intercambiando un archivo mientras ambos demonios siguen en ejecución. Cambiar el archivo de claves bajo una pareja en funcionamiento no rota nada. El modo de clave estática, que OpenVPN 2.6 marca como obsoleto, mantiene una sola clave durante toda la vida del túnel, así que el archivo en disco y la clave en memoria solo vuelven a coincidir después de que ambos extremos se reinicien. Si el requisito es la renovación automática, el modo de protección tiene que cambiar.

Lo que el modo de clave estática no puede hacer

En modo secreto, ambos pares comparten una clave precompartida que cifra y autentica el túnel directamente. No hay handshake, así que no hay mecanismo para que ningún lado proponga material de clave nuevo, demuestre una identidad o se recupere de una discrepancia sin intervención del operador. Ambas propiedades derivan de la ausencia de un canal de control y no de una opción que falte, y ninguna bandera de configuración añade una a este modo.

El manual de OpenVPN 2.6 es explícito en que la clave persiste hasta que se genera una nueva. Eso es aceptable para un enlace de laboratorio o una pareja fija de dispositivos con un procedimiento de rotación documentado, y es inaceptable donde un secreto de larga vida sea un riesgo real. Cambiar un archivo no crea una clave nueva para una pareja en funcionamiento; crea dos pares que no coinciden. Sustituir el archivo, por tanto, añade una interrupción sin añadir rotación.

Tampoco existe noción de identidad de par más allá de la posesión del archivo. Quien tenga la clave es un par, y nada en el túnel registra qué lado es cuál, así que la revocación es todo o nada.

Pasar a TLS sin rediseñar el enlace

El modo TLS añade un canal de control y, con él, la capacidad de negociar claves del canal de datos. En un despliegue punto a punto, un lado asume el papel de servidor y el otro el de cliente, pero la topología sigue siendo un enlace entre dos pares: cada lado conoce el extremo del otro y no aparece ningún grupo ni servicio multiusuario. Los papeles son un detalle del handshake, no una arquitectura nueva.

Dé a cada máquina su propia identidad. Cada lado necesita un certificado y una clave privada, el ancla de confianza que valida al otro y una regla de verificación de par que nombre a quién se espera. No reutilice la clave privada de un par en el otro para ahorrar tiempo; eso convierte dos identidades en una y elimina la capacidad de revocar cualquiera de los lados por separado. La inscripción es el lugar para hacerlo bien, porque corregirlo después significa reemitir certificados.

Mantenga el contrato de red sin cambios mientras cambia la protección. Las mismas direcciones de túnel, rutas y servicios permitidos deberían aplicarse antes y después, de modo que un fallo durante la migración sea un problema de protección y no una sorpresa de enrutamiento disfrazada. Anote las direcciones y las rutas antes del cambio; compararlas después es más rápido que reconstruirlas de memoria.

Algunos despliegues también protegen el canal de control con su propia clave estática, que no rota con el canal de datos. Esa clave protege el handshake y no la carga útil, así que comprometerla expone la negociación y no el tráfico. Guárdela aparte del material del canal de datos y dele una fecha de sustitución de la que sea responsable una persona concreta. Rotarla significa reiniciar ambos pares en una ventana coordinada, por lo que merece una entrada en el calendario y no un recuerdo.

Quién renueva qué, y cuándo

En modo TLS, la renovación se rige por límites configurados: un intervalo de tiempo, un recuento de bytes o un recuento de paquetes. El control de tiempo documentado es en el que se apoya la mayoría de los despliegues, y el valor efectivo más bajo entre ambos pares puede iniciar la sustitución, así que subirlo solo en un lado no frenará el evento. Los límites por volumen existen porque un enlace ocupado puede agotar una clave mucho antes de que lo haga el reloj. Ninguno de los límites es una comprobación de salud y ninguno le dice que una renovación haya tenido éxito.

Por eso diagnosticar una renegociación recurrente a partir de un solo archivo de configuración es engañoso. Lea los ajustes en ambos pares y luego mire la transición en el registro en lugar de suponer una avería. Una renovación que se completa limpiamente parece una ráfaga corta de tráfico del canal de control, no una desconexión.

Mantenga los objetos separados en su cabeza. El certificado demuestra identidad a largo plazo y se sustituye según un calendario que usted controla. La clave del canal de datos se refresca automáticamente, y un intercambio de autenticación separado, si el despliegue lo requiere, sigue la política de la cuenta y puede necesitar sus propios arreglos para intercambios posteriores.

Desactivar la renovación por completo, poniendo el intervalo a cero, no es una solución para un registro ruidoso. Convierte un evento sano del ciclo de vida en una clave permanente, lo que le devuelve a la propiedad de la que intentaba salir.

Aceptar el cambio

Construya la configuración nueva a partir del ejemplo admitido de la versión instalada, no de un fragmento mínimo antiguo cuyos algoritmos y rutas de archivo se heredaron de otro sitio. Coordine el cambio para que ambos pares se modifiquen juntos y mantenga una ruta de recuperación aprobada por si un lado no arranca. Baje el enlace deliberadamente en lugar de esperar una interrupción para probar la reversión. Una reversión que ha ensayado vale más que una reversión que ha descrito.

Pruebe tres cosas: la verificación inicial de identidad tiene éxito, el flujo de aplicación previsto funciona y una renovación controlada ocurre sin perder tráfico. Después lea la transición en el registro por lo que demuestra realmente: un identificador de clave nuevo significa que los pares completaron una sustitución, no que el túnel se haya reconectado. Trátelo como evidencia de un paso y revise los contadores de tráfico antes de dar la migración por terminada.

Lo que una promesa de cero interrupciones ocultaría es el fallo que todavía no ha visto. Una renovación que falla, un certificado que caduca o un defecto de ruta aún pueden perturbar el enlace, y ninguno queda descartado por una prueba limpia. La propiedad por la que vale la pena diseñar es más estrecha y más útil: la sustitución rutinaria de claves deja de ser un cambio manual de archivo.