Einleitung
Die Erreichbarkeit seines Heimnetzes via IPv4 zu ermöglichen, ist für viele keine Neuigkeit und in vielen Variationen gelebte Praxis.
Da es aber immer wahrscheinlicher wird, dass der ISP nur noch eingeschränkte Konnektivität zum IPv4-Teil des Internets anbietet, drängt sich die Frage nach Lösungen auf.
Hier möchte ich einen Lösungsansatz zeigen, wie man einzelne Systeme (Server, NAS oder andere Arten von Appliances) im Heimnetz von außen via IPv6 erreichbar macht.
DynDNS
Da man als Privatperson in der Regel keine feste IP-Adresse bekommt, sondern diese dynamisch durch den ISP zugewiesen werden, besteht auch bei IPv6 die Notwendigkeit, den eigenen Server unter einem klar definierten Namen erreichbar zu machen.
Im Unterschied zu IPv4 ist es bei IPv6 aber so, dass nicht der Router (z.B. die Fritzbox) die einzige öffentliche Adresse hält, sondern jedes Gerät dahinter über eine eigene öffentliche IPv6-Adresse verfügt. Der bisherige Ansatz, dass der Router die öffentliche IP-Adresse bei einem DynDNS-Service registriert und die eingehenden Verbindungen an ein Ziel weiterleitet (via DNAT und PNAT), ist unter IPv6 nicht nötig.
In dem Beispiel nutze ich den Service von deSEC (https://desec.io). Dort kann ich nach Belieben Zonen einrichten und habe den weiteren Vorteil, dass Certbot ein natives Plugin dafür bereitstellt. Das wird gebraucht, um sich automatisiert Let's-Encrypt-Zertifikate ausstellen zu lassen. Das hat aber nur indirekt mit dem Thema zu tun und zeigt die Bandbreite der Möglichkeiten.
Sollte diese Domain zum Beispiel bei Strato gehostet sein, kann man dort die Delegation vornehmen, indem man die DNS-Server von deSEC setzt:
Das geht natürlich auch mit vielen anderen Anbietern.
DynDNS-Client
Jedes System muss sich selbst beim Service registrieren und seine öffentliche Adresse pflegen.
Linux-Systeme bieten dazu mehrere Möglichkeiten, ich gehe auf "ddclient" als Paket unter Ubuntu ein, das auf einem Raspberry Pi 4 läuft. Nennen wir ihn "rpi4".
Damit der Client berechtigt ist, Updates vorzunehmen, wird ein Acccess Token bei deSEC erstellt:
Jetzt wird der Client konfiguriert (Datei ist /etc/ddclient.conf):
protocol=dyndns2
# "use=cmd" and the curl command is one way of doing this; other ways exist
usev6=if, if=eth0
#use=cmd, cmd='curl https://checkipv6.dedyn.io/'
ssl=yes
server=update6.dedyn.io
login=rpi4.meinefabelhaftedomain.de
password='bxt8RkoBN7v4gqv8pF9QtTqFzxWB'
rpi4.meinefabelhaftedomain.deMan kann die Adresse am Interface auslesen lassen oder eine Erkennung über ein Kommando realisieren. In dem Beispiel wird die Adresse am Interface eth0 ausgelesen.
Nun den Dienst aktivieren und kontrollieren:
systemctl enable ddclient.service
Synchronizing state of ddclient.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable ddclient
Crea
ted symlink /etc/systemd/system/multi-user.target.wants/ddclient.service → /lib/systemd/system/ddclient.service.
systemctl status ddclient.service
● ddclient.service - Update dynamic domain name service entries
Loaded: loaded (/lib/systemd/system/ddclient.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2024-06-30 11:36:19 CEST; 12min ago
Docs: man:ddclient(8)
Process: 741097 ExecStart=/usr/sbin/ddclient -daemon $daemon_interval -syslog -pid /run/ddclient.pid (code=exited, status=0/SUCCESS)
Main PID: 741184 (ddclient - slee)
Tasks: 1 (limit: 2033)
Memory: 14.7M
CPU: 571ms
CGroup: /system.slice/ddclient.service
└─741184 "ddclient - sleeping for 180 seconds"
Jun 30 11:36:19 pi4 systemd[1]: Started Update dynamic domain name service entries.Im Laufe der Zeit sollte die Adresse beim Service und allen anderen DNS-Servern ein Update erhalten haben:
nslookup rpi4.meinefabelhaftedomain.de ns1.desec.io
Server: ns1.desec.io
Address: 2607:f740:e633:deec::2#53
Name: rpi4.meinefabelhaftedomain.de
Address: 2003:a1:b1:c1:d1:e1:f1:1234
nslookup rpi4.meinefabelhaftedomain.de 1.1.1.1
Server: 1.1.1.1
Address: 1.1.1.1#53
Non-authoritative answer:
Name: rpi4.meinefabelhaftedomain.de
Address: 2003:a1:b1:c1:d1:e1:f1:1234Firewall-Konfiguration
Der Router sollte in der Regel das delegierte IPv6-Prefix hinter einer Firewall schützen. Ich lasse die Firewall am System (rpi4 auf Ubuntu) hier außen vor, da es zu viele Variationen gibt.
Damit es nicht immer nur um Fritzboxen geht, hier ein Beispiel, wie eingehender Traffic zu Port 443 auf einem OpenWRT-Router akzeptiert wird:
Das Ziel, der rpi4, wird hier nur mit einem Host-Anteil und einem Prefix-Hinweis angelegt. Bei wechselnden Prefixes kann die OpenWRT-Firewall auch in Zukunft sicher feststellen, welches Ziel gemeint ist, auch wenn das Prefix sich geändert hat.
Ähnlich wird es auf einer Fritzbox gemacht. Wichtig zu verstehen ist, dass dabei weiter DNAT noch PNAT eine Rolle spielen.
Und so würde man "von außen" sehen, dass die Verbindung in Ordnung ist:
nc -v rpi4.meinefabelhaftedomain.de 443
Ncat: Version 7.95 ( https://nmap.org/ncat )
Ncat: Connected to [2003:a1:b1:c1:d1:e1:f1:1234]:443.