Öffentliche IPv4-Adresse an CGN-/DS-Lite-Anschluss mittels vServer und OpenVPN Peer to Peer (SSL/TLS)

Wie im ersten Beitrag dieser Serie angekündigt folgt nun die Variante mit “Peer to Peer (SSL/TLS)”, also der Verwendung von Zertifikaten statt eines PSK. Abgesehen von der PKI- und OpenVPN-Konfiguration auf beiden Seiten ändert sich sonst nichts, daher hier im wesentlichen nur die Änderungen gegenüber dem ersten Beitrag.

PKI erstellen

Für die Nutzung von Zertifikaten wird eine PKI (Public Key Instructur, dt. Zertifikatsinfrastruktur), kurzum eine eigene Zertifizierungsstelle die Zertifikate ausgibt, benötigt.

Bemerkung: Der Vollständigkeit halber sei erwähnt, das man eine PKI/CA auch offline betreiben kann bzw. diese nicht zwingend auf dem vServer sein muss. Man kann genauso gut die notwendigen Zertifikate bspl. auf der pfSense erzeugen, die Zertifikate die für den vServer sind exportieren und das CA- und Client-Zertifikat einfach bei der Konfiguration auf der Client-Seite auswählen. Von Vorteil bei dieser Variante ist eine einfachere Handhabung dank GUI und mehr Sicherheit, falls der vServer doch mal kompromitiert werden sollte.

Für das hier genannte Vorhaben werden drei Zertifikate gebraucht: 1x CA, 1x Server, 1x Client. Diese werden alle auf dem vServer erzeugt. Auf diesem als root folgende Befehle ausführen:

EasyRSA vorbereiten:

cp -r /usr/share/easy-rsa /etc/openvpn/
cd /etc/openvpn/easy-rsa
mv vars.example vars

Die Datei “vars” editieren und ab Zeile 97 auf die eigenen Bedürfnisse hin anpassen:

#set_var EASYRSA_REQ_COUNTRY "US"
#set_var EASYRSA_REQ_PROVINCE "California"
#set_var EASYRSA_REQ_CITY "San Francisco"
#set_var EASYRSA_REQ_ORG "Copyleft Certificate Co"
#set_var EASYRSA_REQ_EMAIL "me@example.net"
#set_var EASYRSA_REQ_OU "My Organizational Unit"

Wichtig: Die vorangestellte # entfernen!

./easyrsa init-pki

CA erstellen

./easyrsa build-ca nopass

Als CA-Namen bspl. “OpenVPN-CA” eingeben.

Server-Zertifikat erstellen

./easyrsa gen-req OpenVPN-Server nopass
./easyrsa sign-req server OpenVPN-Server

Als Server-Namen bspl. “OpenVPN-Server” eingeben.

Client-Zertifikat erstellen

./easyrsa gen-req OpenVPN-Client nopass
./easyrsa sign-req client OpenVPN-Client

Als Client-Namen bspl. “OpenVPN-Client” eingeben.

Nachdem die Zertifikate und Schlüssel erzeugt wurden, diese umkopieren:

cp /etc/openvpn/easy-rsa/pki/ca.crt /etc/openvpn
cp /etc/openvpn/easy-rsa/pki/issued/OpenVPN-Server.crt /etc/openvpn
cp /etc/openvpn/easy-rsa/pki/private/OpenVPN-Server.key /etc/openvpn

DH-Parameter und TLS-Key (für HMAC) erzeugen

openssl dhparam -out /etc/openvpn/dh2048.pem 2048
/usr/sbin/openvpn --genkey --secret /etc/openvpn/ta.key

OpenVPN-Server konfigurieren

Gegenüber der Beispielkonfiguration von Debian muss die Datei “/etc/openvpn/server.conf” wie folgt abgeändert werden:

tls-server
ca ca.crt
cert OpenVPN-Server.crt
key OpenVPN-Server.key

# server 10.8.0.0 255.255.255.0

# ifconfig-pool-persist /var/log/openvpn/ipp.txt

ifconfig 10.8.0.1 10.8.0.2

comp-lzo no
compress

log         /var/log/openvpn/openvpn.log

auth SHA256

route 192.168.1.0 255.255.255.0

Anschließend einmal den Daemon durchstarten:

systemctl restart openvpn@server

pfSense konfigurieren

Zunächst müssen das Zertifikat der CA (ohne privaten Schlüssel) und des Clients inkl. des privaten Schlüssels importiert werden:

  • Über “System – Cert. Manager” auf der Registerkarte “CAs” auf “+ Add” klicken.
  • Bei “Descriptive name” den Namen, z.B. OpenVPN-CA, eingeben.
  • Bei “Method” “Import an existing Certificate Authority” auswählen.
  • Im Feld “Certificate data” die Daten aus der Datei “ca.crt” einfügen und auf “Save” klicken.
  • Auf die Registerkarte “Certificates” wechseln und auf “+ Add/Sign” klicken.
  • Bei “Method” “Import an existing Certificate” auswählen.
  • Bei “Descriptive name” den Namen, z.B OpenVPN-Server, eingeben.
  • Im Feld “Certificate data” die Daten (ab “—–BEGIN CERTIFICATE—–“) aus der Datei “OpenVPN-Client.crt” einfügen.
  • Im Feld “Private key data” die Daten aus der Datei “OpenVPN-Client.key” einfügen.

