OpenVPN-Leistung: Wie viele Clients sind gleichzeitig möglich?

Ich evaluiere ein System für einen Client, bei dem viele OpenVPN-Clients eine Verbindung zu einem OpenVPN-Server herstellen. "Viele" bedeutet 50000 - 1000000.

Warum mache ich das? Die Clients sind verteilte Embedded-Systeme, die sich jeweils hinter dem DSL-Router des Systembesitzers befinden. Der Server muss Befehle an die Clients senden können. Mein erster naiver Ansatz besteht darin, die Clients über ein OpenVPN-Netzwerk mit dem Server zu verbinden. Auf diese Weise kann der sichere Kommunikationstunnel in beide Richtungen verwendet werden.

Dies bedeutet, dass alle Clients immer mit dem Server verbunden sind. Im Laufe der Jahre haben sich viele Kunden gemeldet.

Die Frage ist: explodiert der OpenVPN-Server, wenn eine bestimmte Anzahl von Clients erreicht wird? Mir ist bereits eine maximale TCP-Verbindungsanzahl bekannt, daher müsste (und aus anderen Gründen) das VPN den UDP-Transport verwenden.

OpenVPN-Gurus, was ist Ihre Meinung?

Ich bezweifle, dass ein so umfangreiches Setup jemals zuvor versucht wurde, sodass Sie beim Versuch wahrscheinlich die Grenzen überschreiten werden. Ich konnte einen Artikel über eine VPN-Bereitstellung für 400 Clients finden, aber dem Text nach zu urteilen, stützte sich der Autor nur auf grobe Schätzungen darüber, wie viele Clients pro CPU ausgeführt werden könnten, und es fehlte ein gewisses Verständnis über die Leistung seines Setups.

Sie müssten hauptsächlich diese beiden Punkte berücksichtigen:

1. Die Bandbreite, die Ihre Datenübertragungen benötigen, muss auf der VPN-Serverseite ver- und entschlüsselt werden, was CPU-Ressourcen beansprucht

2. OpenVPN-Clientverbindungen belegen sowohl Speicher- als auch CPU-Ressourcen auf dem Server, auch wenn keine Daten übertragen werden

Gute PC-Hardware, die heutzutage verfügbar ist, sollte eine Gigabit-Verbindung mit Blowfish oder AES-128 problemlos auslasten. Selbst 100 US-Dollar teure Embedded-Geräte können Datenraten von nahezu 100 Mbit / s erreichen , sodass CPU-Engpässe aufgrund der Bandbreitenintensität keine Rolle spielen sollten.

Bei einem Standardintervall von 3600 Sekunden würde eine Anzahl von 1.000.000 Clients bedeuten, dass der Server durchschnittlich 278 Schlüsselaustauschvorgänge pro Sekunde ausführen muss. Während ein Schlüsselaustausch eine recht CPU-intensive Aufgabe ist, können Sie ihn bei Bedarf auf dedizierte Hardware auslagern. Die verfügbaren kryptografischen Beschleunigerkarten können diese Anzahl von TLS-Handshakes problemlos erfüllen und übertreffen. Und Speicherbeschränkungen sollten nicht zu sehr stören - eine 64-Bit-Binärdatei sollte sich um alle Einschränkungen des virtuellen Speichers kümmern, auf die Sie sonst wahrscheinlich stoßen würden.

Das Schöne an OpenVPN ist jedoch, dass Sie es ganz einfach skalieren können. Richten Sie einfach eine beliebige Anzahl von OpenVPN-Servern ein und stellen Sie sicher, dass Ihre Clients sie verwenden (z. B. über DNS Round-Robin). Konfigurieren Sie ein dynamisches Routing-Protokoll Ihrer Wahl (In der Regel ist dies aufgrund seiner Einfachheit RIP.) Ihre Infrastruktur kann eine beliebige Anzahl von Clients unterstützen, sofern Sie über genügend Hardware verfügen.

Ich habe das tatsächlich gemacht, allerdings mit "nur" ein paar hundert Fernverbindungen ähnlich hinter DSL-Routern. Ich kann nicht allzu viel über die Probleme mit der Neuverschlüsselung sagen, aber ein paar praktische Dinge, die ich dabei gelernt habe:

1) Wenn Sie Clients bereitstellen, müssen Sie mehrere VPN-Server in der Clientkonfiguration angeben, vpn1.example.com, vpn2.example.com, vpn3 ..... Auch wenn Sie jetzt nur einen oder zwei davon angeben, geben Sie an selbst Kopffreiheit. Richtig konfiguriert, wiederholen die Clients die Versuche nach dem Zufallsprinzip, bis sie eines finden, das funktioniert.

2) Wir verwenden ein benutzerdefiniertes AWS-VPN-Server-Image und können bei Bedarf zusätzliche Kapazität aufbauen. Amazon DNS (R53) kümmert sich um die DNS-Seite. Es ist vollständig vom Rest unserer Infrastruktur getrennt.

3) Verwenden Sie am Ende des Servers die Netzmaske, um die Anzahl der potenziellen Clients zu begrenzen. Das sollte Clients auf einen alternativen Server zwingen und die CPU-Probleme mindern. Ich denke, wir beschränken unsere Server auf ungefähr 300 Clients. Diese Wahl war für uns etwas willkürlich - "Bauchgefühl", wenn Sie möchten.

