Performance OpenVPN: combien de clients simultanés sont possibles?


37

J'évalue un système pour un client où de nombreux clients OpenVPN se connectent à un serveur OpenVPN. "Plusieurs" signifie 50000 - 1000000.

pourquoi est ce que je fais ça? Les clients sont des systèmes intégrés distribués, chacun 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 à amener les clients à se connecter 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. Il y a beaucoup de clients qui résument au fil des ans.

La question qui se pose est la suivante: le serveur OpenVPN explose-t-il lorsqu'il atteint un certain nombre de clients? Je suis déjà au courant d'un nombre maximal de connexions TCP. Par conséquent (et pour d'autres raisons), le VPN devrait utiliser le transport UDP.

OpenVPN gourous, quelle est votre opinion?


Pourriez-vous partager vos conclusions finales à ce sujet avec nous? Avez-vous pu faire des tests avec plus de 5 000 utilisateurs?
Philipp

Bonjour Philipp, nous avons abandonné le plan OpenVPN car il était clair que nous allions toucher un terrain que personne n’avait jamais touché auparavant. Nous avons opté pour une connexion TCP Socket normale basée sur SSL à un serveur de gestion de connexions Node.js.
Steffen Müller,

Réponses:


25

Je doute qu'une configuration aussi importante ait déjà été tentée, vous allez donc probablement repousser les limites lorsque vous essayez. Je pouvais trouver un article sur un déploiement VPN pour 400 clients mais, à en juger par le texte, l'auteur ne s'est fondé que sur des estimations approximatives du nombre de clients pouvant être exécutés par processeur et manquait de connaissances sur les performances de sa configuration.

Vous devez principalement prendre en compte ces deux points:

  1. La bande passante que vos transferts de données vont utiliser nécessiterait un chiffrement / déchiffrement côté serveur VPN, consommant des ressources de la CPU

  2. Les connexions client OpenVPN consomment à la fois de la mémoire et des ressources de la CPU sur le serveur même lorsqu'aucune donnée n'est transférée.

Tout matériel informatique décent disponible aujourd'hui devrait facilement saturer une liaison Gigabit avec Blowfish ou AES-128, même les périphériques embarqués à 100 $ sont capables d'atteindre des débits proches de 100 Mbps .

Compte tenu de l'intervalle de modification des clés par défaut de 3 600 secondes, un nombre de clients égal à 1 000 signifierait que le serveur devrait pouvoir effectuer 278 échanges de clés par seconde en moyenne. Bien que l'échange de clés soit une tâche plutôt gourmande en ressources processeur, vous pouvez le transférer sur du matériel dédié si nécessaire. Les cartes accélératrices cryptographiques disponibles rencontrent et dépassent facilement ce nombre de poignée de main 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 risqueriez de toucher autrement.

Mais la vraie beauté avec OpenVPN est que vous pouvez facilement l’évoluer - 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. (En règle générale, il s'agirait de RIP en raison de sa simplicité) et votre infrastructure serait capable de prendre en charge un nombre arbitraire de clients tant que vous avez suffisamment de matériel.


Merci pour la réponse concise. Voyez-vous des alternatives à openvpn? L'objectif principal est simplement de faire passer la communication bidirectionnelle via le routeur.
Steffen Müller

2
@ SteffenMüller Si vous n'avez pas besoin d'une pile complète mais seulement d'un canal de contrôle, pourquoi ne pas utiliser quelque chose de similaire aux réseaux de zombies ? Des implémentations sont disponibles et le SANS propose un document expliquant comment les configurer
the-wabbit

Merci pour le lien intéressant. Malheureusement, le bot utilise une simple interrogation pour savoir si le serveur a des informations. Bien que cela puisse être la voie à suivre, je cherche un moyen d'établir et de conserver une connexion bidirectionnelle. L'interrogation constante provoque des retards dans l'exécution de la commande ou un volume de données élevé pour les demandes d'interrogation inutiles. Peut-être une connexion TCP permanente est la voie à suivre?
Steffen Müller

1
@ SteffenMüller Il a été prouvé que les réseaux de zombies gèrent bien des milliers de clients - c’est ce que j’ai suggéré de faire. Vous n'êtes pas obligé de suivre la mise en œuvre spécifique suggérée par SANS - il y en a vraiment beaucoup d'autres. Autre que cela, sans connaître vos exigences exactes, il est vraiment difficile de dire. Une connexion TCP envoyant des keepalives serait sûrement capable de s’assurer que la relation d’état au niveau de la passerelle NAT ne vieillit pas. Mais vous devez vous occuper de tout le reste (authentification, cryptage, traitement des erreurs) tout seul.
le-wabbit

2
En passant, il n’ya aucune raison pour que vous ne puissiez pas réduire l’intervalle de ré-saisie (il existe un compromis de sécurité, dans la mesure où une clé compromise remettra le texte en clair au dernier ré-saisie). En outre, je serais beaucoup plus préoccupé par l' échec de l' acheminement ou d'une autre recherche de connexion. Je veux dire, si OpenVPN doit avoir <100 connexions actives, quelle est la probabilité qu'il y ait une recherche O (n) d'une connexion quelque part?
derobert

26

C'est ce que j'ai fait, bien qu'avec "seulement" quelques centaines de connexions distantes de la même manière derrière des routeurs DSL. Je ne peux pas trop en dire sur les problèmes de changement de code, 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 du client, vpn1.example.com, vpn2.example.com, vpn3 ..... Même si vous ne fournissez qu’un ou deux d’entre eux, vous vous-même Configurés correctement, les clients continueront à les réessayer de manière aléatoire 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é de traitement à la demande. Amazon DNS (R53) gère le côté DNS de vos tâches. Il est complètement détaché du reste de notre infrastructure.

3) À la fin du ou des serveurs, 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 processeur. Je pense que nous limitons nos serveurs à environ 300 clients. Ce choix était quelque peu arbitraire de notre part - "Gut Feel" si vous voulez.

4) Également du côté du serveur, vous devez utiliser les pare-feu avec précaution. En termes simples, notre configuration est telle que les clients peuvent se connecter au VPN, mais les serveurs interdisent formellement toutes les connexions SSH entrantes, sauf à partir d'une adresse IP connue. Nous pouvons SSH pour les clients si nous en avons parfois besoin, ils ne peuvent pas SSH pour nous.

