Desempenho do OpenVPN: quantos clientes simultâneos são possíveis?

Estou avaliando um sistema para um cliente em que muitos clientes OpenVPN se conectam a um servidor OpenVPN. "Muitos" significa 50000 - 1000000.

Por que eu faço isso? Os clientes são sistemas embarcados distribuídos, cada um sentado atrás do roteador dsl dos proprietários do sistema. O servidor precisa poder enviar comandos para os clientes. Minha primeira abordagem ingênua é fazer com que os clientes se conectem ao servidor por meio de uma rede openvpn. Dessa forma, o túnel de comunicação seguro pode ser usado nas duas direções.

Isso significa que todos os clientes estão sempre conectados ao servidor. Há muitos clientes resumindo ao longo dos anos.

A questão é: o servidor OpenVPN explode ao atingir um certo número de clientes? Já estou ciente de um limite máximo de número de conexão TCP, portanto (e por outros motivos) a VPN precisaria usar o transporte UDP.

Gurus do OpenVPN, qual a sua opinião?

Eu duvido que uma configuração tão grande já tenha sido tentada antes, então você provavelmente estará empurrando limites ao tentar. Eu pude encontrar um artigo sobre uma implantação de VPN para 400 clientes, mas, a julgar pelo texto, o autor apenas se baseou em estimativas aproximadas de quantos clientes poderiam ser executados por CPU e não tinha um entendimento sobre o desempenho da instalação.

Você precisaria principalmente considerar esses dois pontos:

1. A largura de banda que suas transferências de dados usarão precisaria de criptografia / descriptografia no servidor VPN, consumindo recursos da CPU

2. As conexões do cliente OpenVPN consomem recursos de memória e CPU no servidor, mesmo quando nenhum dado é transferido

Qualquer hardware decente de PC disponível hoje deve saturar facilmente um link Gigabit com Blowfish ou AES-128, até dispositivos embarcados de US $ 100 são capazes de taxas próximas a 100 Mbps , portanto, gargalos na CPU devido à intensidade da largura de banda não devem ser motivo de preocupação.

Dado o intervalo de repetição padrão de 3600 segundos, um número de 1.000.000 de clientes significaria que o servidor precisaria concluir 278 trocas de chaves por segundo, em média. Embora uma troca de chaves seja uma tarefa bastante intensiva da CPU, você pode transferi-la para um 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 qualquer restrição de memória virtual que você provavelmente enfrentaria.

Mas a verdadeira beleza do OpenVPN é que você pode escalá-lo facilmente - basta configurar um número arbitrário de servidores OpenVPN e garantir que seus clientes os estejam usando (por exemplo, através de round-robin DNS), configurar um protocolo de roteamento dinâmico de sua escolha (normalmente, isso seria RIP devido à sua simplicidade) e sua infraestrutura seria capaz de suportar um número arbitrário de clientes, desde que você tenha hardware suficiente.

Eu realmente fiz isso, embora com "apenas" algumas centenas de conexões remotas da mesma forma atrás de roteadores DSL. Não posso comentar muito sobre as questões de rekeying, mas algumas coisas práticas que aprendi ao longo do caminho:

1) Ao implantar clientes, especifique vários servidores VPN na conf client, vpn1.example.com, vpn2.example.com, vpn3 ..... Mesmo se você fornecer apenas um ou dois deles agora, você fornece você mesmo espaço. Configurados corretamente, os clientes continuarão repetindo-os aleatoriamente até encontrar um que funcione.

2) Usamos uma imagem personalizada do servidor VPN da AWS e podemos aumentar a capacidade sob demanda, e o Amazon DNS (R53) lida com o lado do DNS. É completamente separado do restante de nossa infraestrutura.

3) No final do servidor, faça um uso cuidadoso da máscara de rede para restringir o número de clientes em potencial. Isso deve forçar os clientes a um servidor alternativo, mitigando os problemas de CPU. Acho que limitamos nossos servidores a mais ou menos 300 clientes. Essa escolha foi um tanto arbitrária da nossa parte - "instinto", se quiser.

