Estou avaliando um sistema para um cliente onde muitos clientes OpenVPN se conectam a um servidor OpenVPN. "Muitos" significa 50.000 - 1.000.000.
Por que eu faço isso? Os clientes são sistemas embarcados distribuídos, cada um atrás do roteador dsl do proprietário do sistema. O servidor precisa ser capaz de enviar comandos aos clientes. Minha primeira abordagem ingênua é fazer com que os clientes se conectem ao servidor através de uma rede openvpn. Desta forma, o túnel de comunicação seguro pode ser utilizado em ambas as direções.
Isso significa que todos os clientes estão sempre conectados ao servidor. São muitos clientes resumindo ao longo dos anos.
A questão é:o servidor OpenVPN explode ao atingir um determinado número de clientes? Já estou ciente de um limite máximo de número de conexões TCP, portanto (e por outros motivos) a VPN teria que usar o transporte UDP.
Gurus do OpenVPN, qual a sua opinião?
Responder1
Duvido que uma configuração tão grande já tenha sido tentada antes, então você provavelmente estará ultrapassando os limites ao tentar. Eu poderia encontrar um artigo sobre umImplantação de VPN para 400 clientesmas a julgar pelo texto, o autor apenas se baseou em estimativas aproximadas sobre quantos clientes poderiam ser executados por CPU e não tinha algum entendimento sobre o desempenho de sua configuração.
Você precisaria considerar principalmente estes dois pontos:
A largura de banda que suas transferências de dados usarão precisaria de criptografia/descriptografia no lado do servidor VPN, consumindo recursos da CPU
As conexões do cliente OpenVPN consomem recursos de memória e CPU no servidor, mesmo quando nenhum dado é transferido
Qualquer hardware de PC decente disponível hoje deve saturar facilmente um link Gigabit com Blowfish ou AES-128, até mesmo dispositivos embarcados de US$ 100 sãocapaz de taxas próximas a 100 Mbps, portanto, gargalos de CPU devido à intensidade da largura de banda não devem ser motivo de preocupação.
Dado o intervalo de rechaveamento padrão de 3.600 segundos, um número de 1.000.000 de clientes significaria que o servidor precisaria ser capaz de concluir, em média, 278 trocas de chaves por segundo. Embora uma troca de chaves seja uma tarefa que exige bastante CPU, você pode descarregá-la para hardware dedicado, se necessário - as placas aceleradoras criptográficas disponíveis atendem e excedem facilmente esse número de handshakes TLS. E as restrições de memória também não devem incomodar muito - um binário de 64 bits deve cuidar de quaisquer restrições de memória virtual que você provavelmente atingiria de outra forma.
Mas a verdadeira beleza do OpenVPN é que você pode escaloná-lo facilmente - basta configurar um número arbitrário de servidores OpenVPN e certificar-se de que seus clientes os estão usando (por exemplo, através de round-robin de DNS), configurar um protocolo de roteamento dinâmico de sua escolha (normalmente seria RIP devido à sua simplicidade) e sua infraestrutura seria capaz de suportar um número arbitrário de clientes, desde que você tivesse hardware suficiente.
Responder2
Na verdade, eu fiz isso, embora com "apenas" algumas centenas de conexões remotas por trás de roteadores DSL. Não posso comentar muito sobre as questões de rechaveamento, mas aprendi algumas coisas práticas ao longo do caminho:
1) Ao implantar clientes, certifique-se de especificar vários servidores VPN na configuração do cliente, vpn1.example.com, vpn2.example.com, vpn3..... Mesmo que você forneça apenas um ou dois deles agora, você fornece você mesmo espaço livre. Configurados corretamente, os clientes continuarão tentando-os aleatoriamente até encontrarem um que funcione.
2) Usamos uma imagem de servidor VPN AWS personalizada e podemos aumentar a capacidade adicional sob demanda, e o Amazon DNS (R53) cuida do lado DNS das coisas. Está completamente separado do resto da nossa infraestrutura.
3) No final do(s) servidor(es), faça uso cuidadoso da máscara de rede para restringir o número de clientes potenciais. Isso deve forçar os clientes a um servidor alternativo, mitigando os problemas de CPU. Acho que limitamos nossos servidores a cerca de 300 clientes. Essa escolha foi um tanto arbitrária de nossa parte - "instinto", se preferir.
4) Também no servidor, você deve fazer uso cuidadoso de firewalls. Em termos simples, configuramos o nosso de forma que os clientes possam se conectar por VPN, mas os servidores proíbem estritamente todas as conexões ssh de entrada, exceto de um endereço IP conhecido. Podemos fazer SSH para os clientes se ocasionalmente precisarmos, eles não podem fazer SSH para nós.
5) Não confie no OpenVPN para fazer a reconexão para você no lado do cliente. 9 em cada 10 vezes isso acontece, mas às vezes fica preso. Tenha um processo separado para redefinir/reiniciar o openVPN regularmente no cliente.
6) Você precisa de uma maneira de gerar chaves exclusivas para os clientes, para que às vezes possa rejeitá-las. Nós os geramos internamente com nosso processo de construção de servidor (PXEboot). Nunca aconteceu conosco, mas sabemos que podemos fazer isso.
7) Você precisará de algumas ferramentas de gerenciamento e scripts para monitorar efetivamente as conexões do servidor VPN.
Infelizmente não há muito material por aí sobre como fazer isso, mas é possível, com uma configuração cuidadosa.
Responder3
Atualização 2018
Não tenho certeza do que tudo mudou desde 2012. Só queria atualizar minha experiência em 2018. Implantamos uma rede openvpn muito semelhante à configuração do OP. Nossos endpoints são PCs Linux completos em vez de dispositivos incorporados. Cada endpoint possui um monitor usado para exibir informações e alarmes para aquele site e nosso servidor nos permite um único ponto de acesso remoto a todos os endpoints. A rede não está excessivamente ativa, mas às vezes tem de 5 a 10 sessões remotas simultaneamente.
Usando uma versão atual do openvpn com cerca de 100 clientes em uma imagem azul com um único núcleo e 2 GB de RAM, usamos cerca de 0,7% de memória em média e o uso da CPU é quase sempre em torno de 0%. Com base no que descobri neste teste menor, imagino que um único servidor com especificações decentes lidaria facilmente com 50.000 simultâneos se tivesse memória RAM para suportá-lo. Se o uso de RAM fosse dimensionado linearmente, 16 GB seriam capazes de lidar com 50.000 usuários com extra suficiente em uma máquina openvpn dedicada.
Não estamos em uma escala grande o suficiente para dizer isso com confiança significativa, mas eu só queria dar uma atualização recente, pois quando implantei originalmente nossa rede, descobri isso e esperava muito mais uso de recursos nessa escala. Agora, acredito que a CPU que executa isso possui criptografia de hardware e não tenho certeza em que ponto isso ficaria sobrecarregado em termos de tráfego, mas para endpoints que não se comunicam muito, isso não deve ser um problema.
Em 1.000.000, você precisaria de 200 GB de RAM em uma única máquina (se dimensionado linearmente com extra), embora isso seja possível, acho que nesse ponto você gostaria de ter 5 máquinas, cada uma com 64 GB de RAM, para não ter um único ponto de fracasso. Isto deve permitir manutenção, reinicializações e substituições de 1 ou até 2 máquinas sem problemas significativos.
Minhas estimativas de memória RAM são provavelmente um exagero, já que estou dividindo todo o uso do openvpn pelo número de clientes, onde apenas uma parte dessa memória RAM é devida aos clientes.
Adicionamos 74 endpoints em um ano desde a implantação inicial. Espero continuar a aumentar esse número significativamente e farei mais uma atualização se chegarmos a uma escala decente.
Responder4
Estou investigando um problema semelhante, embora o número de clientes seja de centenas, talvez alguns milhares.
Achei que não posso manter todos os clientes conectados o tempo todo.
Estou pensando em iniciar o daemon OpenVPN em clientes em intervalos de tempo aleatórios para que eles possam verificar se foram pesquisados. Se fossem, eles deveriam enviar um e-mail ou algo assim que estivessem online e enviar pacotes keep alive por um período de tempo para que eu pudesse me conectar a eles.
Se não houver tráfego por algum tempo, o daemon será interrompido.
O problema que estou enfrentando agora é que parece impossível obter uma lista de clientes VPN atualmente conectados...