5) Ne vous fiez pas à OpenVPN pour vous reconnecter chez le client. 9 fois sur 10, ça va, mais parfois ça reste bloqué. Utilisez un processus distinct pour réinitialiser / redémarrer openVPN chez le 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 les désavouer de temps en temps. Nous les générons en interne avec notre processus de génération 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’ya pas beaucoup de matériel sur la façon de procéder mais c’est possible, avec une configuration soignée.


Merci beaucoup pour vos idées. Je suis surpris que les problèmes de ré-saisie vous frappent déjà avec 300 clients ...
Steffen Müller

Pour clarifier - ils ne l’ont pas fait, mais je ne l’ai pas suivi non plus ....: - / Le nombre "300" semblait juste raisonnable. Si nous avons des problèmes, nous allons simplement transformer l'image AWS en une instance plus grande. Je n'avais jamais eu autant de connexions sur un serveur auparavant, probablement environ 100 max maximum, mais nous en exploitons plusieurs et ils s'équilibrent approximativement avec openvpn en choisissant au hasard une destination dans une liste connue.
Aitch

Pourriez-vous nous donner plus de détails sur la manière de procéder: "5) Ne comptez pas sur OpenVPN pour vous reconnecter chez le client. 9 fois sur 10, il y aura parfois un blocage. Créez un processus distinct pour réinitialiser / redémarrer openVPN à la fin du client régulièrement. "
Doug

Désolé d'avoir quitté cet emploi il y a 4,5 ans (!), Je ne m'en souviens pas, mais il est presque certain qu'une sorte de liste de processus supprime, puis élimine le redémarrage du service.
Aitch

