Kaum ein Monat vergeht, in dem keine Presseberichte von einem größeren Datenleck die Runde machen – zuletzt traf es den Mietwagenanbieter Buchbinder. Die ... (mehr)

Zertifikate und Schlüssel erzeugen

Das Toolset "Easy-Rsa" macht es dem Anwender sehr leicht, Zertifikate und Schlüssel zu verwalten. Nach der Installation finden sich die Pakete unter "/usr/share/ easy-rsa/<Versionsnummer>". Legen Sie einen passenden Ordner für Ihre Certificate-Authority-Konfiguration an; wir verwenden dafür einfach "/root/rsa". Kopieren Sie den kompletten Inhalt des "easy-rsa"-Unterverzeichnisses (im Workshop Version 3.0.6) nach "/root/rsa".

Als Erstes benötigt das SSL-VPN eine Zertifizierungsstelle, die Certificate Authority (CA). Die erstellt sich der Anwender einfach selbst, ein "offizielles" Zertifikat ist für das private VPN nicht nötig. Ebenso kann der Anwender auf detaillierte Metadaten seiner CA (Land, OU, Bundesstaat, Ansprechpartner, Ort et cetera) verzichten. Auf die Funktion des VPNs haben diese Informationen keinen Einfluss.

Innerhalb des "/root/rsa"-Verzeichnisses starten Sie jetzt das Kommando »./easyrsa init-pki« , das ein "pki"-Verzeichnis und die CA-Konfigurationsdatei in "/root/rsa/ pki" anlegt. Dann erstellen Sie Ihre eigene Root-CA nebst Zertifikat plus passenden Schlüssel mit dem Kommando »./easyrsa build-ca« . Sichern Sie den CA-Schlüssel mit einem starken Passwort ab. Wer den Zugriff zu Schlüssel und CA erhält, kann jederzeit Clientschlüssel erstellen und signieren.

Im zweiten Schritt bekommt der OpenVPN-Server selbst ein gültiges Serverzertifikat namens "vpnserver" und einen passenden Schlüssel, der dann allerdings ohne Passwort funktionieren muss. Würden Sie ein Serverzertifikat mit Passwort auf dem Schlüssel bauen, müssten Sie bei jedem Start des VPN-Servers dieses Passwort eintippen:

./easyrsa gen-req vpnserver nopass

Das Kommando »gen-req« erstellt dabei zunächst einen Request für das Zertifikat, der im nächsten Schritt von der CA signiert wird:

./easyrsa sign-req server vpnserver

Details zum Zertifikat und dessen Gültigkeit erhalten Sie mit dem openssl-Tool:

openssl x509 -text -noout -in pki/issued/vpnserver.crt

Dabei tragen Sie besser schon einmal im Kalender rot ein, dass die mit den Default-Einstellungen erzeugten Zertifikate 1080 Tage lang gültig sind. In knapp drei Jahren brauchen Sie also neue. Passend zum Server benötigt jeder VPN-Client ein eigenes Zertifikat, das Sie nach demselben Prinzip anfordern und signieren:

./easyrsa gen-req client01 nopass
./easyrsa sign-req client client01

Theoretisch erlaubt OpenVPN, dass sich mehrere Clients gleichzeitig mit demselben Zertifikat anmelden. So könnte ein einziges Clientzertifikat für viele Systeme genügen. Davon ist aber dringend abzuraten. Sollte eines Ihrer Engeräte mit installiertem VPN-Clientzertifikat abhandenkommen oder ein Unbefugter ein Clientzertifikat abgreifen, kann OpenVPN auf dem Server einzelne Zertifikate für ungültig erklären und damit den betroffenen Zugang sperren. Dazu würden Sie den entsprechenden Eintrag zurücknehmen

./easyrsa revoke irgendeinclient

und eine Liste der ungültigen Zertifikate erstellen

./easyrsa gen-crl

Diese "Certificate Revoking List" müssen Sie danach in der OpenVPN-Server-Konfiguration eintragen. Zu den Zertifikaten gesellt sich abschließend ein "Diffie-Hellman"-Schlüssel. In Kombination mit der CA und dem Clientschlüssel errechnet OpenVPN dann die eigentlichen Transfer-Keys für den VPN-Tunnel: »./build-dh.« Die benötigten Schlüssel und Zertifikate kopieren Sie in das Konfigurationsverzeichnis des OpenVPN-Servers

cp /root/rsa/pki/dh.pem /etc/openvpn/server/
cp /root/rsa/pki/ca.crt /etc/openvpn/server/
cp /root/rsa/pki/issued/vpnserver.crt /etc/openvpn/server/
cp /root/rsa/pki/private/vpnserver.key /etc/openvpn/server/