4) Auch auf der Serverseite sollten Sie vorsichtig mit Firewalls umgehen. In einfachen Worten, wir haben unsere so konfiguriert, dass die Clients eine VPN-Verbindung herstellen können, aber die Server verbieten strengstens alle eingehenden SSH-Verbindungen mit Ausnahme einer bekannten IP-Adresse. Wir können den Kunden SSH zur Verfügung stellen, wenn wir dies gelegentlich benötigen. Sie können uns kein SSH zur Verfügung stellen.

5) Verlassen Sie sich nicht darauf, dass OpenVPN die Wiederherstellung der Verbindung für Sie auf Client-Seite durchführt. 9 mal von 10 wird es, aber manchmal bleibt es stecken. Haben Sie einen separaten Prozess zum Zurücksetzen / Neustarten von openVPN auf dem Client-Ende regelmäßig.

6) Sie benötigen eine Möglichkeit, eindeutige Schlüssel für die Clients zu generieren, damit Sie sie manchmal deaktivieren können. Diese generieren wir intern mit unserem Server Build (PXEboot) -Prozess. Ist uns noch nie passiert, aber wir wissen, dass wir es schaffen können.

7) Sie benötigen einige Verwaltungstools und Skripts, um Ihre VPN-Serververbindungen effektiv zu überwachen.

Es gibt leider nicht viel Material darüber, wie man das macht, aber es ist mit vorsichtiger Konfiguration möglich.

Update 2018

Ich bin mir nicht sicher, was sich seit 2012 alles geändert hat. Ich wollte nur ein Update über meine Erfahrungen im Jahr 2018 geben. Wir haben ein OpenVPN-Netzwerk bereitgestellt, das dem OP-Setup sehr ähnlich ist. Unsere Endpunkte sind vollwertige Linux-PCs anstelle von eingebetteten Geräten. Jeder Endpunkt verfügt über einen Monitor, auf dem Informationen und Alarme für diesen Standort angezeigt werden. Unser Server ermöglicht es uns, einen einzelnen Punkt an alle Endpunkte zu übertragen. Das Netzwerk ist nicht übermäßig aktiv, hat jedoch manchmal 5-10 Remote-Sitzungen gleichzeitig.

Bei einer aktuellen OpenVPN-Version von rund 100 Clients auf einem Azure-Image mit einem einzelnen Kern und 2 GB RAM-Speicher belegen wir durchschnittlich rund 0,7% des Arbeitsspeichers und die CPU-Auslastung liegt fast immer bei rund 0%. Basierend auf dem, was ich für diesen kleineren Test gefunden habe, denke ich, dass ein einzelner Server mit anständigen Spezifikationen problemlos 50000 gleichzeitig handhaben würde, wenn er den RAM hätte, der ihn unterstützt. Wenn die RAM-Nutzung linear skaliert würde, könnten 16 GB 50000 Benutzer mit genügend zusätzlichen Ressourcen auf einem dedizierten OpenVPN-Computer verwalten.

Wir sind nicht groß genug, um dies mit größerem Vertrauen zu sagen, aber ich wollte nur ein aktuelles Update veröffentlichen, da ich dies bei der ursprünglichen Bereitstellung unseres Netzwerks festgestellt habe und mit einem deutlich höheren Ressourcenverbrauch in dieser Größenordnung gerechnet habe. Nun glaube ich, dass die CPU, auf der dies ausgeführt wird, eine Hardwareverschlüsselung aufweist, und ich bin nicht sicher, an welchem ​​Punkt der Datenverkehr überlastet wäre, aber für Endpunkte, die nicht viel kommunizieren, sollte dies kein Problem sein.

Bei 1000000 würden Sie 200 GB RAM auf einer einzelnen Maschine benötigen (wenn linear mit zusätzlichen skaliert), während dies möglich ist. Ich würde denken, an diesem Punkt würden Sie 5 Maschinen mit jeweils 64 GB RAM haben wollen, damit Sie keinen einzigen Punkt haben des Scheiterns. Dies sollte die Wartung, den Neustart und den Austausch von 1 oder 2 Maschinen ohne nennenswerte Probleme ermöglichen.

Meine RAM-Schätzungen sind wahrscheinlich viel zu hoch, da ich die gesamte OpenVPN-Nutzung durch die Anzahl der Clients teile, von denen nur ein Teil auf Clients entfällt.

Seit der ersten Bereitstellung haben wir in einem Jahr 74 Endpunkte hinzugefügt. Ich hoffe, dass wir diese Zahl weiterhin erheblich steigern und ein weiteres Update vornehmen können, wenn wir zu einem anständigen Maßstab gelangen.

Ich untersuche ein ähnliches Problem, obwohl die Anzahl der Kunden Hunderte, vielleicht ein paar Tausend betragen würde.

Ich stellte fest, dass ich nicht immer alle Clients in Verbindung halten kann.

Ich denke daran, OpenVPN-Daemon auf Clients in zufälligen Zeitintervallen zu starten, damit sie überprüfen können, ob sie abgefragt wurden. Wenn sie eine E-Mail senden oder etwas, das sie online sind, und Keep-Alive-Pakete senden, damit ich mich mit ihnen verbinden kann.

Wenn für einige Zeit kein Datenverkehr besteht, wird der Dämon gestoppt.

Das Problem, mit dem ich gerade konfrontiert bin, ist, dass es unmöglich zu sein scheint, eine Liste der aktuell verbundenen VPN-Clients abzurufen ...