Desempenho do OpenVPN: quantos clientes concorrentes são possíveis?

Question

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 distribuídos sistemas embarcados, cada um sentado atrás do roteador dsl proprietários do sistema. O servidor precisa ser capaz de 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 em ambas as 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? Eu já estou ciente de um limite máximo de número de conexão TCP, portanto (e por outros motivos) a VPN teria que usar o transporte UDP.

Gurus do OpenVPN, qual é a sua opinião?

    

Answer 1

Eu duvido que uma configuração tão grande tenha sido tentada antes, então você provavelmente estará forçando limites ao tentar. Eu encontrei um artigo sobre uma implantação de VPN para 400 clientes , mas julgando No texto, o autor baseava-se em estimativas aproximadas sobre quantos clientes poderiam ser executados por CPU e não entendia como sua configuração funcionaria.

Você precisa considerar principalmente esses dois pontos:

1. A largura de banda que suas transferências de dados vão usar precisaria de criptografia / descriptografia no lado do 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 de PC decente disponível hoje deve facilmente saturar um link Gigabit com Blowfish ou AES-128, até mesmo dispositivos incorporados de $ 100 são capazes de taxas próximas a 100 Mbps , portanto, os gargalos da CPU devido à intensidade da largura de banda não devem ser motivo de preocupação.

Dado o intervalo de recriaçã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 que exige bastante uso da CPU, você pode descarregá-la em 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 usaria de outra forma.

Mas a verdadeira beleza com o OpenVPN é que você pode escalá-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 infra-estrutura seria capaz de suportar um número arbitrário de clientes, desde que você tenha hardware suficiente.

    

Answer 2

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 os problemas de rediscagem, mas algumas coisas práticas que aprendi ao longo do caminho:

1) Ao implantar clientes, certifique-se de especificar vários servidores VPN no cliente conf, vpn1.example.com, vpn2.example.com, vpn3 ..... Mesmo se você fornecer apenas um ou dois deles agora , você se dá espaço livre. Configurados corretamente, os clientes continuarão tentando novamente aleatoriamente até encontrarem um que funcione.

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

3) No (s) servidor (es) final (es), faça uso cuidadoso da máscara de rede para restringir o número de potenciais clientes. Isso deve forçar os clientes a um servidor alternativo, atenuando os problemas da CPU. Acho que limitamos nossos servidores a 300 ou mais clientes. Esta escolha foi um pouco arbitrária da nossa parte - "intuição" se você gosta.

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

5) Não confie no OpenVPN fazendo a reconexão para você no cliente final. 9 vezes fora de 10 será, mas às vezes fica preso. Ter um processo separado para redefinir / reiniciar o openVPN no cliente regularmente.

6) Você precisa de uma maneira de gerar chaves exclusivas para os clientes para que você possa rejeitá-las às vezes. Nós geramos estes internamente com o nosso processo de compilação do servidor (PXEboot). Nunca nos aconteceu, mas sabemos que podemos fazer isso.

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

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

    

Answer 3

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

Eu percebi 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 eles foram pesquisados. Se fossem eles devem enviar um e-mail ou algo que eles estão online e enviar pacotes vivos por um período de tempo para que eu possa 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 ...

    

Answer 4

Atualizar 2018

Não tenho certeza do que tudo mudou desde 2012. Só queria dar uma atualização sobre minha experiência em 2018. Nós implantamos uma rede openvpn muito semelhante à configuração do OP. Nossos endpoints são PCs linux completos em vez de dispositivos embarcados. Cada endpoint tem um monitor usado para exibir informações e alarmes para esse site e nosso servidor nos permite um único ponto remoto para todos os endpoints. A rede não é excessivamente ativa, mas às vezes tem 5-10 sessões remotas simultaneamente.

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

Não estamos em uma escala grande o suficiente para dizer isso com significativa confiança, mas eu só queria dar uma atualização recente desde que originalmente implantando nossa rede eu encontrei isso e estava esperando muito mais uso de recursos nessa escala. Agora, eu acredito que a cpu que executa isso tem criptografia de hardware e eu não tenho certeza em que ponto isso seria sobrecarregado de tráfego, mas para endpoints que não se comunicam muito isso não deve ser um problema.

Em 1000000 você precisaria de 200gb de ram em uma única máquina (se escalado linearmente com extra) enquanto isso é possível Eu pensaria que nesse ponto você gostaria de ter 5 máquinas cada com 64gb de ram, então você não tem 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 são provavelmente excessivas, pois estou dividindo todo o uso do openvpn pelo número de clientes, onde apenas uma parte desse RAM é devida aos clientes.

Adicionamos 74 endpoints em um ano desde o início da implantação. Espero continuar a aumentar significativamente esse número e farei uma atualização adicional se chegarmos a uma escala decente.