Performances OpenVPN: combien de clients simultanés sont possibles?
J'évalue un système pour un client où de nombreux clients OpenVPN se connectent à un serveur OpenVPN. "Beaucoup" signifie 50000 - 1000000.
Pourquoi est ce que je fais ça? Les clients sont des systèmes intégrés distribués, chacun assis derrière le routeur dsl du propriétaire du système. Le serveur doit pouvoir envoyer des commandes aux clients. Ma première approche naïve consiste à faire se connecter les clients au serveur via un réseau openvpn. De cette façon, le tunnel de communication sécurisé peut être utilisé dans les deux sens.
Cela signifie que tous les clients sont toujours connectés au serveur. De nombreux clients résument au fil des ans.
La question est: le serveur OpenVPN explose-t-il en atteignant un certain nombre de clients? Je suis déjà au courant d'une limite maximale de nombre de connexions TCP, par conséquent (et pour d'autres raisons), le VPN devrait utiliser le transport UDP.
Gourous d'OpenVPN, quelle est votre opinion?
Je doute qu'une configuration aussi importante ait déjà été tentée auparavant, vous devrez donc probablement repousser les limites lors de la tentative. Je pourrais trouver un article sur un déploiement VPN pour 400 clients mais à en juger par le texte, l'auteur s'est contenté d'estimations approximatives sur le nombre de clients pouvant être exécutés par CPU et manquait de compréhension sur la façon dont sa configuration serait effectuer.
Vous devrez principalement considérer ces deux points:
La bande passante que vos transferts de données vont utiliser nécessiterait un chiffrement/déchiffrement côté serveur VPN, consommant des ressources CPU
Les connexions client OpenVPN consomment à la fois des ressources mémoire et CPU sur le serveur même lorsqu'aucune donnée n'est transférée
Tout matériel PC décent disponible aujourd'hui devrait facilement saturer une liaison Gigabit avec Blowfish ou AES-128, même les appareils embarqués à 100 $ sont capables de débits proches de 100 Mbps , donc les goulots d'étranglement CPU dus à l'intensité de la bande passante ne devraient pas être de tout préoccupation.
Compte tenu de l'intervalle de recomposition par défaut de 3 600 secondes, un nombre de 1 000 000 de clients signifierait que le serveur devrait être en mesure d'effectuer en moyenne 278 échanges de clés par seconde. Bien qu'un échange de clés soit une tâche plutôt gourmande en ressources processeur, vous pouvez le décharger sur du matériel dédié si nécessaire - les cartes accélératrices cryptographiques disponibles atteignent et dépassent facilement ce nombre de prises de contact TLS. Et les restrictions de mémoire ne devraient pas trop déranger - un binaire 64 bits devrait prendre en charge toutes les restrictions de mémoire virtuelle que vous risquez de rencontrer autrement.
Mais la vraie beauté avec OpenVPN est que vous pouvez le faire évoluer assez facilement - configurez simplement un nombre arbitraire de serveurs OpenVPN et assurez-vous que vos clients les utilisent (par exemple via DNS round-robin), configurez un protocole de routage dynamique de votre choix (il s'agit généralement de RIP en raison de sa simplicité) et votre infrastructure serait capable de prendre en charge un nombre arbitraire de clients tant que vous disposez de suffisamment de matériel.
J'ai effectivement fait cela, mais avec "seulement" quelques centaines de connexions distantes de même derrière les routeurs DSL. Je ne peux pas trop commenter les problèmes de recomposition, mais quelques choses pratiques que j'ai apprises en cours de route:
1) Lors du déploiement de clients, assurez-vous de spécifier plusieurs serveurs VPN dans la configuration client, vpn1.example.com, vpn2.example.com, vpn3 ..... Même si vous n'en fournissez qu'un ou deux maintenant, vous donnez vous headroom. Configurés correctement, les clients continueront de les réessayer au hasard jusqu'à ce qu'ils en trouvent un qui fonctionne.
2) Nous utilisons une image de serveur AWS VPN personnalisée et pouvons augmenter la capacité supplémentaire à la demande, et Amazon DNS (R53) gère le côté DNS des choses. Il est complètement détaché du reste de notre infrastructure.
3) Du côté serveur (s), utilisez soigneusement le masque de réseau pour limiter le nombre de clients potentiels. Cela devrait forcer les clients sur un autre serveur, atténuant ainsi les problèmes de CPU. Je pense que nous limitons nos serveurs à environ 300 clients. Ce choix était quelque peu arbitraire de notre part - "intuition" si vous voulez.
4) Toujours du côté du serveur, vous devez faire attention aux pare-feu. En termes simples, nous avons le nôtre configuré de telle sorte que les clients puissent se connecter VPN, mais les serveurs interdisent strictement toutes les connexions ssh entrantes, sauf à partir d'une adresse IP connue. Nous pouvons SSH pour les clients si nous en avons besoin, ils ne peuvent pas SSH pour nous.
5) Ne comptez pas sur OpenVPN pour vous reconnecter du côté client. 9 fois sur 10, mais parfois il se coince. Avoir un processus distinct pour réinitialiser/redémarrer openVPN du côté client régulièrement.
6) Vous avez besoin d'un moyen de générer des clés uniques pour les clients afin de pouvoir parfois les désavouer. Nous les générons 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 et de scripts pour surveiller efficacement les connexions de votre serveur VPN.
Malheureusement, il n'y a pas beaucoup d'informations sur la façon de procéder, mais c'est possible, avec une configuration soignée.
Mise à jour 2018
Je ne sais pas ce qui a changé depuis 2012. Je voulais juste faire le point sur 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 ordinateurs Linux complets à la place des appareils intégrés. Chaque point de terminaison a un moniteur utilisé pour afficher des informations et des alarmes pour ce site et notre serveur nous permet un point unique à distance dans tous les points de terminaison. Le réseau n'est pas trop actif mais a parfois 5 à 10 sessions distantes simultanément.
En utilisant une version actuelle d'openvpn sur environ 100 clients sur une image Azure avec un seul cœur et 2 Go de RAM, nous utilisons environ 0,7% de mémoire en moyenne et l'utilisation du processeur est presque toujours de 0%. Sur la base de ce que j'ai trouvé pour ce test plus petit, je pense qu'un seul serveur avec des spécifications décentes gérerait facilement 50000 simultanément s'il avait le ram pour le prendre en charge. Si l'utilisation du ram était mise à l'échelle de manière linéaire, 16 Go seraient capables de gérer 50000 utilisateurs avec suffisamment de ressources supplémentaires sur une machine openvpn dédiée.
Nous ne sommes pas à une échelle suffisamment grande pour dire cela avec une confiance significative, mais je voulais juste donner une mise à jour récente car lors du déploiement initial de notre réseau, j'ai trouvé cela et je m'attendais à beaucoup plus d'utilisation des ressources à cette échelle. Maintenant, je crois que le processeur qui exécute cela a un chiffrement matériel et je ne sais pas à quel point cela serait surchargé en termes de trafic, mais pour les points de terminaison qui ne communiquent pas beaucoup, cela ne devrait pas être un problème.
À 1000000, vous auriez besoin de 200 Go de RAM sur une seule machine (si elle est mise à l'échelle linéairement avec un supplément) alors que cela est possible, je pense qu'à ce stade, vous voudriez avoir 5 machines chacune avec 64 Go de RAM afin que vous n'ayez pas un seul point d'échec. Cela devrait permettre la maintenance, le redémarrage et le remplacement de 1 ou même 2 machines sans problèmes importants.
Mes estimations de RAM sont probablement excessives car je divise l'utilisation entière d'Openvpn par le nombre de clients, où seule une partie de ce 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 ce nombre de manière significative et je ferai une nouvelle mise à jour si nous atteignons une échelle décente.
J'examine un problème similaire, bien que le nombre de clients se chiffre en centaines, voire en milliers.
J'ai pensé que je ne pouvais pas garder tous les clients connectés tout le temps.
Je pense à démarrer le démon OpenVPN sur des clients à des intervalles de temps aléatoires afin qu'ils puissent vérifier s'ils ont été interrogés. S'ils l'étaient, ils doivent envoyer un e-mail ou quelque chose qu'ils sont en ligne et envoyer des paquets Keep Alive pendant un certain temps afin 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 actuellement connectés ...