Anschließend erstellen Sie die Konfiguration "/etc/openvpn/server/server.conf" für den OpenVPN-Server mit folgendem Inhalt:

#OpenVPN Server Config
port      443
proto    tcp
dev       tun

Diese Konfiguration legt den Port, das Protokoll und den Modus als Router (dev tun = Tunneling Device) fest.

ca         ca.crt
cert      vpnserver.crt
key       vpnserver.key
dh        dh.pem

verweist auf die zu verwendenden Schlüssel. Gesetzt den Fall, Sie müssten ein Zertifikat widerrufen, würden Sie hier zudem den Verweis auf die Certificate Revocation List einfügen:

crl-verify     crl.pem

Tunnel bauen

Anschließend legen Sie die Parameter des Tunnels fest. Mit

server 10.9.8.0 255.255.255.0

bestimmen Sie das IP-Netzwerk des Tunnels. Es folgen

push "redirect-gateway def1"
push "dhcp-option DNS 9.9.9.9"

Mit den push-Anweisungen überträgt der VPN-Server Kommandos für das IP-Setup an den Client. Mit "redirect-gateway def1" beispielsweise weist der OpenVPN-Server seine Clients an, die Default-IPv4-Route auf den Tunnel zu legen und damit, den gesamten IP-Traffic des Clients über das VPN zu transferieren. Sollen Clients nur den Traffic für das Intranet des VPN-Servers (Beispiel 172.27.0.0/16) in den Tunnel packen, würde die push-An­weisung stattdessen "route 172.27.0.0 255.255.0.0" lauten.

Das push-Kommando mit der DHCP-Option "DNS" ändert den zu verwendenden DNS-Server des Clients. Das ist zum einen für Intranets mit eigenem Nameserver wichtig. Zum andern sind die DNS-Servers eines lokalen Netzwerkes (Beispiel offenes WLAN) nur innerhalb des Netzwerks erreichbar und funktionieren daher nicht mehr, wenn der Client seine DNS-Anfragen über den Tunnel versendet. Daher muss hier ein DNS-Server stehen, auf den der VPN-Server zugreifen kann.

Leider funktioniert genau diese wichtige Option bei diversen Clientsetups und Betriebssystemen nicht richtig. Wer einen Client mit einer statischen DNS-Konfiguration (statt DHCP) betreibt, setzt das Kommando nicht um.

Zudem kommt es speziell auf MacOS-Clients immer wieder zu Problemen, da das Betriebssystem dem Nutzer oft nicht gestattet, die globale DNS-Einstellung zu ändern. Hier helfen oft nur Clientskripte, die das "up"-Kommando in der VPN-Client-Konfigurationsdatei starten – zur Not eben mit erhöhten Systemprivilegien. Linux-Clients, die den "NetworkManager" als Dienst verwenden, haben in der Regel keine Probleme.

Die "keepalive"-Direktive prüft regelmäßig, ob die Verbindung zum Client noch besteht. Sollte die Verbindung abbrechen, muss sie der Client neu initiieren. Die "persist"-Anweisungen verhindern dabei, dass der Server das betreffende "tun"-Device (Netzwerktunnel) abschaltet und den aktuellen Transferschlüssel verwirft. Das beschleunigt den Reconnect:

keepalive 10 120
persist-key
persist-tun

Optional kann der Anwender die Log-Verbosity (Ausführlichkeit) des VPN-Servers konfigurieren und eine eigene Logdatei für den OpenVPN-Dienst erstellen:

verb 3
log-append /var/log/openvpn.log

Weitere Konfigurationsanweisungen braucht der VPN-Server erst einmal nicht und lässt sich dann via

systemct enable openvpn-server@server.service –now

aktivieren und starten.

Der Service heißt übrigens aus dem Grund "...@server.service", weil der Name nach dem "@" auf die Konfigurationsdatei verweist. Somit könnten Anwender bei Bedarf mehrere VPN-Services mit verschiedenen Konfigurationen parallel auf einem Server laufen lassen. Ein "open­vpn-server@second.service" würde seine Konfiguration aus der Datei "/etc/openvpn/server/second.conf" beziehen.

Erhalten Sie beim ersten Start die Fehlermeldung, dass der OpenVPN-Server die "server.conf"-Datei oder eines der Zertifikate nicht lesen kann, hat wahrscheinlich SELinux ein Problem mit dem Security Context der Dateien. Abhilfe schafft dann

cd /etc/openvpn/server restorecon *
Bild 3: Mit einigen wenigen Angaben ist die VPN-Konfiguration auf dem Client dank NetworkManager erledigt.
comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023