Einleitung
Heutzutage gibt es eine Vielzahl von Geräten (Synology NAS, QNAP NAS, Asustor NAS, Raspberry Pi, usw.), ebenso wie unzählige Apps (z.B. HomeAssistant, Nextcloud, Gitea, Baikal, usw.), welche man Zuhause selber betreiben/hosten kann und auf welche man teilweise auch gerne von extern zugreifen würde (ggf. sogar über einen Reverse-Proxy). Leider ist das in der heutigen Zeit bei vielen privaten Internetanschlüssen durch die Vorgabe von IPv6 nicht mehr so einfach. Zwar kann man von einem externen Anschluss mit IPv6-Unterstützung problemlos auf Dinge Zuhause zugreifen, bekommt man allerdings am externen Standort lediglich eine IPv4-Adresse, ist der Zugriff auf die Dienste Zuhause nicht mehr ohne weiteres möglich.
Durch die Modernisierung vieler Anschlüsse, ist mittlerweile häufig der Umstand gegeben, dass diese primär nur noch IPv6 einsetzen und die IPv4-Konnektivität zu externen Zielen über ein sogenanntes CGN (Carrier-Grade-NAT) bereitgestellt wird (z.B. bei DS-Lite). Man kann somit "ausgehend" zwar mit IPv4-Zielen sprechen, eingehend funktioniert die Verbindung via IPv4 aber nicht mehr. Man bemerkt recht schnell den Nachteil, wenn man versucht von extern auf seinen Anschluss (z.B. über eine DynDNS-Adresse) zuzugreifen, aber keine Verbindung zustande kommt, da man ggf. von einer IPv4-Adresse versucht, auf seine IPv6-Adresse zuzugreifen.
Oftmals sind es ja durchaus Geräte/Dienste, welche man gerne von extern erreichbar machen möchte - trotz reinem IPv6-Anschluss, wie z.B. das Synology-NAS Zuhause, HomeAssistant zwecks Smarthome-Steuerung, oder einfach nur eine Nextcloud.
Diese Anleitung soll euch zeigen, wie ihr - trotz IPv6-Anschluss - dennoch mit kleinem finanziellen Aufwand eure heimischen Geräte via IPv4 ansprechen könnt. Auf irgendwelche Dienste (Portmapper, etc.) wird hier ganz bewusst verzichtet und ihr habt das komplette Szenario selbst in der Hand.
Anleitung
Im Prinzip geht es darum, dass wir die Verbindung über einen zusätzlichen Mittelsmann (angemieteter vServer) leiten. Dieser reicht die Verbindung einfach nur durch, die SSL-Terminierung erfolgt weiterhin auf dem Zielhost. Das kann man sich dann so vorstellen:
Client <--IPv4+IPv6--> vServer <--IPv6--> Server
Wir benötigen einen externen Server (angebunden mit IPv4 + IPv6 (Dualstack)), z.B. ein angemieteter vServer (in unserem Fall ein Debian 12). Dieser darf keinerlei Software in Bezug auf unsere benötigten Ports enthalten (wenn wir die Web-Ports weiterleiten wollen, darf z.B. kein "Plesk" o.ä. Hosting-Software installiert sein). Im Grunde reicht ein kleiner vServer mit einem einfachen vorinstalliertem Linux. Alle weiteren Schritte beziehen sich auf den vServer und sind entsprechend auf diesem auszuführen.
Wir melden uns am vServer via SSH an und überprüfen zunächst, ob wir auch wirklich via Dualstack (IPv4+IPv6) angebunden sind. Dazu geben wir folgenden Befehl ein:
ip a
Die Ausgabe sollte ungefähr wie folgt aussehen:
Wichtig sind hierbei die IP-Adresse direkt hinter "inet" (öffentliche IPv4 (1)) und die IP-Adresse hinter der ersten Zeile "inet6" (öffentliche IPv6 (2)). Sind diese vorhanden, kann man mit der Installation beginnen.
Zunächst einmal wird das System auf den neusten Stand gebracht mittels:
apt update && apt upgrade -y
Ist das System up2date, kann das benötigte Paket "6tunnel" installiert werden:
apt install 6tunnel
Nach erfolgreicher Installation (und vorheriger Installation der Updates) starten wir das System einmal neu:
reboot
Nach erfolgtem Neustart des vServers und erneuter Anmeldung ist es nun an der Zeit, die Ports und Adresse zur Weiterleitung unserer Pakete zu bestimmen. Dies geschieht in recht einfacher Form über den 6tunnel-Befehl. Die Einrichtung der Weiterleitungen gestaltet sich wie folgt:
6tunnel {Port vServer} {Ziel-Adresse} {Port Ziel}
In unserem Beispiel beziehen wir uns dabei auf eine fiktive DynDNS-Adresse, hier müsst ihr natürlich eure eigene DynDNS-Adresse eintragen, ebenso wie die gewünschten weiterzuleitenden Ports. Wir beschränken uns hier auf die Ports 80 (http) und 443 (https), aber das könnt ihr natürlich nach Wunsch selber definieren. Praktisch wäre es dann wie folgt umzusetzen.
6tunnel 80 meinedynamischeadresse.dyndns-anbieter.de 80
6tunnel 443 meinedynamischeadresse.dyndns-anbieter.de 443
Eine Rückmeldung (positiv/negativ) gibt es nicht, aber man kann schauen, ob die entsprechenden Prozesse wie gewünscht laufen:
ps aux | grep 6tunnel | grep -v grep
Solltet ihr euch verschrieben haben, könnt ihr die gesamten 6tunnel-Prozesse auch alle beenden über den Befehl:
killall 6tunnel
Einzelne Prozesse könnt ihr über die PID (Prozess-ID) beenden, in Bezug auf den Screenshot z.B. um den Prozess mit der Portangabe 80 zu beenden:
kill 419
Ebenso könnt ihr nochmal die Ports überprüfen, an welchen 6tunnel lauscht (auch wenn es aus der o.g. Ansicht schon ersichtlich ist) mittels folgendem Befehl:
ss -tlpn | grep 6tunnel
Wenn alles wie gewünscht konfiguriert ist, könnt ihr über die IPv4-Adresse eures vServers auf eure heimische IPv6-Adresse zugreifen.
Es wäre noch erwähnenswert, dass ihr die Ports nur einmal weiterleiten könnt. Insofern könnt ihr mit einem bestimmten Port (z.B. 443 - https) auch nur eine bestimmte Adresse ansprechen. Habt ihr einen Reverse-Proxy im Einsatz, wäre es am sinnvollsten, wenn die Weiterleitung vom vServer auf diesen zeigt, da ihr von dort aus dann alles weitere konfigurieren könnt.
DNS
Beim Einsatz von DynDNS wäre es wichtig zu beachten, dass die angesproche DynDNS-Adresse auch "wirklich" auf euren gewünschten Zielhost zeigt (z.B. Reverse-Proxy, HomeAssistant, etc. und nicht einfach nur den Router). Bei IPv6 und myfritz wäre es z.B. entsprechend "hostname.meinemyfritzadresse.myfritz.net".
Habt ihr dazu noch eine eigene Domain (example.com), wäre es sinnvoll, wenn ihr eure gewünschten DNS-Records (v4/v6) bzgl. example.com auf die Adressen des vServers legt (ggf. sogar ein Wildcard-DNS-Record auf ggf. eine Subdomain, z.B. "*.home.example.com"). Da der vServer nun sowieso alles in Bezug auf die Ports 80/443 an eure DynDNS-Adresse weiterleitet, gilt das auch für die example.com-Anfragen, welche auf den vServer zeigen. Am anderen Ende - also bei euch Zuhause - könnt ihr die Anfragen bzgl. der Domain example.com dann entsprechend weiterverarbeiten, z.B. über einen Reverse-Proxy, welcher die unterschiedlichen Anfragen an eure diversen virtuellen Hosts (z.B. homeassistant.home.example.com, nextcloud.home.example.com, etc.) dann an die jeweiligen Stellen in eurem Heimnetzwerk verteilt.
P.S.: Entstanden ist diese Anleitung aufgrund der Problematik, dass man in HomeAssistant die Alexa-Integration nicht nutzen konnte, da Amazon die HomeAssistant-Installation unter einer IPv4-Adresse ansprechen möchte. Mithilfe dieses Workarounds hat es dann schlussendlich funktioniert. Auf anderweitige extern anmietbare Dienste wurde hierbei verzichtet (IP-Tunnel, Portmapper, etc.), so dass man alles selbst in der Hand hat und den angemieteten vServer ggf. auch noch für anderweitige Dinge nutzen kann.
---
Vielen Dank an den User blurrrr für diese Anleitung!