4) Também no final do servidor, você deve fazer uso cuidadoso de firewalls. Em termos simples, temos o nosso configurado para que os clientes possam conectar-se à VPN, mas os servidores proíbem estritamente todas as conexões ssh de entrada, exceto um endereço IP conhecido. Podemos fazer o SSH para os clientes, se precisarmos ocasionalmente, eles não podem fazer o SSH para nós.

5) Não confie no OpenVPN para reconectar você no final do cliente. 9 vezes em 10, mas às vezes fica preso. Tenha um processo separado para redefinir / reiniciar o openVPN no final do cliente regularmente.

6) Você precisa de uma maneira de gerar chaves exclusivas para os clientes, para poder rejeitá-las às vezes. Nós os geramos internamente com nosso processo de criação de servidor (PXEboot). Nunca aconteceu conosco, mas sabemos que podemos fazê-lo.

7) Você precisará de algumas ferramentas de gerenciamento, scripts para monitorar efetivamente as conexões do servidor VPN.

Infelizmente, não há muito material sobre como fazer isso, mas é possível, com uma configuração cuidadosa.

Atualização 2018

Não tenho certeza do que tudo mudou desde 2012. Só queria atualizar a minha experiência em 2018. Implantamos uma rede openvpn muito semelhante à configuração do OP. Nossos terminais são PCs Linux completos, em vez de dispositivos incorporados. Cada terminal possui um monitor usado para exibir informações e alarmes para esse site e nosso servidor nos permite um único ponto para remotamente em todos os terminais. A rede não está excessivamente ativa, mas às vezes possui 5 a 10 sessões remotas simultaneamente.

Usando uma compilação atual do openvpn em cerca de 100 clientes em uma imagem azul com um único núcleo e 2 GB de RAM, usamos cerca de 0,7% da memória em média e o uso da CPU é quase sempre em torno de 0%. Com base no que encontrei para esse teste menor, acho que um único servidor com especificações decentes lidaria facilmente com 50000 simultâneos se tivesse o RAM para suportá-lo. Se o uso da memória RAM for escalonado linearmente, então 16GB poderão lidar com 50000 usuários com o suficiente em uma máquina openvpn dedicada.

Não estamos em uma escala suficientemente grande para dizer isso com confiança significativa, mas eu só queria fazer uma atualização recente, pois ao implantar originalmente nossa rede, encontrei isso e esperava muito mais uso de recursos nessa escala. Agora, acredito que a CPU que executa isso tem criptografia de hardware e não tenho certeza em que ponto seria sobrecarregado o tráfego, mas para os terminais que não se comunicam muito, isso não deve ser um problema.

Em 1000000, você precisaria de 200 GB de RAM em uma única máquina (se dimensionada linearmente com extra), enquanto isso é possível, eu pensaria que naquele momento você gostaria de ter 5 máquinas cada uma com 64 GB de RAM, para que você não tenha um único ponto. de falha. Isso deve permitir manutenção, reinicializações e substituições de 1 ou até 2 máquinas sem problemas significativos.

Minhas estimativas de RAM provavelmente são um exagero, pois estou dividindo todo o uso do openvpn pelo número de clientes, onde apenas uma parte dessa RAM é devida a clientes.

Adicionamos 74 pontos de extremidade em um ano desde a implantação inicial. Espero continuar a aumentar esse número significativamente e fará uma atualização adicional se chegarmos a uma escala decente.

Estou analisando um problema semelhante, embora o número de clientes esteja em centenas, talvez alguns milhares.

Achei que não conseguia 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 consultados. Se eles fossem, deveriam enviar um email ou algo que estivesse online e enviar manter pacotes ativos por um período de tempo para que eu pudesse conectar-me 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 conectados no momento ...