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
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-Anweisung 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 "openvpn-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 *