Ich evaluiere ein System für einen Client, bei dem viele OpenVPN-Clients eine Verbindung zu einem OpenVPN-Server herstellen. „Viele“ bedeutet 50000 – 1.000.000.
Warum mache ich das? Die Clients sind verteilte eingebettete Systeme, die jeweils hinter dem DSL-Router des Systembesitzers sitzen. Der Server muss in der Lage sein, Befehle an die Clients zu senden. 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. Über die Jahre summieren sich so viele Clients.
Die Frage ist:explodiert der OpenVPN-Server, wenn eine bestimmte Anzahl von Clients erreicht wird? Mir ist bereits eine Beschränkung der maximalen Anzahl von TCP-Verbindungen bekannt, daher (und aus anderen Gründen) müsste das VPN UDP-Transport verwenden.
OpenVPN-Gurus, was ist Ihre Meinung?
Antwort1
Ich bezweifle, dass ein so großes Setup jemals zuvor versucht wurde, also werden Sie wahrscheinlich an Grenzen stoßen, wenn Sie es versuchen. Ich könnte einen Artikel über einVPN-Bereitstellung für 400 ClientsAber dem Text nach zu urteilen, verließ sich der Autor lediglich auf grobe Schätzungen darüber, wie viele Clients pro CPU ausgeführt werden könnten, und es fehlte ihm an Verständnis für die Leistung seines Setups.
Dabei sind vor allem diese beiden Punkte zu beachten:
Die Bandbreite, die Ihre Datenübertragungen nutzen werden, würde eine Verschlüsselung/Entschlüsselung auf der VPN-Serverseite erfordern, was CPU-Ressourcen verbraucht
OpenVPN-Clientverbindungen verbrauchen sowohl Speicher- als auch CPU-Ressourcen auf dem Server, auch wenn keine Daten übertragen werden.
Jede heute verfügbare PC-Hardware sollte eine Gigabit-Verbindung mit Blowfish oder AES-128 problemlos auslasten, selbst eingebettete Geräte für 100 US-Dollar sindermöglicht Geschwindigkeiten von fast 100 Mbit/s, daher sollten CPU-Engpässe aufgrund der Bandbreitenintensität kein Grund zur Sorge sein.
Bei einem standardmäßigen Neuverschlüsselungsintervall von 3600 Sekunden würde eine Anzahl von 1.000.000 Clients bedeuten, dass der Server im Durchschnitt 278 Schlüsselaustausche pro Sekunde durchführen muss. Obwohl ein Schlüsselaustausch eine ziemlich CPU-intensive Aufgabe ist, können Sie ihn bei Bedarf auf dedizierte Hardware auslagern – verfügbare kryptografische Beschleunigerkarten erreichen und übertreffen diese Anzahl an TLS-Handshakes problemlos. Und auch Speicherbeschränkungen sollten nicht allzu sehr stören – eine 64-Bit-Binärdatei sollte alle virtuellen Speicherbeschränkungen beseitigen, auf die Sie sonst wahrscheinlich stoßen würden.
Das wirklich Schöne an OpenVPN ist jedoch, dass Sie es ganz einfach skalieren können: Richten Sie einfach eine beliebige Anzahl an OpenVPN-Servern ein und stellen Sie sicher, dass Ihre Clients diese verwenden (z. B. durch DNS-Round-Robin), konfigurieren Sie ein dynamisches Routing-Protokoll Ihrer Wahl (normalerweise wäre dies aufgrund seiner Einfachheit RIP) und Ihre Infrastruktur wäre in der Lage, eine beliebige Anzahl an Clients zu unterstützen, solange Sie über genügend Hardware verfügen.
Antwort2
Ich habe das tatsächlich getan, allerdings mit „nur“ ein paar hundert Remote-Verbindungen, ähnlich hinter DSL-Routern. Zu den Problemen mit der Neuverschlüsselung kann ich nicht viel sagen, aber ein paar praktische Dinge habe ich dabei gelernt:
1) Achten Sie beim Bereitstellen von Clients darauf, dass Sie in der Client-Konfiguration mehrere VPN-Server angeben, vpn1.example.com, vpn2.example.com, vpn3... Auch wenn Sie jetzt nur einen oder zwei davon angeben, verschaffen Sie sich Spielraum. Bei richtiger Konfiguration werden die Clients sie nach dem Zufallsprinzip erneut versuchen, bis sie einen finden, der funktioniert.
2) Wir verwenden ein benutzerdefiniertes AWS VPN-Server-Image und können bei Bedarf zusätzliche Kapazitäten bereitstellen. Amazon DNS (R53) kümmert sich um die DNS-Seite. Es ist vollständig vom Rest unserer Infrastruktur getrennt.
3) Gehen Sie auf der Serverseite mit der Netzmaske vorsichtig um, um die Anzahl potenzieller Clients zu begrenzen. Dadurch sollten die Clients auf einen alternativen Server umgeleitet werden, was die CPU-Probleme mildert. Ich glaube, wir beschränken unsere Server auf etwa 300 Clients. Diese Wahl war unsererseits etwas willkürlich – sozusagen „Bauchgefühl“.
4) Auch auf der Serverseite sollten Sie Firewalls mit Bedacht einsetzen. Einfach ausgedrückt haben wir unsere so konfiguriert, dass die Clients eine VPN-Verbindung herstellen können, die Server jedoch alle eingehenden SSH-Verbindungen strengstens untersagen, außer von einer bekannten IP-Adresse. Wir können bei Bedarf eine SSH-Verbindung zu den Clients herstellen, sie können jedoch keine SSH-Verbindung zu uns herstellen.
5) Verlassen Sie sich nicht darauf, dass OpenVPN die erneute Verbindung auf der Clientseite für Sie durchführt. In 9 von 10 Fällen klappt das, aber manchmal bleibt es hängen. Führen Sie einen separaten Prozess durch, um OpenVPN auf der Clientseite regelmäßig zurückzusetzen/neu zu starten.
6) Sie benötigen eine Möglichkeit, eindeutige Schlüssel für die Clients zu generieren, damit Sie diese manchmal ablehnen können. Wir generieren diese intern mit unserem Server-Build-Prozess (PXEboot). Das ist uns noch nie passiert, aber wir wissen, dass wir es schaffen können.
7) Sie benötigen einige Verwaltungstools und Skripte, um Ihre VPN-Serververbindungen effektiv zu überwachen.
Leider gibt es nicht viele Informationen hierzu, aber mit sorgfältiger Konfiguration ist es möglich.
Antwort3
Aktualisierung 2018
Ich bin mir nicht sicher, was sich seit 2012 alles geändert hat. Ich wollte nur ein Update zu meinen 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 diese Site angezeigt werden, und unser Server ermöglicht uns einen einzigen Punkt, um auf alle Endpunkte zuzugreifen. Das Netzwerk ist nicht übermäßig aktiv, hat aber manchmal 5-10 Remote-Sitzungen gleichzeitig.
Bei Verwendung eines aktuellen Builds von OpenVPN mit etwa 100 Clients auf einem Azure-Image mit einem einzelnen Kern und 2 GB RAM verwenden wir im Durchschnitt etwa 0,7 % des Speichers und die CPU-Auslastung liegt fast immer bei etwa 0 %. Basierend auf dem, was ich bei diesem kleineren Test herausgefunden habe, gehe ich davon aus, dass ein einzelner Server mit anständigen Spezifikationen problemlos 50.000 gleichzeitige Benutzer verarbeiten könnte, wenn er über den entsprechenden RAM verfügt. Wenn die RAM-Nutzung linear skaliert würde, könnten 16 GB 50.000 Benutzer verarbeiten, mit genügend Extra auf einer dedizierten OpenVPN-Maschine.
Wir sind nicht groß genug, um das mit großer Sicherheit sagen zu können, aber ich wollte nur ein aktuelles Update geben, da ich dies bei der ursprünglichen Bereitstellung unseres Netzwerks festgestellt habe und bei diesem Umfang mit einer viel höheren Ressourcennutzung gerechnet habe. Nun, ich glaube, die CPU, die dies ausführt, verfügt über Hardwareverschlüsselung und ich bin mir nicht sicher, ab wann das verkehrsmäßig überlastet wäre, aber für Endpunkte, die nicht viel kommunizieren, sollte dies kein Problem sein.
Bei 1.000.000 bräuchten Sie 200 GB RAM auf einer einzelnen Maschine (bei linearer Skalierung mit Extra). Obwohl dies möglich ist, würde ich denken, dass Sie an diesem Punkt 5 Maschinen mit jeweils 64 GB RAM haben möchten, damit Sie keinen einzelnen Ausfallpunkt haben. Dies sollte Wartung, Neustarts und Austausch von 1 oder sogar 2 Maschinen ohne größere Probleme ermöglichen.
Meine RAM-Schätzungen sind wahrscheinlich viel zu übertrieben, da ich die gesamte OpenVPN-Nutzung durch die Anzahl der Clients teile, wobei nur ein Teil des RAM auf die Clients zurückzuführen ist.
Seit der ersten Bereitstellung haben wir in einem Jahr 74 Endpunkte hinzugefügt. Ich hoffe, diese Zahl weiterhin deutlich steigern zu können, und werde ein weiteres Update veröffentlichen, wenn wir eine angemessene Größenordnung erreichen.
Antwort4
Ich beschäftige mich mit einem ähnlichen Problem, obwohl die Zahl der Kunden im Hunderter- oder vielleicht im Tausenderbereich liegt.
Mir ist klar geworden, dass ich nicht die ständige Verbindung aller Clients aufrechterhalten kann.
Ich denke daran, den OpenVPN-Daemon auf den Clients in zufälligen Zeitabständen zu starten, damit sie prüfen können, ob sie abgefragt wurden. Wenn dies der Fall ist, sollen sie eine E-Mail oder etwas Ähnliches senden, das besagt, dass sie online sind, und für einen bestimmten Zeitraum Keep-Alive-Pakete senden, damit ich eine Verbindung zu ihnen herstellen kann.
Wenn für einige Zeit kein Verkehr herrscht, wird der Daemon gestoppt.
Das Problem, mit dem ich derzeit konfrontiert bin, ist, dass es unmöglich scheint, eine Liste der aktuell verbundenen VPN-Clients zu erhalten ...