Manual: incorporar dos clientes OpenVPN por separado

Dos clientes en un solo host suenan como un bloque de servidor más y un segundo puerto. Se convierte en otro proyecto cuando enumeras todo lo que un cliente posee en realidad: un oyente, un pool de túneles, una identidad, archivos de confianza, rutas y un calendario de revocación. Omite uno de esos elementos y el segundo cliente hereda en silencio una parte del primero. Crea una ficha por cliente y complétala antes de que se conecte el primer cliente.

Asigna una ficha de recursos completa por cliente

Reserva todo el conjunto a la vez: puerto público, subred del túnel, ruta de configuración, destino de registros, nombre de la instancia de servicio y dispositivo. Nombrarlos como grupo es lo que evita la clásica copia de un archivo que funciona y que aún contiene el pool o la interfaz del primer cliente. Los valores son ejemplos, no puertos reservados, así que comprueba qué usa ya el host. Un servicio que arranca no es lo mismo que un cliente completo.

Mantén la ficha junto a la configuración y actualízala siempre que cambie un valor. La documentación que se aleja de la realidad es peor que ninguna.

Mantén el material de confianza dentro de cada cliente

Una autoridad emisora separada por cliente hace que el límite sea fácil de razonar y mantiene la clave de firma fuera del host expuesto a Internet. Una raíz compartida también puede funcionar, pero un ancla común no convierte dos servicios en un solo dominio de pertenencia. Decide qué cadenas acepta cada oyente y qué identidades de cliente autoriza, y luego escribe ambas cosas. No quites certificados de una cadena probando y fallando hasta que algo se conecte.

La clave privada del propio servidor pertenece a un archivo protegido por cliente, no a un directorio de plantillas que se replica junto con la configuración.

Separa las redes además de los procesos

Dos procesos en dos puertos siguen compartiendo un host y una tabla de enrutamiento si no los separas. Confirma qué escucha antes de confiar en el diseño.

ss -lunp | grep -E '1194|1195'
openssl verify -CAfile customer-a/ca.crt customer-a/client.pem

La comprobación del oyente muestra qué proceso posee cada puerto público, y la verificación muestra si un certificado de cliente encadena con el ancla prevista. Ninguna de las dos salidas demuestra que el cliente de A no pueda alcanzar la subred de B, así que define la política de origen y destino, las rutas de retorno y cualquier servicio compartido deliberadamente. Los espacios de nombres de red o los contenedores separan contextos de enrutamiento y reducen la mezcla accidental, pero no son un límite completo de inquilino por sí solos. Elige un mecanismo de aislamiento más fuerte cuando el modelo de amenazas lo exija.

Entrega la revocación antes del traspaso

Un despliegue de certificados no está completo hasta que la revocación tiene una ruta de entrega. Comprueba el emisor y la ventana de validez de la CRL como parte de la incorporación.

openssl crl -in customer-a/crl.pem -noout -lastupdate -nextupdate
systemctl status openvpn@customer-a

La inspección de la CRL informa de cuándo se emitió la lista y cuándo caduca, y el estado del servicio confirma que la instancia que la lee se está ejecutando. Refresca la lista según el calendario de la política de emisión incluso cuando no se haya revocado nada nuevo, porque una CRL caducada puede rechazar a todos los clientes. Publica un archivo completo en lugar de dejar que los lectores encuentren una escritura parcial, y valida la firma antes del despliegue. Registra quién posee la emisión, la operación del punto final y la retirada, para que apagar al cliente A no perturbe a B.

Después ejecuta el par de aceptación: un cliente permitido llega a su propio servicio, y una credencial de A es rechazada por el oyente de B. Ese es el límite expresado como prueba.