Manual: incorporar dous clientes OpenVPN por separado

Dous clientes nun só host soan como un bloque de servidor máis e un segundo porto. Convértese noutro proxecto cando enumeras todo o que un cliente posúe realmente: un oínte, un pool de túneles, unha identidade, ficheiros de confianza, rutas e un calendario de revocación. Omite un deses elementos e o segundo cliente herda en silencio unha parte do primeiro. Constrúe unha ficha por cliente e énchea antes de que se conecte o primeiro cliente.

Asigna unha ficha de recursos completa por cliente

Reserva todo o conxunto á vez: porto público, subrede do túnel, ruta de configuración, destino dos rexistros, nome da instancia de servizo e dispositivo. Nomealos como grupo é o que evita a clásica copia dun ficheiro que funciona e que aínda contén o pool ou a interface do primeiro cliente. Os valores son exemplos, non portos reservados, así que comproba que usa xa o host. Un servizo que arrinca non é o mesmo que un cliente completo.

Mantén a ficha xunto á configuración e actualízaa sempre que cambie un valor. A documentación que se afasta da realidade é peor que ningunha.

Mantén o material de confianza dentro de cada cliente

Unha autoridade emisora separada por cliente fai que o límite sexa fácil de razoar e mantén a clave de sinatura fóra do host exposto a Internet. Unha raíz compartida tamén pode funcionar, pero unha áncora común non converte dous servizos nun só dominio de pertenza. Decide que cadeas acepta cada oínte e que identidades de cliente autoriza, e despois escribe ambas as dúas. Non quites certificados dunha cadea probando e fallando ata que algo se conecte.

A clave privada do propio servidor pertence a un ficheiro protexido por cliente, non a un directorio de modelos que se replica xunto coa configuración.

Separa as redes ademais dos procesos

Dous procesos en dous portos seguen compartindo un host e unha táboa de enrutamento se non os separas. Confirma que escoita antes de confiar no deseño.

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

A comprobación do oínte mostra que proceso posúe cada porto público, e a verificación mostra se un certificado de cliente encadea coa áncora prevista. Ningunha das dúas saídas demostra que o cliente de A non poida alcanzar a subrede de B, así que define a política de orixe e destino, as rutas de retorno e calquera servizo compartido deliberadamente. Os espazos de nomes de rede ou os contedores separan contextos de enrutamento e reducen a mestura accidental, pero non son un límite completo de inquilino por si sós. Escolle un mecanismo de illamento máis forte cando o modelo de ameazas o esixa.

Entrega a revocación antes do traspaso

Un despregamento de certificados non está completo ata que a revocación ten unha ruta de entrega. Comproba o emisor e a xanela de validez da CRL como parte da incorporación.

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

A inspección da CRL informa de cando se emitiu a lista e cando caduca, e o estado do servizo confirma que a instancia que a le está en execución. Refresca a lista segundo o calendario da política de emisión mesmo cando non se revogou nada novo, porque unha CRL caducada pode rexeitar todos os clientes. Publica un ficheiro completo en lugar de deixar que os lectores atopen unha escritura parcial, e valida a sinatura antes do despregamento. Rexistra quen posúe a emisión, a operación do punto final e a retirada, para que apagar o cliente A non perturbe B.

Despois executa o par de aceptación: un cliente permitido chega ao seu propio servizo, e unha credencial de A é rexeitada polo oínte de B. Ese é o límite expresado como proba.