☰

Best Practices zum Einrichten mehrerer OpenVPN-Instanzen für verschiedene Clients

tag-icon • tag-icon linux vpn openvpn pki
Best Practices zum Einrichten mehrerer OpenVPN-Instanzen für verschiedene Clients

Ich arbeite an einem Projekt, bei dem ich OpenVPN-Instanzen einrichten muss, um IoT-Geräte verschiedener Kunden mit einem zentralen Server zu verbinden. Jeder Client sollte seine eigene isolierte VPN-Verbindung haben. Ich plane derzeit die Infrastruktur und das Zertifikatshandling und hätte gerne Ratschläge zum besten Ansatz.

Für die Zertifikatsverwaltung stelle ich mir folgende Struktur vor:

CA.crt
|_Customer1.crt
|  |_ServerCert.crt
|     |_ClientCert1.crt
|     |_ClientCert2.crt
|     |_ClientCertX.crt
|
|_Customer2.crt
   |_ServerCert.crt
      |_ClientCert1.crt
      |_ClientCert2.crt
      |_ClientCertX.crt

Daher würde ich für jeden Client eine separate OpenVPN-Instanz einrichten, etwa /etc/openvpn/server/Client1/und /etc/openvpn/server/Client2/, und sie mit Befehlen wie den folgenden starten:

sudo systemctl start [email protected] Ist das ein akzeptabler Ansatz? Ich würde mich über alle Erkenntnisse oder alternativen Vorschläge zur Organisation der Infrastruktur für mehrere VPN-Clients und -Server freuen.

Weitere Fragen sind:

  • Wie verwaltet man viele dezentrale Geräte, vielleicht mit Ansible?
  • Für jede OpenVPN-Instanz benötige ich einen zusätzlichen Port.
    • Was kommt als nächstes, nachdem 443 TCP, UDP und 1194 TCP, UDP verwendet wurden?

Danke schön!

Antwort1

Im OpenVPN-Handbuch heißt es, dass jedem Zertifikat vertraut wird, das von dem darin konfigurierten CA-Zertifikat abstammt. Um VPNs wirklich zu trennen, lassen Sie also das Stammzertifikat aus allen Konfigurationen weg. Es wird nirgendwo verwendet, bringt keinen Wert oder Nutzen, also warum sollte man es pflegen? Nehmen Sie einfach EasyRSA und erstellen Sie für jedes VPN eine separate und unabhängige „Stamm-CA mit einer Ebene“.

Ich weiß nicht, warum Sie hier Port 443 aufgeführt haben. Er wird selten für OpenVPN verwendet, da er ein bekannter HTTPS-Port ist und häufig belegt ist. Wenn er also verwendet wird, sind häufig knifflige Konfigurationen erforderlich port-share. In diesem Fall sslhist Port 443 besser geeignet, zumindest weil Sie den „transparenten Modus“ verwenden können, damit Daemons die echte IP-Adresse der Remote-Verbindung sehen können und sich nicht mit der Art und Weise herumschlagen müssen, wie OpenVPNs diese Informationen verfügbar macht. Ich bezweifle jedoch, dass Sie diese Besonderheit für Ihr Projekt benötigen. Abgesehen davon können Sie wirklich beliebige Portnummern verwenden. 1194 ist als „offiziell“ aufgeführt, aber nichts verbietet Ihnen, 11941 oder 1195 oder 5000 (was vor 15 Jahren vorgeschlagen wurde) oder etwas anderes einzustellen. Wählen Sie eine Reihe von Ports aus, beginnen wir beispielsweise mit 1194 und höher, und fügen Sie für jede nachfolgende VPN-Instanz einfach einen hinzu.

Der Rest ist richtig: Sie verwenden separate (öffentliche) Ports für unabhängige Daemons und führen sie als separate SystemD-Einheiten aus. Erwägen Sie separate Container für verschiedene VPNs: Obwohl es möglich ist, separate VPN-Instanzen im einzelnen Namespace auszuführen, ist es einfacher und weniger fehleranfällig, sie einfach aufzuteilen (und nicht viel ressourcenintensiver). So wie ich es verstanden habe, sind Ihre Kunden unabhängige Einheiten, daher wäre dies eine einfachere Möglichkeit, sie zu trennen. In diesem Fall verwenden VPN-Konfigurationen innerhalb von Containern möglicherweise den Standardport, aber Sie leiten (veröffentlichen) unterschiedliche Ports für sie weiter.

Legen Sie ein System fest, das ausschließlich für die Verwaltung von VPNs bestimmt ist. Es speichert Ihre CAs und kann daher nur Zertifikate ausstellen. Dieses System wird auch zum Ausstellen von CRLs benötigt. Standardmäßig sind CRLs 30 Tage lang gültig, und wenn Sie dies konfigurieren crl-verify(und das werden Sie tun!), akzeptiert das VPN nach Ablauf der CRL keine neuen Verbindungen mehr, bis sie wieder gültig ist. Was Sie also wirklich automatisieren müssen, ist die Neuausstellung und Verteilung von CRLs. Wenn Sie die CRL-Datei aktualisieren, müssen Sie den Daemon nicht neu laden, es scpreicht also aus, sie einfach über die alte Datei zum Zielsystem zu übertragen.

Es ist sinnvoll, eine Vorlage für eine OpenVPN-Clientkonfigurationsdatei zu erstellen und aus dieser Vorlage Clientkonfigurationen mit eingebetteten Zertifikaten zu generieren. Das hat mir auch ohne Ansible viel Zeit gespart. Ich passe häufig gebündelte openssl.cnfDateien an vars, um mehrere Felder hinzuzufügen und ungenutzte zu entfernen, Dinge neu zu organisieren und sie mit weniger Fragen auszuführen (oder ohne Fragen, für die Stapelverarbeitung). In Ihrem Fall kann es auch nützlich sein, solche Vorlagen und Generierungsskripte zum Erstellen neuer VPNs und Serverkonfigurationen zu haben. Solche Vorlagen, Skripte und Anpassungen sind für Ansible-Playbooks nützlich, die neue Kunden oder neue IoT-Geräte eines bestehenden Kunden instanziieren. Für Letzteres kann es sinnvoll sein, die CN des Zertifikats mit der Seriennummer des IoT-Geräts zu verknüpfen, was die Abrechnung vereinfachen sollte.

verwandte Informationen