Das Problem
Dank Dual-Stack Lite (DS-Lite) steigt die Anzahl der Endkunden, denen keine global routbare IPv4-Adresse zur Verfügung steht. Dies schränkt das Hosten von Servern ein, die auch über eine IPv4-Adresse erreichbar sein sollen. In diesem Beitrag beschreibe ich anhand eines Teamspeak-Servers eine Möglichkeit, das geschilderte Problem zu umgehen.
Voraussetzungen
- V-Server („VPS“), Root-Server o.ä. mit fester IPv4- und IPv6-Adresse
- Sophos UTM oder andere Router-Distribution mit IPsec site-to-site Unterstützung
Übersicht
Wie die Grafik zeigt, wird ein IPsec-Tunnel zwischen dem V-Server und der lokalen Firewall eingerichtet. Zum Ansprechen des eigenen Webservers kann die öffentliche IP-Adresse des V-Servers genutzt werden, der Datenverkehr soll durch das IPsec-VPN geroutet werden.
V-Server-Konfiguration
Auf dem VPS sollte eine aktuelle Linux-Serverinstallation vorhanden sein, wie Debian 10. Für das IPsec-VPN wird das Programm „Strongswan“ installiert:
apt-get install strongswan libcharon-extra-plugins
Bevor nun die Schlüsselpaare erstellt werden, muss der RSA-Key der UTM kopiert und in eine Datei auf dem Server gespeichert werden.
Dazu kann ein beliebiger Texteditor verwendet werden, beispielsweise Nano. Der kopierte Schlüssel kann eingefügt und die Datei gespeichert werden.
mkdir /etc/ipsec.d/rsa
cd /etc/ipsec.d/rsa
nano utm.pub
Im nächsten Schritt wird das RSA-Schlüsselpaar erzeugt und umgewandelt. Eine detaillierte Beschreibung kann in dem Artikel von Martin Seener gefunden werden.
openssl genrsa -out privkey.key 4096
openssl rsa -in privkey.key -out privkey.der.key -outform DER
openssl rsa -in privkey.key -outform DER -pubout -out public.der
openssl rsa -in privkey.key -outform PEM -pubout -out public.pem
cd /tmp
git clone https://github.com/ryanriske/rsa-converter
cd rsa-converter
apt install libcrypt-openssl-bignum-perl libcrypt-openssl-rsa-perl libparse-recdescent-perl -y
./rsa-converter -p /etc/ipsec.d/rsa/utm.pub > /etc/ipsec.d/rsa/utm.pub.pem
cd /etc/ipsec.d/rsa/
openssl rsa -pubin -inform PEM -in utm.pub.pem -outform DER -out utm.pub.der
Da in der UTM später der öffentliche RSA-Schlüssel des V-Servers hinterlegt werden muss, kann diese mit folgendem Befehl in das benötigte Format umgewandelt werden.
/tmp/rsa-converter/rsa-converter -r < /etc/ipsec.d/rsa/public.pem > /etc/ipsec.d/rsa/publickeyforutm
Nun kann die Strongswan-Konfigurationsdatei /etc/ipsec.conf bearbeitet und entsprechend der eigenen Gegebenheiten angepasst werden. Mindestens die Einträge für VPN-ID und IP-Adresse müssen individuell gesetzt werden.
nano /etc/ipsec.conf
# ipsec.conf - strongSwan IPsec configuration file # basic configuration config setup # strictcrlpolicy=yes uniqueids = yes # Add connections here. conn %default ikelifetime=7800 keylife=3600 rekeymargin=3m keyingtries=1 keyexchange=ikev1 # mobike=no # fragmentation=yes conn net-net # oeffentliche IP dieses Servers left=2a03:3333:3333:cccc::1 # Subnetz hinter diesem Server leftsubnet=10.0.0.0/24 # VPN-ID dieses Servers leftid=@vpshostname.tobaste.de leftsigkey=/etc/ipsec.d/rsa/public.der leftauth=pubkey leftfirewall=yes # oeffentliche IP der UTM right=2a02:2222:2222:bbbb::1 # Subnetz hinter der UTM rightsubnet=10.1.0.0/24 # VPN-ID der UTM rightid=@utmhostname.tobaste.de rightsigkey=/etc/ipsec.d/rsa/utm.pub.der rightauth=pubkey auto=add ike=aes128-sha256-modp2048! esp=aes128gcm16-sha256-modp2048! dpdaction=restart include /var/lib/strongswan/ipsec.conf.inc
Jetzt muss der Pfad zum privaten Schlüssel in der Secrets-Datei hinterlegt werden:
nano /etc/ipsec.secrets
# This file holds shared secrets or RSA private keys for authentication. # RSA private key for this host, authenticating it to any other host # hich knows the public part. # this file is managed with debconf and will contain the automatically created private key include /var/lib/strongswan/ipsec.secrets.inc : RSA /etc/ipsec.d/rsa/privkey.der.key
In der Datei /etc/sysctl.conf wird das IP-Paketforwarding aktiviert, indem die Raute vor den entsprechenden Einträgen entfernt wird:
nano /etc/sysctl.conf
# Uncomment the next line to enable packet forwarding for IPv4 net.ipv4.ip_forward=1 # Uncomment the next line to enable packet forwarding for IPv6 # Enabling this option disables Stateless Address Autoconfiguration # based on Router Advertisements for this host net.ipv6.conf.all.forwarding=1
In der Netzwerkkonfiguration wird eine virtuelle Schnittstelle mit dem oben definierten Subnetz angelegt:
nano /etc/network/interfaces
# This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). source /etc/network/interfaces.d/* # The loopback network interface auto lo iface lo inet loopback # The primary network interface allow-hotplug ens3 # öffentliche IPv4 des V-Servers iface ens3 inet static address 94.111.222.111 netmask 255.255.252.0 gateway 94.11.222.1 # öffentliche IPv6 des V-Servers iface ens3 inet6 static address 2a03:3333:3333:cccc::1 netmask 64 gateway fe80::1 auto vpn0 iface vpn0 inet manual pre-up /sbin/ip link add vpn0 type dummy up /sbin/ip link set vpn0 address 12:34:56:ff:ff:ff up ip addr add 10.0.0.1/24 dev vpn0 # static route
Der Server sollte nun einmal neugestartet werden.
UTM-Konfiguration
Die weitere Konfiguration kann ebenfalls sehr individuell erfolgen. Ich habe mich für die Nutzung eines VLANs auf dem LAN-Interface entschieden:
In der Firewall müssen nun nur noch drei Punkte konfiguriert werden: Die Richtlinie, das Gateway und die eigentliche Verbindung.
Zuerst wird eine neue Richtlinie angelegt, die Parameter sollten den in Strongswan konfigurierten Werten entsprechen.
Bei der Erstellung des Gateways muss darauf geachtet werden, dass die UTM die Verbindung initiiert. Zudem müssen – wenn nicht bereits vorhanden – neue Netzwerkdefinitionen für das VPS-Subnet und die öffentliche IP-Adresse des V-Servers erstellt werden. Der RSA-Key kann aus der Datei „publickeyforutm“ ausgelesen werden:
nano /etc/ipsec.d/rsa/publickeyforutm
Jetzt kann die eigentliche Verbindung konfiguriert und aktiviert werden:
Wenn die Verbindung erfolgreich hergestellt werden konnte, sieht das Ganze dann wie folgt aus:
Damit die Kommunikation zwischen den Netzen erfolgen kann, muss die Maskierung entsprechend konfiguriert werden. Da sich mein Server in der DMZ befindet, muss diese oben ausgewählt werden.
Zudem muss eine DNAT-Regel für die gewünschten Dienste erstellt werden. Für Teamspeak sind hier die Ports 9987, 30033 und 10011 erforderlich. Falls noch nicht geschehen, muss zudem eine „Host“-Definition für den Zielserver mit dessen interner IP-Adresse erzeugt werden (hier „TS3“).
Die UTM ist nun vollständig konfiguriert und einsatzbereit. Bislang weiß der V-Server jedoch noch nicht, wie er mit eingehendem Datenverkehr auf den oben genannten Ports verfahren soll. Mithilfe des Programms „iptables“ müssen daher noch Regeln für den Umgang mit den Paketen definiert werden. Auch hier ist nämlich ein NAT erforderlich.
Parameter | Erläuterung | Beispiel |
-t / –table | Gibt den Namen der Tabelle an, standardmäßig ist die Tabelle „filter“ vorgegeben. | -t nat |
-A / –append | Fügt eine neue Regel am Ende einer Tabelle ein. | -A |
-p / –protocol | Definiert das verwendete IP-Protokoll, hängt von dem Serverdienst ab. | -p udp |
–dport | Gibt den Zielport an. | –dport 9987 |
-i bzw. -o / –in-interface bzw. –out-inteface | Gibt die Schnittstelle für das Eingangs-/Ausgangsnetzwerk an. | -i ens3 |
-j / –jump | Gibt an, was mit dem Paket getan werden soll. Möglich sind z.B. „ACCEPT“, „DROP“, „DNAT“, „SNAT“, … | -j SNAT |
–to-destination bzw. –to-source | Ändert die Ziel-, bzw. Quell-IP-Adresse im IP-Header | –to-destination 10.1.0.1 |
Bezogen auf das Beispiel Teamspeak-Server sieht die Liste der auszuführenden Befehle wie folgt aus:
iptables -t nat -A POSTROUTING -p udp --dport 9987 -o ens3 -j SNAT --to-source 10.0.0.1
iptables -t nat -A PREROUTING -p udp --dport 9987 -i ens3 -j DNAT --to-destination 10.1.0.1
iptables -t nat -A POSTROUTING -p tcp --dport 10011 -o ens3 -j SNAT --to-source 10.0.0.1
iptables -t nat -A PREROUTING -p tcp --dport 10011 -i ens3 -j DNAT --to-destination 10.1.0.1
iptables -t nat -A POSTROUTING -p tcp --dport 30033 -o ens3 -j SNAT --to-source 10.0.0.1
iptables -t nat -A PREROUTING -p tcp --dport 30033 -i ens3 -j DNAT --to-destination 10.1.0.1
Damit die neuen Regeln dauerhaft gespeichert werden, sollten diese mittels iptables-save gespeichert werden, um sie automatisch mit dem Paket iptables-persistent laden zu können:
apt install iptables-persistent
iptables-save > /etc/iptables/rules.v4
Nach einem Neustart sollten die Regeln weiterhin aufgeführt werden. Eine Ausgabe der aktuellen Regeln erhält man mittels…
iptables -L
Nun sollte auch das Verbinden mit dem gewünschten Server möglich sein.