Performance OpenVPN: combien de clients concurrents sont possibles?

J'ai en fait fait cela, même avec "seulement" quelques centaines de connexions à distance derrière des routeurs DSL. Je ne peux pas trop commenter les problèmes de rekeying, mais j'ai appris quelques choses pratiques en chemin :

1) Lors du déploiement des clients, assurez-vous de spécifier plusieurs serveurs VPN dans le fichier de configuration du client, vpn1.example.com, vpn2.example.com, vpn3... Même si vous n'en fournissez qu'un ou deux maintenant, vous vous donnez de la marge de manoeuvre. Configurés correctement, les clients continueront à les réessayer au hasard jusqu'à ce qu'ils en trouvent un qui fonctionne.

2) Nous utilisons une image de serveur VPN AWS personnalisée et pouvons augmenter la capacité supplémentaire à la demande, et Amazon DNS (R53) gère la partie DNS. Il est complètement détaché du reste de notre infrastructure.

3) À l'extrémité du(des) serveur(s), utilisez soigneusement le masque réseau pour limiter le nombre de clients potentiels. Cela devrait forcer les clients à utiliser un serveur alternatif, atténuant les problèmes de CPU. Je pense que nous limitons nos serveurs à environ 300 clients. Ce choix était quelque peu arbitraire de notre part - une intuition, si vous préférez.

4) Également à l'extrémité du serveur, utilisez soigneusement les pare-feu. En termes simples, nous avons configuré le nôtre de telle sorte que les clients puissent se connecter en VPN, mais que les serveurs interdisent strictement toutes les connexions entrantes SSH sauf d'une adresse IP connue. Nous pouvons nous connecter en SSH aux clients si nous en avons occasionnellement besoin, mais ils ne peuvent pas se connecter en SSH à nous.

5) Ne comptez pas sur OpenVPN pour reconnecter automatiquement le client. 9 fois sur 10, il le fera, mais parfois il reste bloqué. Ayez un processus séparé pour réinitialiser/redémarrer OpenVPN régulièrement au niveau du client.

6) Vous avez besoin d'un moyen de générer des clés uniques pour les clients pour pouvoir les désavouer parfois. Nous générons celles-ci en interne avec notre processus de construction de serveur (PXEboot). Cela ne nous est jamais arrivé, mais nous savons que nous pouvons le faire.

7) Vous aurez besoin d'outils de gestion, de scripts pour surveiller efficacement les connexions de votre serveur VPN.

Il n'y a malheureusement pas beaucoup de ressources sur la manière de faire cela, mais c'est possible avec une configuration soignée.

Mise à jour 2018

Je ne suis pas sûr de tout ce qui a changé depuis 2012. Je voulais juste donner une mise à jour de mon expérience en 2018. Nous avons déployé un réseau openvpn très similaire à la configuration OP. Nos points de terminaison sont des PC linux complets au lieu de périphériques intégrés. Chaque point de terminaison dispose d'un moniteur utilisé pour afficher des informations et des alarmes pour ce site, et notre serveur nous permet de nous connecter à distance à tous les points de terminaison à partir d'un point unique. Le réseau n'est pas très actif mais il arrive parfois qu'il y ait 5 à 10 sessions à distance simultanément.

Avec une version actuelle d'openvpn et environ 100 clients sur une image azure avec un seul cœur et 2 Go de RAM, nous utilisons en moyenne environ 0,7 % de mémoire et l'utilisation du processeur est presque toujours autour de 0 %. Basé sur ce que j'ai trouvé pour ce petit test, je suppose qu'un seul serveur avec des spécifications décentes pourrait facilement gérer 50000 connexions simultanées s'il avait la RAM nécessaire pour le supporter. Si l'utilisation de la RAM est linéaire, alors 16 Go pourrait gérer 50000 utilisateurs avec suffisamment de capacité supplémentaire sur une machine openvpn dédiée.

Nous ne sommes pas à une échelle suffisamment grande pour affirmer cela avec une grande confiance, mais je voulais juste donner une mise à jour récente puisque lorsque nous avons déployé notre réseau à l'origine, j'ai trouvé cela et je m'attendais à une consommation de ressources beaucoup plus élevée à cette échelle. Maintenant, je crois que le processeur qui exécute ceci possède un chiffrement matériel et je ne sais pas à quel moment cela serait saturé en termes de trafic, mais pour les points de terminaison qui ne communiquent pas beaucoup, cela ne devrait pas poser de problème.

Avec 1000000, vous auriez besoin de 200 Go de RAM sur une seule machine (si l'échelle est linéaire avec du supplément), bien que cela soit possible, je pense qu'à ce stade, vous voudriez avoir 5 machines chacune avec 64 Go de RAM pour éviter un point de défaillance unique. Cela devrait permettre la maintenance, les redémarrages et le remplacement de 1 ou même 2 machines sans problèmes significatifs. Mes estimations de RAM sont probablement très exagérées car je divise la totalité de l'utilisation d'openvpn par le nombre de clients alors qu'une partie seulement de cette RAM est due aux clients.

Nous avons ajouté 74 points de terminaison en un an depuis le déploiement initial. J'espère continuer à augmenter significativement ce nombre et je ferai une nouvelle mise à jour si nous atteignons une échelle décente.

Je me penche sur un problème similaire, bien que le nombre de clients serait de l'ordre de centaines, voire de quelques milliers.

J'ai compris que je ne peux pas garder tous les clients connectés tout le temps.

Je pense à démarrer le démon OpenVPN sur les clients à des intervalles de temps aléatoires afin qu'ils puissent vérifier s'ils ont été interrogés. S'ils l'ont été, ils doivent envoyer un e-mail ou quelque chose pour indiquer qu'ils sont en ligne et envoyer des paquets de maintien de connexion pendant un certain temps pour que je puisse me connecter à eux.

S'il n'y a pas de trafic pendant un certain temps, le démon serait arrêté.

Le problème auquel je suis confronté en ce moment est qu'il semble impossible d'obtenir une liste des clients VPN connectés actuellement...