Ich habe eine DynDNS Adresse erstellt und diese in meiner Fritz!Box eingetragen (URL: „Mit AVM Fritzbox IPv6-Prefix Updaten“). Diese sitzt hinter einem DS-Lite Glasfaseranschluß. Außerdem wurden zwei Subdomains erstellt. Eine für einen AdguardPi mit Worddpress und eine für ein Streamingradio (Als zweite Testmöglichkeit).
Außerdem ist der CDN-Services aktiv. Ausprobiert „Full Mode“ und IPv4.
Im Healthcheck wird mir die Verbindung als in Ordnung angezeigt. Leider komme ich weder auf meine Fritzbox noch auf meine Geräte dahinter.
Folgendes habe ich getestet:
Direkte Eingabe der IPv6-Adresse+Port für meine Fritz!Box in der Adressleiste von meinem Browser (also https://[20:xx:xx:xx:xx]:Port ): ich kann auf meine Fritz!Box zugreifen.
Direkte Eingabe der IPv6-Adresse für meine beiden privaten Netzwerkgeräte: keine Verbindung trotz dem ich sie testweise auf „Exposed Host“ in IPv4 & v6 freigegeben habe
Aufruf der DynDNS-URL+Port von IPv64: keine Verbindung zu meiner Fritz!Box. Ich kriege eine Seite von IPv64 angezeigt mit Fehler „50x The requested website is currently not available.“
Der Aufruf der Subdomäns scheiterte ebenfalls.
Welche Angaben ihr genau braucht schreibt bitte rein. Ich liefer sie dann. Würde mich freuen wenn mir jemand Tipps geben kann das ich meine Geräte erreiche. Danke!
Hast du das von außen, also z.B. über das Mobilfunknetz oder von innen (WLAN/LAN) probiert? Wenn das von innen nicht geht, sind es möglicherweise die falschen Adressen oder die Dienste “lauschen” gar nicht auf IPv6. Wenn Namen von innen nicht gehen, liegt es oft am DNS-Rebindschutz.
Solange du nicht einmal mit der IPv6-Adresse von Außen auf die angeblich freigeschalteten Server kommst, kann alles was du danach gemacht hast (DynDNS, Reverse-Proxy) auch nicht klappen.
Der Fehler liegt in der Konfiguration deines LAN’s und/oder deiner Fritte
sollte es aussehen, wenn Server, Netzwerk und Firewall/Router korrekt konfiguriert sind und man per IPv6-Adresse über das Mobilfiunknetz (nutze den WiFi-Hotspot des Mobiltelefons) auf eine https-Seite zugreift. Man sollte dann (hier im Beispiel mit Firefox) im Browser eine Warnung sehen und sich das Let’s Encrypt Zertifikat des Server ansehen können um eine Ausnahmeregel zu definieren. Das macht bei IPv6 aber keinen Sinn, weil sich die IPv6-Adresse regelmäßig nach Zwangstrennung ändert.
Davon würde ich dringend abraten. Die Fritte macht man sinnvollerweise nicht direkt per https (und noch weniger per http) von Außen erreichbar. Will man diese aus der Ferne administrieren, nutzt man IPSec oder besser Wireguard.
Ich teste über Mobilfunk/USB-Tethering. Von innen gibt es null Probleme. Ich erreiche alles unter seiner IP/Rebind Adresse und seinem zugewiesenem Port
Ich komme mit der DynDNS-URL aber auch nicht auf meine Fritz!Box (mit angehängtem Port). Und die kann ich direkt über ihre IPv6 Adresse+Port aufrufen (Mobilfunk).
Momentan bin ich nicht vor Ort bei dem Anschluß auf den ich zugreifen will. Wireguard ist aber eingerichtet, beide Netze verbunden und ich gehe von meinem jetzigen Standort schon über Wireguard. Nur wenn ich es teste ziehe ich den LAN Stecker und hänge mein Telefon über USB-Tethering an den Rechner. Außerdem habe ich hier an diesem Anschluß nur eine IPv4. Und Nein hier ist nichts falsch konfiguriert. Der Anschluß hat nur IPv4 und wenn ich die IPv64-URL aufrufe nutze ich Mobilfunk um es nicht noch komplizierter zu machen .
Vielleicht könnten wir uns auf den Zugriff zur Fritz!Box über DynDNS-IPv64 beschränken? Ich habe den Verdacht wenn sich das klärt funktioniert auch das andere. Ich habe testweise auch schon mal einen anderen DynDNS-Anbieter getestet aber mit dem selben Ergebnis.
Dazu müsstest du erst einmal hier mitteilen, was du genau im CDN konfiguriert hast. CDN ist nicht gleich CDN.
Nein. Das CDN braucht den Zugriff auf die extern erreichbare IPv6-Adresse des Servers der via CDN erreicht werden soll. Ist das nicht möglich kann kein CDN klappen.
Diese krasse Fehlkonfiguration hatte ich fast schon vermutet. So kann das ja nicht klappen !!!
Nur der Portmapper macht Sinn, wenn man FQDN mit angehängtem Port (wie abc.cdefgh.ij:8443) verwenden will. Der Reverse Proxy ist NUR für 80 und 443 gedacht. Man sollte die Anleitungen und Videos auch lesen / ansehen.
Direkter Aufruf der IPv6-Adresse mit angehängtem Port meiner Fritz!Box. Die IPv6 Adresse ist Past & Copy aus den Einstellungen meiner DynDNS Adresse. In diesem Fall habe ich Firefox genutzt um zu verhindern das er sich irgendwas aus dem Cache holt.
Beim Test mit eingeschaltetem oder ausgeschaltetem Proxy und dem Port aus Portmapper war das Ergebnis immer das selbe. Alles getestet über Mobilfunk.
Wenn ich die DynDNS-URL nutzen will muss der Proxy an sein und ich muß mich in einem IPv6-Netz befinden. Aus einem IPv4-Netz funktioniert das nicht. Das soll wohl auch anders funktionieren.
Glaub bitte nicht das ich vorher hier nicht schon hin-und-her probiert habe. Ich habe schon einige Zeit investiert bevor ich mich an das Forum gewandt habe. Gerne kann man noch mal auf die Fritz!Box Konfiguration schauen und ich lasse mich bestimmt auch eines besseren belehren.
Warum nimmt die Fritz!Box eine direkte Eingabe der IPv6 an aber den Aufruf über IPv64 mit Portmapper nicht? Direkte Eingabe nur über IPv6-Netz - Ok verständlich. Warum aber nicht mit IPv64 über ein IPv4-Netz? Dafür habe ich den Proxy eingerichtet (oder meinetwegen auch den Portmapper). Es funktioniert aber auch nicht mit einem anderen DynDNS-Dienst.
Die Fritz!Box steht im Netz. Hier ist meine IPv6-Adresse. Hier ist mein Port. Sie steht da mit nacktem A… Direkt darüber ist sie auch erreichbar. Was soll sie denn noch machen? Ich habe den Verdacht das es weder an IPv64 (oder dem anderen DynDNS-Dienst) liegt noch an der Fritz!Box. Und Nein ich habe keine Idee was dazwischen nicht funktioniert. Darum habe ich gefragt.
Dass der Portmapper bei Aufruf einer IP-Adresse, die auf das WAN-Interface der Fritte zeigt, nicht klappt scheint mir so ein Fritte-Spezialding zu sein.
Hab das an einer Fritte an einem entfernten Standort, die aber eigentlich Dual-Stack hat, nachgestellt. Neue DynDNS-Domain für die konfiguerert und für diese zusätzliche Domain nur die IPv6-Adresse des WAN-Interfaces eingetragen.
Dann Internetzugriff auf die FRITZ!Box über HTTPS aktiviert. Der dabei zugeloste Port: 16507. Ergebnis: Fritte kann über MyFritz- und ipv64-DynDNS erreicht werden. Aber abei schon erste Auffälligkeit. Obwohl im Zertifikat der Fritte aufgelistet gibt es für die ipv64-Domain im Frefox einen Warnhinweis und man müsste eine Ausnahmeregel hinzufügen, nicht aber für die MyFritz-Domain
Als nächstes Portmapper aktiviert für diese neue Domain und 16507 hierfür wurde mir seitens ipv64 Port 50837 zugelost. Ergebnis: bei Aufruf über die neue Domain und Port 50837 Webseite nicht erreichbar
Nun Porrtmapper deaktiviert und Reverse Proxy aktiviert. Da gibts mit dem ursprünglichen Port 16507 nur einen Timeout. Genau das was ich auch erwartet habe, denn der Reverse Proxy ist nur für 80 und 443 gedacht.
Schlussfolgerung: grundsätzlich ist der Reverse Proxy für alles was nicht 443 oder 80 ist ungeeignet. Das richtige Tool wäre der Portmapper. Aber dagegen scheint die Fritte was zu haben, wenn es um einen Zugriff aufs eigene WAN-Interface per https oder http geht. Anders wenn man z.B. den Wireguard Port z.B. udp 51822 per Portmapper mappt. Das duldet die Fritte problemlos.
Da Wireguard aber udp und nicht tcp nutzt, kann es theoretisch auch schon grunsätzlich daran liegen dass die Fritte Probleme mit tcp und Portmapping macht. Das zu testen hab ich aber keine Lust. Nutze eh selbst keine Fritten sondern pfsense. Damit habe ich viele Probleme nicht, die bei Fritten total nervig sind.
Nachtrag: offenbar duldet die Fritte auch keine CNAME fürs WAN. Hab mal CNAME gesetzt für meineEntfernteFritte.ipv64.de auf meineEntfernteFritte.ipv64.net. IPv6 ist ja identisch bei setzen von CNAME. Dennoch wird Verbindung per https seitens der Fritte verweigert und das obgleich ich testweise trotz Warnhinweis statt 16507 nun sogar direkt 443 freigegeben hatte.
Diese gammeligen Dinger sind einfach zu nix zu gebrauchen
Vielen Dank das du dir soviel Zeit genommen hast. Und das mein ich im Ernst!
zu 1.
Hier das selbe in Vivaldi.
zu 2.
Hier das selbe
zu 3.
Das wiederum funktioniert bei mir. Eben noch mal ausprobiert. Ist auch in meinem vorigem Beitrag das erste Bild. Allerdings nicht aus einem IPv4-Netz!
zu Wireguard
Das war von Anfang bei mir kein Problem auch ohne IPv64. Das funktioniert tatsächlich Mobil, nur IPv4-Netz etc
Als Hinweis:
Benutze ich in der Anleitung die URL „Mit AVM Fritzbox IPv6-Prefix Updaten“ macht er das einmal und dann kommt kein Update mehr.
Zumindest ist das irgendwie ein Ergebnis. Kein erfreuliches aber immerhin. Leider kann ich die Fritz!Box nicht mit OpenWRT flashen oder in den Bridge Modus versetzen ohne das sie ihre Firewall nutzt. Ist mir zumindest nicht bekannt. Was gibt es denn so noch an Möglichkeiten? Einen Medienwandler und dann einen anderen Router? Ist mir das preislich wert? Ich muss mal schauen…
Was in jedem Fall gehen sollte ist die Verwendung von Port 443 der Fritte in Internetzugriff auf die FRITZ!Box über HTTPS aktivieren zu erzwingen. Dann sollte es mit dem Rerverse Proxy problemlos klappen, aber du exposed eben Port 443. Also zumindest bei IPv4 gar keine gute Idee.
Es gibt m.E. aber sowieso gar keine guten Grund überhaupt eine Fritte per https direkt erreichbar zu machen. Will man die remote erreichen wird eben Wireguard benutzt, was bei dir eh bereits konfiguriert ist. Das ist in jedem Fall wesentlich sicherer, denn man muss sich ja doppelt legitimieren
bei WIreguard mittels der Credentials und dann nochmal
im LAN-seitigen Web-Interface der Fritte mit Usename und Passwort.
Ich erlaube daher grundsätzlich auch an meiner pfsense keinen Remote-Zugang aufs WAN-Interface. Dito bei Fritten, wie der mit der ich getestet habe.
Es ist nur zum testen gewesen. Damit hätte ich einen Fehler in der Konfiguration für den Server hinter der Fritz!Box eingrenzen können. Ich schalte es auch wieder aus.
Da du bei IPv6 kein NAT hast, kannste damit aber wirklich gar nichts eingrenzen, was mit Freigaben und der Erreichbarkeit von Servern bei DS-Lite oder CGNat zu tun hat.
Jetzt haben wir uns tagelang im Kreis gedreht, denn wie ich schon mehrfach betonte:
Das CDN braucht den Zugriff auf die extern erreichbare IPv6-Adresse des Servers der via CDN erreicht werden soll. Ist das nicht möglich kann kein CDN klappen
Diese extern erreichbare IPv6-Adresse des Servers der via CDN erreicht werden soll ist NICHT die der Fritte.
So ist es. Und auch auf diese IPv6-URLs komme ich nicht. Auch schon ausprobiert. Die Fritz!Box war nur Eine wo ich hin wollte. Ich wollte es jetzt nicht noch komplizierter machen indem ich hier noch mehr Baustellen aufmache. Dann geht alles durcheinander.
Ich habe mir z.B die IPv6-GUA von einem Philips „Hue“ Hub, einem AdGuardPi/Wordpress und einem Streming Radio aus der Fritz!Box geholt. Rufe ich diese auf laufen sie alle in einen TimeOut. Also zurück kommt „XYZ antwortete dem Gateway nicht.“ aber eben nicht „XYZ ist nicht erreichbar.“ Ich hätte zumindest die Webinterfaces der Geräte sehen sollen. Aber das jetzt hier auch noch mit rein….
Wir können raten. Die Fritz!Box natet IPv6 nicht. Soll sie auch nicht. Einfach nur durchschieben. Tut sie das?
Soso. Dann haste dich mutmaßlich bisher nicht weiter mit der IPv6-Config von „Hue“ Hub, Pi und Streming Radio befasst.
Okay, ob „Hue“ Hub und Streming Radio da großartig Optionen anbieten darf bezweifelt werden. Aber dein Pi-Server hat sicherlich (und vorzugsweise) eine Config per /etc/network/interfaces oder (wenn mit Klicky-Bunti-Desktop ausgestattet) per Network-Manager. Wie sieht diese Config den bezüglich IPv6 aus?
Dann die Fritte. Wie ist da denn deren DHCPv6-Server konfiguriert?
Weist die überhaupt IA_PD und IA_NA den Clients zu oder würfeln die sich die IPv6-Adresse per SLAAC selbst aus?
Tja, das ist eben die Frage. Was hast du der Fritte (und den Clients) denn gesagt was sie genau tun sollen? Von allein (also out of the Box) läuft es nicht richtig!
.
.