Neben den Möglichkeiten mit 6tunnel oder Anbietern wie Feste-IP.net einzelne Ports von einem vServer mit öffentlicher IPv4-Adresse zu einem CGN-/DS-Lite-Anschluss mit hoffentlich statischer IPv6-Adresse umzuleiten, gibt es noch die Variante, das sich das heimische Netzwerk via OpenVPN zu einem vServer verbindet und der für die Server/Dienste eingehende Datenverkehr entsprechend umgeleitet wird.
Eine solche Lösung hat ggf. den Charme, das man keine Schwierigkeiten mit wechselnden IP-Adressen am Anschluss hat und in einer Fallback-Situation (LTE- statt VDSL, etc.) dennoch die Dienste von außen wie gewohnt erreichbar sind.
In diesem Beispiel kommt eine pfSense als OpenVPN-Client am CGN- bzw. DS-Lite-Anschluss und ein vServer in KAMP’s DHP Mini-Paket mit Debian 10 Buster als OpenVPN-Server zum Einsatz.
Bemerkung: Vorab der Hinweis, das dies ein erster Aufbau eines solchen Konstruktes ist. Statt PSK sollte (später) eine PKI für OpenVPN verwendet werden. Ferner fehlt es mir noch ein Erfahrung hinsichtlich nftables. Darüber hinaus ist angedacht weitere Beiträge zu diesem Thema in Verbindung mit der erwähnten PKI, anderen Routern (OPNsense, Securepoint UTM, evtl. auch FRITZ!BOX dann allerdings mit IPsec, das ganze Thema evtl. auch mal mit Wireguard) zu schreiben. Generell sind Verbesserungsvorschläge willkommen, einfach die Kommentar-Funktion nutzen.
KAMP DHP Mini vServer konfigurieren
- Einen neuen vServer mit Debian 10 Buster anlegen und starten.
- Die Firewall-Regeln für den Zugriff per ssh (Port 22/tcp) und OpenVPN (Port 1194/udp) im ControlCenter erstellen.
Troubleshooting: Sollte der vServer mittels ssh und Ping nicht erreichbar sein, dann diesen nochmals neu starten. Es kommt vor, das beim ersten Start die IP-Konfiguration nicht richtig übernommen wird.
- Folgende Befehle via ssh und als root ausführen:
IP-Forwarding (Routing) aktivieren:
nano /etc/sysctl.conf
net.ipv4.ip_forward=1
Die Änderung speichern und anwenden:
sysctl -p
Den OpenVPN-Server vorbereiten:
apt install openvpn
cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz /etc/openvpn/server
gzip -d /etc/openvpn/server/server.conf.gz
mv /etc/openvpn/server/server.conf /etc/openvpn/
Einen shared key erstellen:
cd /etc/openvpn
openvpn --genkey --secret static.key
Optional: Die Beispielkonfiguration zur Sicherheit kopieren (für den Fall das etwas schief läuft):
cp server.conf server.conf.original
Die Server-Konfiguration bearbeiten:
nano server.conf
und wie folgt abändern:
# ca ca.crt
# cert server.crt
# key server.key # This file should be kept secret
secret /etc/openvpn/static.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
# dh dh2048.pem
# tls-auth ta.key 0 # This file is secret
log /var/log/openvpn/openvpn.log
auth SHA256
comp-noadapt
route 192.168.1.0 255.255.255.0
- Den OpenVPN-Daemon beim Booten starten:
systemctl enable openvpn@server
- Den OpenVPN-Daemon starten:
- Bei „Compression“ „Omit Preference, +Disable Adaptive LZO Compression [Legacy style, comp-noadapt]“ auswählen.
systemctl start openvpn@server
Der OpenVPN-Daemon sollte nun laufen. Der aktuelle Status kann mit
systemctl status openvpn@server
überprüft und das Protokoll kann unter „/var/log/openvpn“ eingesehen werden.
pfSense konfigurieren
- Unter „VPN – OpenVPN – Clients“ eine neue Verbindung anlegen.
- Bei „Server Mode“ „Peer to Peer (Shared Key)“ auswählen.
- Bei „Server host or address“ die IP-Adresse des vServers eintragen.
- Bei „Cryptographic Settings“ den Haken entfernen bei „Auto generate“ und im daraufhin erscheinenden Feld „Shared Key“ den Inhalt aus der Datei „static.key“ vom vServer einfügen.
- Bei „Encryption Algorithm“ „AES-256-CBC (256 bit key, 128 bit block)“ auswählen.
- Bei „IPv4 Tunnel Network“ „10.8.0.0/24“ eintragen.
- Bei „Compression“ „Omit Preference, +Disable Adaptive LZO Compression [Legacy style, comp-noadapt]“ auswählen.
- Auf „Save“ klicken.
- Unter „Firewall – Rules – OpenVPN“ eine Regel anlegen, die Verbindungen vom VPN aus zulässt. Für den ersten Test tut’s eine Any-Regel, diese sollte später unbedingt wieder deaktiviert oder entfernt werden und granularere Regeln setzen.
Der Client beginnt sofort mit dem Verbindungsaufbau. Den aktuellen Stand der Verbindung kann man unter „Status – OpenVPN“ einsehen.
Routing testen
Vom vServer aus sollte man sowohl die IP-Adressen 10.8.0.2 als auch 192.168.1.1 (und weitere im LAN) anpingen können. Von der pfSense bzw. aus derem LAN aus sollte man 10.8.0.1 anpingen können.
Port-Forwarding auf dem vServer konfigurieren
Debian 10 Buster verwendet nftables statt iptables als Firewall bzw. für das Port-Forwarding.
Auf dem vServer folgende Befehle als root ausführen:
apt install nftables
systemctl enable nftables.service
Eine Konfigurationsdatei bzw. die Regeln in der Datei „/etc/nftables.conf“ können z.B. wie folgt aussehen:
#!/usr/sbin/nft -f
flush ruleset
table inet filter {
chain input {
type filter hook input priority 0;
# accept any localhost traffic
iif lo accept
# accept traffic originated from us
ct state established,related accept
# accept ping
ip protocol icmp icmp type echo-request ct state new accept
# ssh
tcp dport 22 ct state new accept
# http
tcp dport 80 ct state new accept
# OpenVPN
udp dport 1194 ct state new accept
udp dport 1195 ct state new accept
# accept neighbour discovery otherwise IPv6 connectivity breaks.
ip6 nexthdr icmpv6 icmpv6 type { nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert } accept
# count and drop any other traffic
counter drop
}
chain forward {
type filter hook forward priority 0;
}
chain output {
type filter hook output priority 0;
}
}
table ip nat {
chain prerouting {
type nat hook prerouting priority 0;
# redirect port 80/tcp (http) to webserver
iif eth0 tcp dport { 80 } dnat 192.168.1.2
# redirect port 1194/udp (OpenVPN) to pfSense
iif eth0 udp dport { 1194 } dnat 192.168.1.1
}
chain postrouting {
type nat hook postrouting priority 100;
oif tun0 masquerade
}
}
In diesem Beispiel wird in der Tabelle „inet“ sowohl Ping, ssh, http als auch OpenVPN zugelassen. Ping und ssh gilt dabei nur für den vServer. Http wird weitergeleitet und bei OpenVPN ist der Port 1195/udp für den lokalen OpenVPN-Server zu dem sich die pfSense verbindet, während der Port 1194/udp für Roadwarrior ist und zur pfSense weitergeleitet wird.
Die eigentlichen Port-Weiterleitungen werden in der Tabelle „ip nat“ definiert. Anhand der Einträge kann man die Weiterleitung von http (80/tcp) und OpenVPN (1194/udp) zum jeweiligen Host gut ablesen.
Es ist dringend empfohlen die Regeln zu dokumentieren, damit man den Überblick oder die Hintergründe (wieso/weshalb/warum, wohin) nicht verliert.
Hinweis: In diesem Beispiel sind keine Regeln enthalten, wie man ggf. Ports in den Tabellen „inet filter“, „ip filter“ oder „ipv6 filter“ zur generellen Erreichbarkeit der Ports, Interfaces oder dem Weiterleiten bzw. Zulassen von Paketen konfiguriert. Sofern man die genannten Tabellen verwendet, müssen entsprechende Regeln hinterlegt werden! Ausgehend von einem frisch installierem Debian 10 Buster mit nftables funktioniert das genannte Beispiel wie beschrieben, da keine weiteren Tabellen konfiguriert sind.
Damit Änderungen an der Konfigurationsdatei übernommen werden als root den Befehl
nft -f /etc/nftables.conf
ausführen.
Tipp: Je nach vServer und Konfiguration des eingesetzten Linux kann es vorkommen, das der „nft“-Befehl nicht gefunden wird. In einem solchen Fall zunächst zu root mittels „sudo su“ oder „su -“ wechseln.
Zu beachten
Wo Licht ist, ist auch Schatten. Am Beispiel des Webserver sieht man im Protokoll als Client-Adresse lediglich die OpenVPN-IP des vServers. D.h. die eigentliche IP-Adresse eines Website-Besuchers kann man so nicht mehr ermitteln, in Folge funktionieren etwaige Filter- oder Schutzmaßnamen auf dem Webserver nicht (mehr). Solche Mechanismen müssten auf den vServer vorgelagert werden. Speziell für Webserver wäre es eine Überlegung über einen Reverse Proxy nachzudenken.
Ähnliches gilt für SMTP, dieses könnte man einfach weiterleiten, geschickter kann allerdings sein, den vServer als Smart Host zu verwenden.
Leitet man OpenVPN weiter und der OpenVPN-Server ist eine pfSense, so muss in der Server-Konfiguration das richtige Interface angegeben werden. Per Default wird immer „WAN“ verwendet. Für die Weiterleitung muss dann das Interface ggf. auf „LAN“ oder „any“ gestellt werden.
Gleichfalls relevant für das Weiterleiten von OpenVPN sind unterschiedliche Ports. Standard ist 1194/udp, wird dieser allerdings bereits verwendet, beispeilsweise wie hier beschrieben um die pfSense an den vServer „anzudocken“, dann muss ein anderer Ports für die Roadwarrior oder Site-to-Site-Verbindungen verwendet werden!
Was noch?
Die Server bzw. Dienste müssen auf die Anfragen vom VPN antworten können, d.h. beispielsweise evtl. Interface-Bindung (engl. binding), lokale Firewall-Regeln, etc. prüfen und anpassen.
Verwendet man DNS, gemeint ist FQDN, um von extern auf Ressourcen zuzugreifen muss in diesem die öffentliche IP-Adresse des vServer hinterlegt werden.
Wie eingangs erwähnt wird hier für den ersten Test und den Anfang PSK verwendet. Aus Gründen der Sicherheit sollte zumindest später auf eine PKI gesetzt werden!
Im Gegensatz zu so manch anderem vServer-Anbieter muss man bei KAMP die Firewall-Regeln doppelt pflegen, einmal im ControlCenter und einmal im vServer selbst.
Als alternativer Anbieter kein beispielsweise netcup verwendet werden, dort gibt es sehr günstige vServer (ungetestet).
Zu beachten ist außerdem der Traffic den man erzeugt, denn bei KAMP’s DHP Mini sind 10 GB pro Tag inkludiert, bei netcup 40 TB pro Monat.
Quellen:
OpenVPN – FAQ – What is and how do I enable IP forwarding on Linux?
TecAdmin.net – How To Enable IP Forwarding on Linux
OpenVPN – Static Key Mini-HOWTO
DigitalOcean – How To Set Up an OpenVPN Server on Debian 9
Debian – Wiki – OpenVPN
superuser – Complete masquerading NAT example using nftables on Linux?
GitHub – mqus/nft-rules – VPN Server
debianforum.de – Port Forwarding in OpenVPN-Tunnel
Schon immer Technik-Enthusiast, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen. Die Schwerpunkte liegen auf der Netzwerkinfrastruktur, den Betrieb von Servern und Diensten.
