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

37

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?

Steffen Müller
quelle
Können Sie uns Ihre abschließenden Schlussfolgerungen dazu mitteilen? Konnten Sie Tests mit> 5'000 Benutzern durchführen?
Philipp
Hallo Philipp, wir haben den OpenVPN-Plan fallen gelassen, da klar war, dass wir den Boden berühren würden, den noch niemand zuvor berührt hat. Wir haben uns für eine SSL-basierte normale TCP-Socket-Verbindung zu einem Node.js-Verbindungsverwaltungsserver entschieden.
Steffen Müller

Antworten:

25

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.

das-wabbit
quelle
Danke für die prägnante Antwort. Sehen Sie Alternativen zur Verwendung von openvpn? Das Hauptziel ist nur, dass die bidirektionale Kommunikation über den Router erfolgt.
Steffen Müller
2
@ SteffenMüller Wenn du keinen kompletten Stack, sondern nur einen Kontrollkanal benötigst, warum nicht so etwas wie Botnets verwenden ? Implementierungen sind verfügbar und die SANS bietet praktischerweise ein
Dokument
Danke für den interessanten Link. Leider fragt der Bot mit einer einfachen Abfrage ab, ob der Server über Informationen verfügt. Obwohl dies der richtige Weg ist, suche ich nach einem Weg, um eine bidirektionale Verbindung herzustellen und aufrechtzuerhalten. Die ständige Abfrage führt entweder zu Verzögerungen bei der Befehlsausführung oder zu einem hohen Datenvolumen für unnötige Abrufanforderungen. Vielleicht ist eine permanente TCP-Verbindung der richtige Weg?
Steffen Müller
1
@ SteffenMüller Botnets können nachweislich Tausende von Kunden gut bedienen - daher mein Vorschlag, sich damit auseinanderzusetzen. Sie müssen sich nicht an die von SANS angedeutete spezifische Implementierung halten - es gibt wirklich viele andere. Davon abgesehen ist es wirklich schwer zu sagen, ohne Ihre genauen Anforderungen zu kennen. Eine TCP-Verbindung, die Keepalives sendet, kann mit Sicherheit sicherstellen, dass die Statusbeziehung am NAT-Gateway nicht abläuft. Alles andere (Authentifizierung, Verschlüsselung, Fehlerbehandlung) müssten Sie jedoch selbst erledigen.
the-wabbit
2
Übrigens, es gibt keinen Grund, warum Sie das Intervall für die Neuverschlüsselung nicht verkürzen können (es gibt einen Kompromiss bei der Sicherheit, da ein kompromittierter Schlüssel Klartext bis zur letzten Neuverschlüsselung zurückgibt). Außerdem würde ich mir viel mehr Sorgen darüber machen, ob das Routing oder die Suche nach einer anderen Verbindung zuerst fehlschlägt. Ich meine, wenn OpenVPN <100 aktive Verbindungen haben soll, wie groß ist dann die Chance, dass irgendwo ein O (n) Lookup einer Verbindung stattfindet?
Derobert
26

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.

Aitch
quelle
Vielen Dank für die Erkenntnisse. Ich bin überrascht , dass die rekeying Probleme treffen Sie bereits mit 300 Kunden ...
Steffen Müller
Zur Verdeutlichung - haben sie nicht, aber ich habe es auch nicht verfolgt ....: - / Die "300" -Nummer schien nur vernünftig. Wenn wir Probleme haben, würden wir das AWS-Image einfach auf eine größere Instanz hochfahren. Ich habe noch nie so viele Verbindungen auf einem Server gehabt, wahrscheinlich nur etwa 100, aber wir betreiben mehrere Server, die ungefähr so ​​verteilt sind, dass openvpn zufällig ein Ziel aus einer bekannten Liste auswählt.
Aitch
Können Sie weitere Details dazu mitteilen, wie Sie dies tun: "5) Verlassen Sie sich nicht darauf, dass OpenVPN die Wiederherstellung der Verbindung für Sie auf der Client-Seite durchführt. 9 von 10 Fällen wird dies der Fall sein, aber manchmal kommt es zum Stillstand setze openVPN auf dem Clientende regelmäßig zurück / starte es erneut. "
Doug
Entschuldigung, ich habe diesen Job vor 4,5 Jahren (!) Verlassen, kann mich nicht erinnern, aber mit ziemlicher Sicherheit eine Art Prozessliste, töte und starte den Dienst neu.
Aitch
(Ich mache ein ähnliches Setup mit derzeit ca. 400 Geräten auf einem VPN-Server) Sie müssen eine Entscheidung treffen, was zu tun ist, wenn VPN nicht erreichbar ist, eine Zeitüberschreitung auftritt oder abgelehnt wird. Das zufällige Wiederholungsintervall hilft Ihnen nicht für immer und generiert nur Datenverkehr. Je nach Problem müssen Sie entweder etwas auf dem Client, auf der Firewall / DSL tun, was Sie normalerweise nicht können, und daher das System in eine Ruhephase "meh, transfer data later" (meh, Daten später übertragen) schicken, oder wenn das Problem der VPN-Server selbst ist . Sie können dies anhand der Protokolle abschätzen und basierend darauf entscheiden. rekeying ist für uns (noch) kein problem.
Dennis Nolte
3

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.

CraigZ
quelle
Können Sie weitere Details dazu mitteilen, wie Sie dies tun: "5) Verlassen Sie sich nicht darauf, ich werde den obigen Thread nicht kommentieren, aber ich wollte darauf antworten: OpenVPN übernimmt die Wiederherstellung der Verbindung für Sie auf Client-Seite. 9 Mal aus 10 heraus wird es, aber manchmal bleibt es hängen. Haben Sie einen separaten Prozess, um openVPN auf dem Client-Ende regelmäßig zurückzusetzen / neu zu starten. " - Doug 18. Mai 17 um 17:12
Uhr
Erreiche ein Zeichenlimit. Verwenden Sie dazu supervisord. Lass es automatisch alle 6-12h neu starten
CraigZ
1

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 ...

Davor Dundovic
quelle
1
Sie können eine aktuelle Liste der verbundenen Clients über das OpenVPN-Statusprotokoll abrufen. Dort sehen Sie alle mit dem aktuellen Server verbundenen IPS.
Fa11enAngel