¿Puede un enlace OpenVPN con clave estática atender a varios clientes?

El modo de clave estática conecta exactamente dos pares, y ese es su diseño, no una limitación que alguien olvidó levantar. client-to-client es una opción de reenvío del modo servidor, así que añadirla a una configuración --secret no cambia nada sobre cuántos clientes pueden conectarse. La decisión no es qué indicador añadir, sino si el despliegue necesita un enlace punto a punto o un servicio para varios clientes. Si varios dispositivos deben conectarse de forma independiente, el modo de protección cambia y cada dispositivo obtiene una identidad.

Dos pares, una clave y ningún estado por cliente: esa forma es toda la historia del modo.

Para qué sirve el modo de clave estática

En el modo secreto ambos pares comparten un solo archivo de clave, y esa clave protege el tráfico directamente. No hay saludo, ni intercambio de certificados, ni sesión por cliente, porque no hay clientes en el sentido de servidor, solo dos extremos.

El modo sigue siendo útil para una pareja fija de máquinas con un proceso documentado de rotación de claves, y OpenVPN 2.6 lo marca como obsoleto precisamente porque el modo TLS cubre esos casos con mejores propiedades. Lo que no puede hacer es distinguir un dispositivo conectado de otro, ya que la posesión del archivo es toda la historia de la autenticación. Añadir un tercer dispositivo significa compartir la misma clave con él, y después los dos primeros ya no pueden distinguirlo de sí mismos.

Por eso el límite de dos pares es estructural y no un ajuste que se pueda cambiar.

Por qué client-to-client no es la pieza que falta

client-to-client controla si los clientes conectados pueden intercambiar tráfico a través del servidor. No admite clientes, ni asigna identidades, ni crea un modo servidor que no se haya configurado, y en una configuración de clave estática no hay lista de clientes que pueda gobernar.

La otra confusión habitual afecta al material de tls-crypt o tls-auth. Un servidor TLS puede compartir una de esas claves entre todos los clientes, porque protege el canal de control en lugar de demostrar quién es cada cliente. Una clave compartida del canal de control en modo TLS es un objeto distinto de una clave de datos estática compartida, aunque ambas lleguen como archivos que se parecen.

Elegir entre los modos se reduce a dos preguntas. ¿Debe más de un dispositivo conectarse de forma independiente, y el despliegue necesita revocación por dispositivo? Un no a ambas mantiene viable el modo de clave estática; un sí a cualquiera de las dos apunta al TLS. No hay una tercera opción en la que se admita un segundo cliente sin identidad propia.

Construir el servidor para varios clientes

Un servidor para varios clientes necesita el modo TLS, un certificado del lado del servidor y una identidad por cliente. El asistente del servidor prepara el conjunto de direcciones y el modo multicliente, pero no proporciona la configuración TLS, el ancla de confianza ni los certificados de cliente que hacen significativa la admisión.

Inscriba cada dispositivo a través de la autoridad de certificación existente en lugar de copiar las credenciales de un cliente. Las identidades distintas son lo que hace posibles la revocación, el enrutamiento por cliente y unos registros útiles, y un solo certificado de cliente compartido derrumba las tres cosas.

Si el despliegue autentica usuarios mediante un directorio externo o un segundo factor, ese diseño se mantiene tal cual. Pasar al modo servidor TLS decide cómo los pares se demuestran en la capa de túnel y no dicta el backend de cuentas. Mantenga las dos decisiones separadas para que un cambio en una no altere en silencio la otra.

Después decida la política de reenvío deliberadamente. client-to-client habilita el tráfico entre clientes en la ruta del servidor en espacio de usuario, que muchos despliegues quieren y algunos no deben tener. Es un interruptor de política, no un mecanismo de identidad, y debe activarse porque el diseño lo exige, no porque un tutorial lo incluyera.

Comprobar que los clientes son realmente independientes

Conecte dos clientes y confirme que reciben direcciones distintas y que aparecen con identidades distintas en el registro del servidor. Luego revoque uno y confirme que el otro sigue funcionando, que es la prueba práctica de que las identidades no se compartieron.

Pruebe el servicio permitido entre pares y uno que deba permanecer bloqueado. Dos inicios de sesión correctos demuestran la admisión, no el aislamiento, y la diferencia importa cuando el despliegue debe separar grupos de usuarios.

Por último, lea el modo servidor desde la configuración en ejecución y no de memoria. Una configuración de clave estática con opciones adicionales sigue siendo un enlace punto a punto, y un servidor TLS correcto es la única disposición en la que varios clientes son pares realmente separados.

Si el registro muestra un solo nombre común para cada dispositivo, el problema no es el modo. El problema es el proceso de inscripción.