Manual: integrar dois clientes OpenVPN separadamente

Dois clientes num único anfitrião soam como mais um bloco de servidor e uma segunda porta. Torna-se outro projeto assim que enumera tudo o que um cliente realmente possui: um ouvinte, um pool de túneis, uma identidade, ficheiros de confiança, rotas e um calendário de revogação. Omita um desses itens e o segundo cliente herda silenciosamente uma parte do primeiro. Construa uma ficha por cliente e preencha-a antes de o primeiro cliente se ligar.

Atribua uma ficha de recursos completa por cliente

Reserve o conjunto inteiro em conjunto: porta pública, sub-rede do túnel, caminho de configuração, destino dos registos, nome da instância de serviço e dispositivo. É nomeá-los como grupo que impede a clássica cópia de um ficheiro funcional que ainda contém o pool ou a interface do primeiro cliente. Os valores são exemplos, não portas reservadas, por isso verifique o que o anfitrião já usa. Um serviço que arranca não é o mesmo que um cliente completo.

Mantenha a ficha ao lado da configuração e atualize-a sempre que um valor mudar. A documentação que se afasta da realidade é pior do que nenhuma.

Mantenha o material de confiança dentro de cada cliente

Uma autoridade emissora separada por cliente torna o limite fácil de raciocinar e mantém a chave de assinatura fora do anfitrião exposto à Internet. Uma raiz partilhada também pode funcionar, mas uma âncora comum não transforma dois serviços num único domínio de pertença. Decida que cadeias cada ouvinte aceita e que identidades de cliente autoriza, e depois registe ambas. Não retire certificados de uma cadeia por tentativa e erro até algo se ligar.

A chave privada do próprio servidor pertence a um ficheiro protegido por cliente, não a um diretório de modelos replicado juntamente com a configuração.

Separe as redes tal como os processos

Dois processos em duas portas continuam a partilhar um anfitrião e uma tabela de encaminhamento se não os separar. Confirme o que está à escuta antes de confiar no desenho.

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

A verificação do ouvinte mostra que processo possui cada porta pública, e a validação mostra se um certificado de cliente encadeia na âncora pretendida. Nenhuma das saídas prova que o cliente de A não consegue alcançar a sub-rede de B, por isso defina a política de origem e destino, as rotas de retorno e qualquer serviço deliberadamente partilhado. Os espaços de nomes de rede ou os contentores separam contextos de encaminhamento e reduzem a mistura acidental, mas não são um limite completo de inquilino por si só. Escolha um mecanismo de isolamento mais forte quando o modelo de ameaças o exigir.

Entregue a revogação antes da transferência

Uma implementação de certificados não está completa enquanto a revogação não tiver um caminho de entrega. Verifique o emissor e a janela de validade da CRL como parte da integração.

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

A inspeção da CRL indica quando a lista foi emitida e quando expira, e o estado do serviço confirma que a instância que a lê está em execução. Atualize a lista segundo o calendário da política de emissão mesmo quando nada novo foi revogado, porque uma CRL expirada pode rejeitar todos os clientes. Publique um ficheiro completo em vez de deixar os leitores encontrarem uma escrita parcial, e valide a assinatura antes da implementação. Registe quem possui a emissão, a operação do ponto final e a retirada, para que desligar o cliente A não perturbe B.

Depois execute o par de aceitação: um cliente permitido alcança o seu próprio serviço, e uma credencial de A é rejeitada pelo ouvinte de B. Esse é o limite expresso como teste.