(Je fais une configuration similaire avec actuellement environ 400 périphériques sur un serveur VPN), vous devez décider quoi faire lorsque vpn ne peut pas être atteint, que le délai d’expiration est dépassé ou qu’il est rejeté. l'intervalle de relance aléatoire ne vous aidera pas pour toujours et ne générera que du trafic. En fonction du problème, vous devez soit faire quelque chose sur le client, sur un pare-feu / DSL, ce que vous ne pouvez généralement pas, et ainsi envoyer le système dans une phase de veille "meh, transférer les données plus tard", ou s'il s'agit du serveur VPN lui-même. . Vous pouvez estimer cela grâce aux journaux et décider en fonction de cela. rekeke n'est pas (encore) un problème pour nous.
Dennis Nolte

3

Mise à jour 2018

Je ne sais pas ce qui a tout changé depuis 2012. Je voulais juste faire le point sur mon expérience de 2018. Nous avons déployé un réseau openvpn très similaire à la configuration de l'OP. Nos ordinateurs d'extrémité sont des ordinateurs Linux complets au lieu d'appareils intégrés. Chaque terminal dispose d'un moniteur utilisé pour afficher des informations et des alarmes pour ce site. Notre serveur nous permet ainsi de centraliser à distance tous les terminaux. Le réseau n'est pas trop actif, mais compte parfois 5 à 10 sessions à distance simultanément.

En utilisant une version actuelle d’OpenVPN représentant environ 100 clients sur une image azur 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 autour de 0%. Sur la base de ce que j'ai trouvé pour ce test plus petit, je pense qu'un serveur unique avec des spécifications correctes pourrait facilement gérer 50000 concurrents s'il avait le ram pour le prendre en charge. Si l'utilisation de la mémoire RAM était mise à l'échelle de façon linéaire, 16 Go seraient en mesure de gérer 50000 utilisateurs avec suffisamment de ressources supplémentaires sur une machine openvpn dédiée.

Nous ne sommes pas à une échelle suffisante pour affirmer cela avec une confiance significative, mais je souhaitais simplement faire une mise à jour récente car, lors du déploiement initial de notre réseau, je l'ai constaté et je m'attendais à une utilisation beaucoup plus importante des ressources à cette échelle. Maintenant, je pense que le processeur qui le gère a un cryptage matériel et je ne sais pas à quel point cela pourrait entraîner une surcharge du trafic, mais cela ne devrait pas poser de problème pour les ordinateurs d'extrémité qui ne communiquent pas beaucoup.

À 1000000, vous auriez besoin de 200 Go de RAM sur une seule machine (si elle est mise à l'échelle de manière linéaire avec un extra), ce qui est possible. Je pense qu'à ce stade, vous voudriez avoir 5 machines chacune avec 64 Go de RAM, de sorte que vous n'ayez pas un seul point. d'échec. Cela devrait permettre la maintenance, les redémarrages et les remplacements d'une ou même de deux machines sans problème significatif.

Mes estimations de bélier sont probablement exagérées, car je divise l’utilisation entière de openvpn par le nombre de clients, seule une partie de ce bélier étant due aux clients.

Nous avons ajouté 74 terminaux en un an depuis le déploiement initial. J'espère continuer à augmenter considérablement ce nombre et ferai une autre mise à jour si nous atteignons une échelle décente.


Pouvez-vous nous donner plus de détails sur la façon dont vous faites cela: "5) Ne comptez pas dessus, cela ne me permettra pas de commenter le sujet ci-dessus, mais je voulais répondre à cela: OpenVPN fait la reconnexion pour vous chez le client. 9 fois sur 10, cela risque de rester bloqué. Créez un processus distinct pour réinitialiser / redémarrer openVPN chez le client régulièrement. " - Doug 18 mai
17h à 17h12

Hit une limite de personnage. Utilisez supervisord pour le faire. Faites-le redémarrer automatiquement toutes les 6-12h
CraigZ

1

Je suis en train d'examiner un problème similaire, même si le nombre de clients se compte en centaines, voire quelques milliers.

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

Je songe à démarrer le démon OpenVPN sur les clients à intervalles aléatoires pour qu'ils puissent vérifier s'ils ont été interrogés. S'ils le sont, ils doivent envoyer un courrier électronique ou quelque chose qu'ils sont en ligne et envoyer des paquets non conservés 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 sera arrêté.

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


1
Vous pouvez obtenir une liste actuelle des clients connectés via le journal d'état openvpn. Là vous voyez tous les ips connectés au serveur actuel.
Fa11enAngel
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.