HowTo: DynDNS mit Starlink, IPv6 oder 5G – Immer erreichbar mit Synology trotz CGNAT
Deutschland ist ja bekanntlich #neuland, wenn es um Erschließung mit ordentlichem Internet geht. Mein Vodafone Kabel ist seit einem halben Jahr so unzuverlässig, dass ich mir einen Starlink Failover einrichten musste, damit Home Office noch geht.
Jeder, der voller Enthusiasmus die Starlink Antenne ans Haus schraubt um dann einen externen Zugriff in sein lokales Netz herzustellen, sei es um Seiten wie diesen Blog lokal zu hosten oder um von Extern auf Heimnetz Tools zu kommen, steht aber vor dem Problem, dass das nicht so einfach ist, da die üblichen DynDNS (DDNS) Varianten nicht funktionieren. Dasselbe Problem hat man bei vielen anderen Providern mit IPv6 & CGNAT.
In diesem HowTo richten wir mit unserer Synology einen kostenlosen externen Zugriff (via Cloudflare Tunnel) auf lokal laufende Dienste ein, der in allen Setups und Umgebungen läuft.
Konkret werden wir:
- (Als kleiner Exkurs) kurz in die Gründe schauen, warum es eigentlich nicht geht und die funktionierende Lösung vorstellen.
- Cloudflare als DNS für unsere Domains einrichten
- Einen Cloudflare Tunnel in unser Heimnetz mit Hilfe von Docker und unserer Synology einrichten
- Mehrere lokal laufende Dienste extern verfügbar machen
- Abschließend: Kurz die Vor- und Nachteile von Cloudflare anschauen und Alternativen diskutieren.
Vorbedingungen:
- Ihr braucht eine eigene Domain.
- Ihr braucht eine Synology, die Virtualisierung beherrscht.
- Ihr müsst natürlich wissen, dass ihr einen internen Service so extern verfügbar macht mit allen Vor- und Nachteilen. Stichwort Sicherheit.
Kleiner Exkurs – Warum geht normales DynDNS nicht?
(Optional zum Lesen. Ungeduldige können die Sektion überspringen.) Der alte Standard Weg für die meisten Internetprovider heutzutage ist, dass man eine IPv4 bekommt, einen beliebigen DynDNS Dienst nutzt, in sein lokales Setup einbaut, eine Port-Weiterleitung im Router anlegt und so interne Dienste von außen verfügbar machen kann.
Mehr oder weniger kostenlose Dienste wie Synology DDNS, no-ip.com oder ipv64.net können heutzutage direkt auf den NAS, oder auch im Router wie Fritz Box oder UniFi problemlos eingerichtet werden.
In zwei Szenarien funktioniert das aber nicht so gut:
- Wenn der Internet Service Provider einem nur eine IPv6 Verbindung zur Verfügung stellt,
- oder, wenn der ISP so genanntes CGNAT verwendet.
Beispielsweise Starlink oder auch 5G Systeme wie das von der Telekom verwenden sog. CGNAT (Carrier-grade NAT). CGNAT, bedeutet zuerst mal, dass man eine IPv4 bekommt, die man auch im Router sieht und auf die man über die eigene Starlink Verbindung auch wunderbar zugreifen kann. Dann denkt man erstmal, „klappt ja alles…“. Leider ist die IP, die man im Router sieht, nicht die tatsächliche externe IP, die man auf Seiten wie whatismyipaddress.com sieht. Die tatsächliche externe IP, die Starlink verwendet teilt man sich mit anderen Kunden im Starlink Netz. Starlink regelt intern, wie die externe Starlink IP zur internen Starlink IP (die man im Router sieht) weiterleitet.
Keine der beiden IPs wird im Zugriff von einem externen Netz auf euch aufgelöst werden können. Heißt auch, dass DynDNS nicht funktionieren wird, egal welche der IPs ihr beim DynDNS Service eintragt.
TL;DR Man kann sich das so vorstellen, dass der ISP einen eigenen Router wie eure Fritz Box zwischen euch und dem Internet hat. Dieser Router versorgt viele Kunden über eine einzige externe IP. Ihr selbst habt keine Möglichkeit diesen Router zu beeinflussen und bspw. ein Port-Forwarding auf euch dort einzurichten.
Tunnels to the Rescue. Falls ihr euch je gefragt habt, wie einzelne Apps von Drittanbietern, wie bspw. Ubiquiti es schaffen, euch Zugriff auf euer lokales Netz zu geben, obwohl ihr hinter entsprechenden Verbindungen sitzt, dann ist die Antwort: Durch Tunnel. In einem Tunnel erstellt ein Gerät, das bei euch im Netz läuft, eine ausgehende, persistente Datenverbindung zu einem entsprechenden Server im Internet. Dieser Server muss also nicht irgendwie rausfinden, wie er bei Bedarf Nachrichten an euch schicken kann, sondern er kann einfach die von euch aktiv am Leben gehaltene Datenverbindung nutzen. Dafür muss in eurem Netzwerk ein Service laufen, der diese Verbindung auch aktiv aufrecht erhält. Bei Ubiquiti ist das bspw euer Cloud Key oder eure UDM…
Damit wir beliebige lokale Services extern verfügbar machen können, werden wir einen Cloudflare Tunnel einrichten, der von einem lokalen Prozess auf eurer Synology aufrecht erhalten wird. Anfragen an eure Domains gehen dann zu Cloudflare und von dort durch den Tunnel zu euch lokal.
Schritt 1: Cloudflare für Deine Domain als DNS einrichten
Ein wichtiger Unterschied zu DynDNS Anbietern ist, dass wir eine eigene Domain benötigen. Hat man keine, muss man sich eine registrieren. Für die Domain, muss man dann Cloudflare als DNS Server einrichten.
Sobald ihr eine Domain habt, kann es losgehen. Geht auf cloudflare.com -> Anmelden -> Sign Up und erstellt euch einen kostenlosen Account. (Nichts was wir hier bei Cloudflare machen, kostet Stand 2025 Geld.)
Erstmal eingeloggt, kann man oben rechts auf Deutsch ändern und dann in der Konto-Startseite geht es auf Onboard a domain. Gebt eure Domain ein und lasst den Rest bei Default. Auf der nächsten Seite wählt den Free Plan. Cloudflare importiert dann erstmal eure aktuellen DNS Records.
In dem Prozess bekommt ihr zwei Cloudflare DNS Server zugewiesen, die ihr euch notieren müsst und die ihr dort, wo ihr eure Domain registriert habt als Nameserver angeben müsst.
Als Beispiel: Bei Strato geht das über Domains -> Domainverwaltung -> Zahnrad neben deiner Domain -> Tab "DNS" -> "verwalten" bei NS-Record… Dort kann man dann eben diese beiden DNS Server eintragen.
Schritt 2: Cloudflare Tunnel mit Docker auf Synology einrichten
Als nächstes konfigurieren wir den Cloudflare Tunnel.
Wichtig: Die Einstellungen für den Tunnel sind „
Konto-Einstellungen“ . Um die zu finden, müsst ihr jeweils oben links bei Cloudflare auf das Logo oder eure Mail klicken. Ihr seid richtig, wenn das Menü links mit „Konto-Startseite“ anfängt. Wollt ihr hingegen wieder zu den DNS Settings eurer Domain, müsst ihr auf eurer Konto-Startseite einmal auf eure Domain klicken. Dadurch ändert sich das linke Menü komplett. Falls ihr mal einen Menüpunkt von dem ich rede nicht findet, seid ihr vermutlich in der falschen Rubrik.
Geht nun auf eure Konto-Startseite -> Zero Trust. Das lädt das „Zero Trust Home“ (wieder mit neuem linken Menü). Dort auf Networks -> Tunnels -> Tunnel erstellen -> Cloudflared. Wählt dann einen Namen und speichert den Tunnel.
Im nächsten Schritt müssen wir jetzt den cloudflared Service bei uns im lokalen Netz installieren, damit er sich zu Cloudflare verbinden kann. Wir wollen das Ganze ja per Docker auf der Synology laufen lassen, daher wählen wir dort „Docker“ aus. Dort steht jetzt ein „Docker „docker run“ Befehl, der den entsprechenden Container ausführen würde. Lasst diesen Tab im Browser offen, den brauchen wir noch.
Um das auf der Synology zu machen, loggen wir uns in unsere Synology Web Oberfläche ein und gehen oben links auf die Anwendungen -> Docker. Wenn ihr noch kein Docker habt, müsst ihr es über das Paket-Zentrum installieren. (Achtung: Manche Synology Geräte wie ältere Geräte ohne das „+“ im Namen unterstützen keine Virtualisierung. Falls ihr so ein altes Schätzchen habt, müsst ihr ein anderes Gerät in eurem Netz, wie bspw. einen Raspberry verwenden.)
Geht im Synology Docker Fenster auf Registrierung -> sucht nach cloudflared und ladet cloudflare/cloudflared als Image herunter. Tag: lastest.
Dann auf Container -> Erstellen -> cloudflare/cloudflared:latest. Wählt für Netzwerk den Host Modus, nicht den Bridge Modus über: Dasselbe Netzwerk wie Docker Host verwenden.
Bei den Einstellungen dann:
Automatischen NeustartaktivierenErweiterte Einstellungen -> Ausführungsbefehl. Hier müssen wir jetzt den Befehl, der in der Cloudflare Oberfläche als „docker run“ Befehl gezeigt wird einmal bearbeiten. Kopiert den euch in einen Text Editor und passt ihn so an, dass ihr in den Ausführungsbefehl schreiben könnt:tunnel run --token euerToken. Alles andere kann weggelassen werden.- Speichern und im Rest überall „Weiter“ klicken und den Container starten.
Wenn ihr alles richtig gemacht habt, erscheint dann in dem Moment auch schon der verbundene Connector in dem im Browser offen gelassenen Cloudflare Tab mit der Tunnel Konfiguration. Wunderbar.
Falls es nicht klappt, stellt sicher, dass euer Befehl wirklich das „tunnel run --token ...“ format hat. Man kann diese Einstellung beim bereits erstellten Docker Container auf der Synology offenbar nicht mehr ändern. Um daran etwas anzupassen muss man den Container einmal löschen und dann die Erstellung neu machen. Keine Angst, auf dem Image gibt es keinerlei interessante Daten, die dabei verloren gehen würden.
Schritt 3: Interne Dienste extern über den Tunnel verfügbar machen
Zurück bei Cloudflare geht in den Tab mit dem Einrichtungs-Wizard, der uns die Connector Verbindung anzeigt. Klickt dort weiter und ihr werdet nach dem Tunnel Routing gefragt. Hier könnt ihr jetzt einen öffentlichen Hostname anlegen und eine Subdomain auf einen beliebigen internen Service zeigen lassen.
Habt ihr zum Beispiel eine Home Assistant Installation auf http://192.168.178.100:8123/ laufen, die ihr extern haben wollt, könnt ihr:
- Subdomain:
homeassistant - Eure Domain auswählen
- Dienst Typ:
HTTP - URL:
192.168.178.100:8123
einstellen und die Einrichtung abschließen. Herzlichen Glückwunsch, wenn ihr jetzt homeassistant.euredomain.de aufruft, sollte euer lokaler Home Assistant antworten. Das Ganze sollte jetzt auch immer klappen, egal wie ihr gerade online seid. Unabhängig vom Provider und auch Dinge, wie eine kurzzeitige Failover Verbindung oder ein Handy Hotspot oder so, wird keine Unterbrechung mehr bedeuten. Der cloudflared Service merkt, wenn die Verbindung abbricht/sich ändert und baut sie direkt wieder auf, so dass ihr kontinuierlich von außen erreichbar bleibt.
Zusätzliche Services / Subdomains hinzufügen geht über Cloudflare -> Konto-Startseite -> Zero Trust -> Networks -> Tunnels -> den Tunnel auswählen -> Bearbeiten -> Tab "Öffentliche Hostnamen" -> Öffentlichen Hostnamen hinzufügen…
Da kann man auch die Weiterleitungen bearbeiten und ggfls. wieder löschen.
Die Subdomains, die man hier anlegt erscheinen dann übrigens auch so wie sie sind in den DNS Records der verwendeten Domain.
Diskussion Vor- und Nachteile Cloudflare und Alternativen
Ich gehe hier jetzt mal nicht auf die Vor- und Nachteile ein, dass man überhaupt einen internen Service öffentlich zur Verfügung stellt, das ist ja eher eine philosophische Diskussion. Für Dinge wie Home Assistant evtl. grenzwertig, für Dinge wie diesen WordPress Blog recht kritisch, da den ja sonst niemand lesen könnte 🙂
Zu Cloudflare müssen einem zwei Dinge klar sein. Zum Ersten mal ist das ein amerikanisches Unternehmen. Heißt, man hat nicht dasselbe Niveau an persönlichem Datenschutz wie in Europa. Wenn man sich außerdem verleiten lässt zusätzliche Services dazuzubuchen, schmeißt man natürlich wieder mal Geld über den Teich statt es hier zu lassen. Leider ist mir zu diesem Zeitpunkt keine Europäische Alternative bekannt, die ebenfalls kostenfrei und mit sehr guter Performance arbeitet. Falls ihr da was kennt, bitte umgehend in die Kommentare.
An zweiter Stelle muss einem klar sein, dass Cloudflare die SSL/TLS Termination macht. Wenn man sich also die Mühe macht und ein TLS Zertifikat für seine Domain einrichtet und der Zugriff über https erfolgt, dann gilt diese Verschlüsselung bis zu Cloudflare. Der Tunnel aus dem Internet ins private Netz ist natürlich auch verschlüsselt, aber da TLS schon bei Cloudflare terminiert wird könnten eben doch 2 Instanzen mitlesen, bei denen man es nicht vermuten würde: Zum Einen ist das Cloudflare selbst und dadurch, Stichwort Datenschutz, natürlich alle Unternehmen oder Agencies, die in der Lage sind auf dieses Amerikanische Unternehmen zuzugreifen. Zum Anderen, geht der weitergeleitete Traffic in eurem lokalen Netz halt normalerweise über http vom cloudflared zu eurem Service und nicht über https. Das ist zumindest zwingend erforderlich, wenn man lokal wie üblich einfach IPs verwendet und lokal keine Zertifikate hat. Nehme ich hier mal an, da das halt für Heimnetze der Standard ist. In dem Fall kann aber auch jeder, der im lokalen WiFi sitzt da mitlesen. Heißt irgendwelche dubiosen IoT Geräte, oder die Hacker Kumpel vom Sohnemann wenn man beides nicht in entsprechende andere Netze wirft. Sollte man im Hinterkopf behalten ob es einen betrifft.
Alternativen: Es gibt ein zunehmend beliebtes und verbreitetes Open Source Projekt, dass dieselbe Funktionalität wie Cloudflare Tunnels abdeckt und das ist Pangolin. Das steht bei mir noch auf der Mal-Ausprobieren-Liste, da es recht gut und ein wenig intuitiver zu konfigurieren aussieht als Cloudflare, allerdings gibt es einen großen Nachteil: Es benötigt einen dedicated Server, der im Internet steht. Heißt, man braucht bspw. eine kleine Server Instanz von Hetzner, auf der man das alles installiert. Und dann hat man halt einen komplett im Internet stehenden Server bei dem man sich um Uptime, Sicherheit und Maintenance selbst kümmern muss. Alternativ, kann es das ganze auch cloud-hosted über die Pangolin Cloud kaufen. Das kostet halt wieder Geld. Und die Kosten skalieren (verständlicherweise) mit dem Traffic, den man verursacht, da der ja komplett immer über den Cloud Server geht. Jede zusätzliche Domain nach der ersten kostet auch nochmal extra. Ist halt alles bei Cloudflare mit drin. Dazu kommt, dass Pangolin halt wieder ein Amerikanisches Unternehmen mit Sitz in San Francisco ist, dass mittlerweile funding über Y Combinator bekommt und … na ja, da unterscheidet sich dann die Cloud Solution auch nicht mehr wirklich von Cloud Flare selbst.
Fazit und Ausblick
Wir haben hier mit einem kostenlosen Service dafür gesorgt, dass Services, die wir in unserem internen Netz laufen lassen, öffentlich im Internet verfügbar sind. Unterschiedliche Services brauchen keine spezifischen Ports, sondern können komfortabel über verschiedene Subdomains (oder Pfade) freigegeben werden unabhängig davon, wo die intern laufen. Intern, geht der Traffic durch ein Docker image, dass auf unserer Synology läuft und das System klappt mit allen Providern und auch instabilen Verbindungen oder temporären Wechseln in andere Netze, wie bspw. bei Failover Verbindungen.
Als Ausblick, kann man noch bei Cloudflare gewisse Zugriffsbeschränkungen einrichten und es gibt noch ein paar Stolpersteine in die man gerade bei WordPress und TLS laufen kann, da wird es auch noch Artikel von mir zu geben.
Hardware-Empfehlungen
Die üblichen Empfehlungen als Amazon-Affiliate Links um den Blog zu unterstützen. Danke fürs klicken 🙂
Synology
Minisforum Homeserver
Das könnte dich ebenfalls interessieren
Zuverlässige Backup-Lösung für Fotografen / Videografen
HowTo: Endlich weg mit der Werbung – AdGuard Home ganz einfach mit Synology Docker