Der VPN-Client wird wie folgt konfiguriert:

  • Unter “VPN – OpenVPN – Clients” eine neue Verbindung anlegen.
  • Bei “Server Mode” “Peer to Peer (SSL/TLS)” auswählen.*
  • Bei “Server host or address” die IP-Adresse des vServers eintragen.
  • Bei “Automatically generate a TLS Key.” den Haken entfernen und im erscheinenden Feld “TLS key” den Inhalt der Datei “ta.key” einfügen.
  • Bei “Peer Certificate Authority” das zuvor importierte CA-Zertifikat auswählen.
  • Bei “Client Certificate” das zuvor importierte Client-Zertifikat auswählen.
  • Bei “Encryption Algorithm” “AES-256-CBC (256 bit key, 128 bit block)” auswählen.
  • Bei “IPv4 Tunnel Network” “10.8.0.0/24” eintragen.
  • Auf “Save” klicken.

Der Client beginnt sofort mit dem Verbindungsaufbau. Den aktuellen Stand der Verbindung kann man unter „Status – OpenVPN“ einsehen.

Den Rest, d.h. Firewall-Regeln, etc. kann man im ersten Beitrag zu diesem Thema nachlesen.

Quellen:

HowtoForge – How to install and configure OpenVPN Server on Debian 10

archlinux – Wiki – Easy-RSA

OpenVPN – Easy-RSA v3 OpenVPN Howto

OpenVPN – 1x HOW TO

OpenVPN – Reference manual for OpenVPN 2.4

OpenVPN – Getting started How-To

DigitalOcean – How To Set Up an OpenVPN Server on Debian 10

Debian – Wiki – OpenVPN

NetGate – PfSense – OpenVPN compression

Update 02.07.2020

Damit die Portweiterletungen auch nach einem Verbindungsabbruch funktionieren muss eine kleine Erweiterung eingebaut werden:

Debian, OpenVPN und nftables: Regeln nach Verbindungsaufbau neu laden

3 Kommentare

  1. Florian Schermer

    Hi Andy,

    ich habe bei dem letzten Beitrag gedacht, dass es Gedankenübertragung sein muss. Wir arbeiten an dem meisten Themen parallel.

    Ich sehe bei einer Konstellation so wie du es aktuell eingerichtet hast keine Vorteil der PKI zu shared Keys. Eine PKI würde aus meiner Sicht nur Sinn machen, wenn ich mit einem VServer mehrere Endpoint bediene und du mal einen Endpoint deaktivieren willst.
    Dies würde aber das Problem bringen, dass ich noch einen Reverse Proxy auf dem Vserver bräuchte.

    Gruss

    Flo

  2. Andy

    Hallo Flo,

    wie sagt man so schön: Zwei D… ähm Admins, ein Gedanke 😉

    Ich sag mal Jein zum Vor-/Nachteil des PSK. I.d.R. gilt PKI als sicherer, hinzu kommt bei der Ergänzung generell mehr Sicherheit durch TLS key/HMAC und DH, was beides im ersten Beitrag nicht enthalten ist. Zusätzlich ist bei der Ergänzung die Komprimierung deaktiviert, da es da wohl Angriffsvektoren gibt (siehe Quellen).

    Im Grunde habe ich nichts gegen PSK, sofern starke Schlüssel verwendet werden. Während der Entwurfsphase des ersten Beitrags wurde ich allerdings mehrfach wegen der fehlenden Zertifikate “angegangen”. Darüber hinaus soll’s noch einen Beitrag zu dem Thema in Verbindung mit einer Securepoint UTM geben und die kann nur PKI. In sofern baut das alles mehr oder weniger aufeinander auf bzw. wird text-sharing gemacht.

  3. K. Frieseke

    Die Problematik der Port Weiterleitung in den Tunnel ist auch hier sehr gut erklärt.
    Wichtig ist das man am vServer auf die Tunnel IPs NATet, ansonsten forwardet der remote Webserver die Antwort direkt über den remoten Router statt über den Tunnel was dann die TCP Session scheitern lässt:

    https://administrator.de/forum/wie-portforwarding-ueber-2-miteinander-verbundenen-pfsense-realisieren-1161214871.html#comment-1291445373

    und Wireguard

    https://administrator.de/forum/routing-zwischen-zwei-pfsense-nutzung-von-public-ip-4173107487.html#comment-4175977564

    Es geht übrigens auch mit den bordeigenen VPN Clients auf Windows usw.

    https://administrator.de/tutorial/ikev2-vpn-server-fuer-windows-und-apple-clients-mit-raspberry-pi-1754377434.html#toc-12

    Gruß
    Kim

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

© 2024 Andy's Blog

Theme von Anders NorénHoch ↑