Pode unha ligazón OpenVPN con clave estática atender varios clientes?

O modo de clave estática conecta exactamente dous pares, e ese é o seu deseño, non unha limitación que alguén esqueceu levantar. client-to-client é unha opción de reenvío do modo servidor, así que engadila a unha configuración --secret non cambia nada sobre cantos clientes se poden conectar. A decisión non é que indicador engadir, senón se o despregamento necesita unha ligazón punto a punto ou un servizo para varios clientes. Se varios dispositivos deben conectarse de forma independente, o modo de protección cambia e cada dispositivo obtén unha identidade.

Dous pares, unha clave e ningún estado por cliente: esa forma é toda a historia do modo.

Para que serve o modo de clave estática

No modo secreto ambos os pares comparten un único ficheiro de clave, e esa clave protexe o tráfico directamente. Non hai aperta de mans, nin intercambio de certificados, nin sesión por cliente, porque non hai clientes no sentido de servidor, só dous extremos.

O modo segue sendo útil para unha parella fixa de máquinas cun proceso documentado de rotación de claves, e OpenVPN 2.6 márcao como obsoleto precisamente porque o modo TLS cobre eses casos con mellores propiedades. O que non pode facer é distinguir un dispositivo conectado doutro, xa que a posesión do ficheiro é toda a historia da autenticación. Engadir un terceiro dispositivo significa compartir a mesma clave con el, e despois os dous primeiros xa non poden distinguilo de si mesmos.

Por iso o límite de dous pares é estrutural e non un axuste que se poida cambiar.

Por que client-to-client non é a peza que falta

client-to-client controla se os clientes conectados poden intercambiar tráfico a través do servidor. Non admite clientes, nin asigna identidades, nin crea un modo servidor que non se configurase, e nunha configuración de clave estática non hai lista de clientes que poida gobernar.

A outra confusión habitual afecta o material de tls-crypt ou tls-auth. Un servidor TLS pode compartir unha desas claves entre todos os clientes, porque protexe a canle de control en lugar de demostrar quen é cada cliente. Unha clave compartida da canle de control en modo TLS é un obxecto distinto dunha clave de datos estática compartida, aínda que ambas cheguen como ficheiros que se parecen.

Escoller entre os modos redúcese a dúas preguntas. Debe máis dun dispositivo conectarse de forma independente, e o despregamento necesita revogación por dispositivo? Un non a ambas mantén viable o modo de clave estática; un si a calquera das dúas apunta ao TLS. Non hai unha terceira opción na que se admita un segundo cliente sen identidade propia.

Construír o servidor para varios clientes

Un servidor para varios clientes necesita o modo TLS, un certificado do lado do servidor e unha identidade por cliente. O asistente do servidor prepara o conxunto de enderezos e o modo multicliente, pero non proporciona a configuración TLS, a áncora de confianza nin os certificados de cliente que fan significativa a admisión.

Inscriba cada dispositivo a través da autoridade de certificación existente en lugar de copiar as credenciais dun cliente. As identidades distintas son o que fai posibles a revogación, o enrutamento por cliente e uns rexistros útiles, e un só certificado de cliente compartido derruba as tres cousas.

Se o despregamento autentica usuarios mediante un directorio externo ou un segundo factor, ese deseño mantense tal cal. Pasar ao modo servidor TLS decide como os pares se demostran na capa de túnel e non dita o backend de contas. Manteña as dúas decisións separadas para que un cambio nunha non altere en silencio a outra.

Despois decida a política de reenvío deliberadamente. client-to-client habilita o tráfico entre clientes na ruta do servidor en espazo de usuario, que moitos despregamentos queren e algúns non deben ter. É un interruptor de política, non un mecanismo de identidade, e debe activarse porque o deseño o esixe, non porque un titorial o incluíse.

Comprobar que os clientes son realmente independentes

Conecte dous clientes e confirme que reciben enderezos distintos e que aparecen con identidades distintas no rexistro do servidor. Despois revogue un e confirme que o outro segue funcionando, que é a proba práctica de que as identidades non se compartiron.

Probe o servizo permitido entre pares e un que deba permanecer bloqueado. Dous inicios de sesión correctos demostran a admisión, non o illamento, e a diferenza importa cando o despregamento debe separar grupos de usuarios.

Por último, lea o modo servidor desde a configuración en execución e non de memoria. Unha configuración de clave estática con opcións adicionais segue sendo unha ligazón punto a punto, e un servidor TLS correcto é a única disposición na que varios clientes son pares realmente separados.

Se o rexistro mostra un só nome común para cada dispositivo, o problema non é o modo. O problema é o proceso de inscrición.