☰

Melhores práticas para configurar múltiplas instâncias OpenVPN para diferentes clientes

tag-icon • tag-icon linux vpn openvpn pki
Melhores práticas para configurar múltiplas instâncias OpenVPN para diferentes clientes

Estou trabalhando em um projeto onde preciso configurar instâncias OpenVPN para conectar dispositivos IoT de vários clientes a um servidor central. Cada cliente deve ter sua própria conexão VPN isolada. Atualmente estou planejando a infraestrutura e o manuseio de certificados e gostaria de alguns conselhos sobre a melhor abordagem.

Para manipulação de certificados, estou considerando a seguinte estrutura:

CA.crt
|_Customer1.crt
|  |_ServerCert.crt
|     |_ClientCert1.crt
|     |_ClientCert2.crt
|     |_ClientCertX.crt
|
|_Customer2.crt
   |_ServerCert.crt
      |_ClientCert1.crt
      |_ClientCert2.crt
      |_ClientCertX.crt

Então, eu configuraria uma instância OpenVPN separada para cada cliente, como /etc/openvpn/server/Client1/e /etc/openvpn/server/Client2/, e os iniciaria usando comandos como:

sudo systemctl start [email protected] Esta é uma abordagem aceitável? Eu apreciaria qualquer informação ou sugestão alternativa para organizar a infraestrutura para vários clientes e servidores VPN.

Outras perguntas são:

  • Como gerenciar muitos dispositivos descentralizados, talvez Ansible?
  • Para cada instância OpenVPN, preciso de uma porta extra.
    • Depois de usar 443 TCP, UDP e 1194 TCP, UDP, o que vem a seguir?

Obrigado!

Responder1

O manual do OpenVPN afirma que ele confiará em qualquer certificado descendente do certificado CA que você configurou nele. Portanto, para realmente separar as VPNs, você omite o certificado raiz de todas as configurações. Não será usado em lugar nenhum, não agrega valor ou benefício, então por que se preocupar em mantê-lo? Basta pegar o EasyRSA e criar uma CA "raiz, de nível único" separada e independente para cada VPN.

Não sei por que você listou a porta 443 aqui; raramente é usado para OpenVPN porque é uma porta HTTPS bem conhecida e geralmente está ocupada; portanto, quando é usado, geralmente são configurações complicadas envolvendo port-share. Nesse caso, sslhé superior, pelo menos porque você pode usar seu "modo transparente" para que os daemons vejam o IP real do remoto e não se preocupem com a forma como o OpenVPNs disponibiliza essa informação. Embora eu duvide que você precise dessa peculiaridade para o seu projeto. Fora isso, você pode usar números de porta arbitrários. 1194 está listado como "oficial", mas nada proíbe definir 11941, 1195 ou 5000 (o que foi sugerido há quinze anos) ou qualquer outra coisa. Escolha um conjunto de portas, digamos começando com 1194 e superior, e apenas adicione uma para cada instância VPN sucessiva.

O resto está correto: você usa portas separadas (públicas) para daemons independentes e as executa como unidades SystemD separadas. Considere contêineres separados para VPNs diferentes: embora seja possível executar instâncias VPN separadas em um único namespace, é mais fácil e menos sujeito a erros apenas dividi-las (e não consome muito mais recursos). Pelo que entendi, seus clientes são entidades não relacionadas, então essa seria uma maneira mais direta de separá-los. Nesse caso, as configurações de VPN dentro dos contêineres podem usar a porta padrão, mas você encaminhará (publicará) portas diferentes para elas.

Designe algum sistema exclusivamente para gerenciamento de VPNs; ele armazenará suas CAs e somente ele poderá emitir certificados. Esse sistema também será necessário para emitir LCRs; por padrão, as CRLs duram 30 dias e, se você configurar crl-verify(você irá!), quando a CRL expirar, a VPN deixará de aceitar novas conexões até que seja válida novamente. Então, o que você realmente precisa para automatizar é a reemissão e distribuição de CRL. Ao atualizar o arquivo CRL, você não precisa recarregar o daemon, portanto, simples scppara o sistema de destino sobre o arquivo antigo é suficiente.

É útil criar um modelo de arquivo de configuração de cliente OpenVPN e gerar configurações de cliente com certificados incorporados a partir desse modelo; isso me economizou muito tempo, mesmo sem o Ansible. Costumo personalizar pacotes openssl.cnfe varsarquivos para adicionar vários campos e remover os não utilizados, e para reorganizar as coisas e para que sejam executados com menos perguntas (ou sem perguntas, para processamento em lote). Para o seu caso, pode ser útil ter esses modelos e scripts de geração para criar novas VPNs e configurações de servidores também. Esses modelos, scripts e personalizações serão úteis para manuais do Ansible que instanciam um novo cliente ou um novo dispositivo IoT de um cliente existente. Para este último, pode ser interessante vincular o CN do certificado ao número de série do dispositivo IoT, o que deve simplificar a contabilidade.

informação relacionada