Hilfreich? 5
-
Ja (5) 100%
-
Nein (0) 0%
-
Zu kompliziert (0) 0%
Einleitung
Da es immer wieder Thema ist, möchte ich hier die Chance nutzen, Möglichkeiten aufzuzeigen, wie eine Erreichbarkeit via IPv4 erreicht werden kann, wenn man bei einem Provider ist, der einem keinen vollwertigen IPv4-Zugang mehr anbietet, sondern Techniken wie CG-NAT oder DS-Lite nutzt.
Hintergrund
Im ersten Beispiel greife ich eine Konfiguration auf, wie sie zuletzt diskutiert wurde. Dabei geht es darum, das Heimnetzwerk mithilfe eines VPS für IPv4-Clients verfügbar zu machen. Die Brücke zwischen den Welten bildet ein Netzwerk auf Basis von WireGuard. Wobei auch andere VPN-Lösungen grundsätzlich sehr ähnlich funktionieren.
Andere Möglichkeiten werde ich in einem anderen Beitrag aufzeigen. Natürlich ist jeder gerne eingeladen, selbst was beizusteuern. 
Es wäre schön, wenn hier im Thema nicht geantwortet würde, wenn etwas unklar sein sollte oder andere Ideen einfließen sollen. Zwecks Übersichtlichkeit bitte dann einen weiteren Thread aufmachen.
Übersichtszeichnung
Ein Bild sagt mehr als tausend Worte, daher erstmal eine Übersicht, was erreicht werden soll.
Komponenten der Lösung
Zu sehen ist also ein Heimnetzwerk (LAN) hinter einem Router, oftmals eine FritzBox. Diese hat einen eingeschränkten Zugang zum Internet, ist also nicht öffentlich erreichbar, sondern kann nur selbst Verbindungen zu Zielen aufbauen.
In diesem Heimnetzwerk kommt zum Beispiel ein Raspberry Pi als Hilfe zum Einsatz. Diese Aufgabe kann auch die FritzBox selbst übernehmen. Diese Abwandlung werde ich zu einem anderen Zeitpunkt ergänzen.
Darüber hinaus gibt es ein NAS, auf das ich zugreifen will, wenn ich nicht im Heimnetzwerk bin. Das können natürlich noch viele weitere andere Geräte zu Hause sein.
Um die Erreichbarkeit zu implementieren, reicht ein sehr einfacher Linux-Server im Internet. Da gibt es viele Angebote bei sehr vielen Providern.
Als Beispiel führe ich Strato mit günstigen Angeboten an: https://www.strato.de/server/linux-vserver/mini-vserver/
Für diese Aufgabe reicht ein VC1-1, den es für 1€/Monat gibt. Bei den Angeboten darauf achten, dass der Server eine öffentliche IPv4-Adresse erhält. Es gibt auch IPv6-only-Angebote. In diesem Beispiel bietet Strato mittlerweile beides: IPv4/IPv6
Um die Komponenten untereinander zu koppeln, kommt eine Tunneltechnik zum Einsatz. Hier konkret geht es um WireGuard (https://www.wireguard.com/).
Der Raspberry Pi dient hier als Router zwischen den Teilnehmern in dem Transportnetz und dem LAN. Der VPS übernimmt die Aufgabe, sowohl den Raspberry Pi als auch externe Clients (zum Beispiel ein Smartphone in einem mobilen Netz) an das Transportnetz zu koppeln, denn dieser ist eingehend für alle Beteiligten erreichbar.
Die Kommunikation in das Heimnetz kann dann auf die Adressen im LAN erfolgen. Das fabelhafte NAS, was man unterwegs erreichen möchte, ist für den mobilen WireGuard-Client also wie gewohnt unter 192.168.178.110 erreichbar. Natürlich kann die Konfiguration auch mit dem lokalen DNS der FritzBox oder jedem anderen DNS im LAN funktionieren, sodass man sich keine IP-Adressen merken muss.
Konfiguration
VPS
Der Dreh- und Angelpunkt ist der VPS, zu dem sich alle verbinden. Der Raspberry Pi aus dem Heimnetz und externe Clients.
Wenn der Provider eine externe Firewall anbietet, gilt es diese eingehend auf UDP auf den festzulegenden Port freizuschalten, in diesem Beispiel ist dies die 52823.
Um die Erreichbarkeit zu vereinfachen, legen wir bei einem geeigneten Service einen DNS-Eintrag an:
vps.meinefabelhaftedomain.de mit der öffentliche Adresse, im fiktiven Beispiel 80.90.100.110.
Benötigt werden zudem die WireGuard-Tools. Das Paket installiert auch die Abhängigkeiten, z.B. via
sudo apt install wireguard-tools
cd /etc/wireguardJetzt gilt es, Keys für alle Beteiligten zu erzeugen:
wg genkey|tee key_vps|wg pubkey >key_vps.pub
wg genkey|tee key_rpi|wg pubkey >key_rpi.pub
wg genkey|tee key_cl1|wg pubkey >key_cl1.pubDie Konfiguration könnte dann so aussehen:
[Interface]
PrivateKey = <key_vps>
Address = 10.99.99.1/24
ListenPort = 52823
[Peer]
PublicKey = <key_rpi.pub>
AllowedIPs = 10.99.99.2/32,192.168.178.0/24
PersistentKeepalive = 25
[Peer]
PublicKey = <key_cl1.pub>
AllowedIPs = 10.99.99.3/32
PersistentKeepalive = 25Hier wird zunächst festgelegt, auf welche IP-Adresse das lokale Interface antworten soll.
Dann werden zwei Peers berechtigt: Der Raspberry Pi und exemplarisch ein Client. Die Keys entsprechend einsetzen.
Der Punkt "AllowedIPs" legt fest, für welche IPs welcher Peer verantwortlich ist. Hier ist es ausreichend, den Host-Anteil selbst "/32" zu definieren. Der Peer am Raspberry Pi übernimmt noch zusätzlich das Heimnetz.
Da ich selbst kein Fan davon bin, die iptables-Regeln via WireGuard zu steuern, nutze ich den Mechanismus, der sich um alle Regeln kümmert.
Wir legen einmalig die Regeln an und speichern diese:
sudo iptables --policy FORWARD DROP
sudo iptables -A FORWARD -i wg0 -o wg0 -j ACCEPT
sudo apt install iptables-persistent
sudo iptables-save >/etc/iptables/rules.v4Der letzte Schritt ist nur notwendig, falls ihr verneint habt, die aktuellen Regeln zu speichern.
Damit verhindern wir jeden FORWARD, außer von wg0 zu wg0, und das wollen wir ja.
Damit der IP-Stack überhaupt Pakete weiterleitet, muss dies aktiviert werden:
sudo echo "net.ipv4.ip_forward=1" >/etc/sysctl.d/50-forwarding.confIm letzten Schritt sorgen wir für den Autostart der Interfaces:
sudo systemctl enable wg-quick@wg0Dann ruhig mal neustarten, damit sowohl Regeln als auch Interface funktionieren.
sudo iptables -L -v
[...]
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- wg0 wg0 anywhere anywhere
[...]
sudo systemctl status wg-quick@wg0.service
● wg-quick@wg0.service - WireGuard via wg-quick(8) for wg0
Loaded: loaded (/lib/systemd/system/wg-quick@.service; enabled; vendor preset: enabled)
Active: active (exited) since Sat 2023-10-28 16:01:48 UTC; 8min agoHier sind wir fertig.
Raspberry Pi
Weiter geht es auf dem Raspberry Pi, der sich zum VPS verbinden soll.
Die Voraussetzungen sind identisch, ich zeige direkt die Konfiguration des WireGuard-Interfaces:
[Interface]
Address = 10.99.99.2/24
PrivateKey = <key_rpi>
[Peer]
PublicKey = <key_vps.pub>
Endpoint = vps.meinefabelhaftedomain.de:52823
AllowedIPs = 10.99.99.0/24
PersistentKeepalive = 25Wir können uns sparen, einen ListenPort zu setzen, der wird automatisch gewürfelt. Da wir hierhin nicht verbinden, benötigen wir das aber nicht.
"AllowedIPs" wird pauschal auf 10.99.99.0/24 gesetzt, sodass der VPS aber auch die Kommunikation zu den Clients möglich wird.
Die Regeln für iptables sehen etwas anders aus:
sudo iptables --policy FORWARD DROP
sudo iptables -A FORWARD -o wg0 -i eth0 -j ACCEPT
sudo iptables -A FORWARD -i wg0 -o eth0 -j ACCEPT
sudo apt install iptables-persistent
sudo iptables-save >/etc/iptables/rules.v4Hier geht es darum, dass von und nach wg0 Pakete weitergeleitet werden dürfen. Damit sind Ziele im Heimnetz erreichbar.
Im letzten Schritt sorgen wir für den Autostart der Interfaces:
sudo systemctl enable wg-quick@wg0Auch der Raspberry Pi muss Pakete weiterleiten können:
sudo echo "net.ipv4.ip_forward=1" >/etc/sysctl.d/50-forwarding.confDann ruhig mal neustarten, damit sowohl Regeln als auch Interface funktionieren.
Danach sollte wir sehen, dass die Kommunikation zum VPS bereits funktioniert:
sudo wg show wg0
interface: wg0
public key: <key_rpi.pub>
private key: (hidden)
listening port: 41657
peer: <key_vps.pub>
endpoint: <IPVPS>:52823
allowed ips: 10.99.99.0/24
latest handshake: 1 minute, 2 seconds ago
transfer: 468 B received, 764 B sent
persistent keepalive: every 25 seconds
ping -c 2 10.99.99.1
PING 10.99.99.1 (10.99.99.1) 56(84) bytes of data.
64 bytes from 10.99.99.1: icmp_seq=1 ttl=64 time=9.59 ms
64 bytes from 10.99.99.1: icmp_seq=2 ttl=64 time=9.61 ms
--- 10.99.99.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 9.586/9.595/9.605/0.009 msSieht soweit gut aus.
Client 1
Nun geht es an einen Client. Das hängt jetzt stark vom Betriebssystem ab, der Android-Client kann eine Config importieren. Das wird vermutlich sonst auch so sein.
Hier ist die Konfiguration recht einfach:
[Interface]
PrivateKey = <key_cl1>
Address = 10.99.99.3/24
[Peer]
PublicKey = <key_vps.pub>
AllowedIPs = 10.99.99.0/24,192.168.178.0/24
Endpoint = vps.meinefabelhaftedomain.de:52823
PersistentKeepalive = 25Router/FritzBox
Damit auch andere Systeme im Heimnetz, z.B. das fabelhafte NAS, seinen Weg zurück zum Client findet, muss der Router darüber Bescheid wissen.
Wenn jetzt alles korrekt ist, sollte der Client alles korrekt pingen können:
ping -c 2 10.99.99.1
PING 10.99.99.1 (10.99.99.1) 56(84) bytes of data.
64 bytes from 10.99.99.1: icmp_seq=1 ttl=64 time=1.48 ms
64 bytes from 10.99.99.1: icmp_seq=2 ttl=64 time=1.36 ms
--- 10.99.99.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 1.363/1.421/1.480/0.058 ms
ping -c 2 10.99.99.2
PING 10.99.99.2 (10.99.99.2) 56(84) bytes of data.
64 bytes from 10.99.99.2: icmp_seq=1 ttl=63 time=12.0 ms
64 bytes from 10.99.99.2: icmp_seq=2 ttl=63 time=10.9 ms
--- 10.99.99.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 10.949/11.461/11.974/0.512 ms
ping -c 2 192.168.178.110
PING 192.168.178.110 (192.168.178.110) 56(84) bytes of data.
64 bytes from 192.168.178.110: icmp_seq=1 ttl=61 time=13.6 ms
64 bytes from 192.168.178.110: icmp_seq=2 ttl=61 time=11.3 ms
--- 192.168.178.110 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 11.287/12.434/13.581/1.147 ms