IPv6 nativ + IPv4 CDN?

IPv64.net - Services
, ,
1

Moin,

Ich habe nun auch Glasfaser (Deutsche Glasfaser mit CGNAT).

Ich habe einen Homeserver, der einige Webseiten (Subdomains) auf https bereit stellt, SSH und außerdem Wireguard VPN zur Fritzbox.

Die DynDNS Einträge leiten korrekt auf meine öffentliche V6 Adresse um und das funktioniert auch.

Vermutlich bin ich damit weitestgehend zufrieden, weiß gerade keinen Dienst der noch zwingend V4 benötigt.

Trotzdem wäre es natürlich schön, dies als fallback zu haben.

Nun also meine Frage: kann ich ipv64 so konfigurieren, dass für V6 nativ per DynDNS genutzt wird und ich V4 über das CDN bereitstellen kann, was dann per V6 auf meinen Server geleitet wird? Bin mir nicht ganz sicher, ob ich das richtig verstanden habe. Wie muss ich das konfigurieren?

Und ansonsten, wenn V4 eh nicht zur Verfügung steht, sollte man den A record dann entfernen? Ich hab aktuell noch ein paar Sachen, die nicht funktionieren, wo ich gerade nicht weiß, ob irgendwo noch veraltete Daten gecached sind, oder doch noch jemand in der Kette V4 nutzt…

Und noch eine Frage: wenn das per CDN funktioniert, sind darüber Subdomains möglich? Mein letzter Stand war, dass letsencrypt keine Wildcard Zerts kann, oder? Wie müsste ich vorgehen, wenn ich verschiedene Subdomains proxyen möchte?

Auf meinem Server gibt es halt Zertifikate für alle genutzten Subdomains.

1 „Gefällt mir“
2

Das gleiche Thema beschäftigt mich auch gerade.
Um die Zertifikate musst du dich nicht kümmern, das macht IPv64.net für dich - gibt dann halt verschiedene Zertifikate, je nachdem ob du über IPv6 oder IPv4 aufrufst.

Zum „Fallback“: nach meiner Beobachtung gibt es leider noch viel zu viele (W)LANs, die nur V4 bieten. Viele mögen es nicht mehr sein, aber wie es Murphys Gesetz will, steckt man immer gerade dann in einem, wenn der Zugriff auf die Webseiten notwendig ist…

Ich habe hier recht ausführlich beschrieben, was du alles wie einrichten musst, um dein Vorhaben umzusetzen. Aktuell ist mir leider kein Weg bekannt, dass für die 4. Domainebene umzusetzen, brauchst also für jeden Dienst eine eigene Subdomain im Portal.

3

Oh ja, genau das kann das CDN sehr gut.

Eine direkt Verbindung via DynDNS / IPv6 einfach weiterhin über den DNS-Namen. Einfach als DynDNS einrichten und fertig.

CDN einrichten - Und zwar mit der Option ONLY IPv4.
Damit wird dann das CDN nur für IPv4 verwendet und IPv6 geht direkt.

image
image1176×263 18.9 KB

4

Hallo @Dennis_Admin,

ich schreib es nur ungern, aber ich denke ich bin da soeben einem Fehler in deinem Setting auf die Spur gekommen.

Genau das funktioniert leider nicht. Ich habe nur mal zum ausprobieren und auch weil mich die Problembeschriebungen von @Sven77 und anderen beschäftigen eben ein CDN-Portmapper für meine Nextcloud eingerichtet und zwar wie von dir hier oben eben beschrieben nur für IPv4. Das Ergebnis: aus einem reinen IPv4-Netz (Mobilfunk, IPv6 in den APN-Einstellungen deaktiviert) komme ich dann mit https://meine.Domain.ipv64.net nur auf deine CDN-Willkommensseite, nicht aber auf die Nextcloud.

Dann habe ich mir angesehen, was in meiner pfsense passiert, wenn ich so (über eine andere Domain bei dir, wie meine.Domain.ipv64.de) vom Mobiltelefon mit nur IPv4 einen Wireguard-Tunnel zur pfsense herstelle. Der Unterschied: bei dieser anderen Domain ist der Full-Proxy -Mode aktiviert, nicht nur der IPv4-Only. Die Verbindung zum Wireguard-Tunnel zur pfsense hat geklappt.

Zu meiner Überraschung wurde aber als Endpoint in der pfsense für mein Smartphone keine IPv4- sondern die IPv6-Adresse [2a01:xxx:yyyy:d5a9::1]:46020 angezeigt. Erwartet hätte ich ja eine IPv4-Adresse, denn das Smartphone hat ja nur IPv4 mit diesen APN-Einstellungen. Aber vielleicht ist meine Erwartung da auch falsch.

Das hat mich nun aber auf die Idee gebracht für den Proxymode der Domain für die Nextcloud von Enable only IPv4 Proxy zu ändern in Enable Proxy (Full Mode) zu ändern.

Diese Änderung hat es dann auch für die Nextcloud gebracht. Mit dem Full Mode konnte ich dann bei unveränderten APN (also nur IPv4) auch meine Nextcloud per https://meine.Domain.ipv64.net im Firefox des Smartphones erreichen, was im only IPv4 zuvor nicht geklappt hat.

Insofern scheint die Option ONLY IPv4 derzeit nicht so zu funktionieren, wie du das beschrieben hast.

Nachtrag: nun klappt es auch plötzlich nicht mehr im Full Mode. Ich komme nur bis zur ipv64-CDN-Seite.

Könnte das eventuell daran liegen, dass beim Einrichten von CDN automatisch Let’s Encrypt Zertifikate erstellt werden? Das sind ja ganz andere Zertifikate als die, die in meiner Nextcloud hinterlegt sind. Ohne neuen Zertifikate zu erstellen, kann man aber kein CDN anlegen.

Den CDN-Proxy habe ich nun wieder für die Nextcloud deaktiviert und gelöscht.

5

Also ich denke ich bin dem Mysterium nun auf die Spur gekommen. Über eine weitere ipv64-DynDNS-Domain konnte ich meine Nextcloud nun per CDN Reverse Proxy erreichbar machen. Dazu musste ich die nginx- und php-Konfigurationsdateien der Nextcloud entsprechend anpassen, damit diese die zusätzliche Domain akzeptieren.

Diese neue Domain hat keinen Domainprefix, wie die andere, bisher genutzte. Bisher sah die so aus:

Bei der bisherigen musste ich ja über CDN → CDN Service → CDN Options → Set DNS Records auf die Domain mit dem Präfix, also nextcloud.meineDomain,ipv64.net verweisen. Unter Add CDN Domain kann man aber gar keine Domains mit einem Präfix auswählen.

Dieser Sachverhalt könnte also auch der Grund dafür sein, dass es bisher nicht geklappt hat.

Nun ist das ja als mögliche Fehlerursache entfallen. Der Verweis unter CDN → CDN Service → CDN Options → Set DNS Records entspricht dem was unter Add CDN Domain ausgewählt werden kann.

Die zweite mögliche Ursache, warum es nun klappt, zuvor aber nicht, sind die Let’s Encrypt Zertifikate. Die von mir auf dem Nextcloud-Server erstellten Zertifikate sind ja nur gültig für nextcloud.meineDomain.ipv64.net, nicht aber für meineDomain.ipv64.de. Daher kann es hier nun keine Konflikte mehr geben.

Was von beidem nun genau die Ursache ist, werde ich heute Abend aber nicht mehr herausfinden. Dazu ist f+r mich der Abend nun bereits zu sehr fortgeschritten.

6

Vielen, vielen Dank für die exzessiven Tests!

Wenn ich das richtig verstehe, geht es jetzt bei dir doch wieder, jedoch ohne Präfix vor der Subdomain?
(Zum Verständnis: ich werde jetzt von „Subdomain“ sprechen, wenn ich den dritten Teil meine und von „Präfix“ für den vierten, also: Präfix.Subdomain.Domain.tld )

Ja, ich habe auch gesehen dass CDN jeweils nur pro Subdomain aktiviert werden kann. WENN das erledigt ist, kann man aber je Präfix z.Bsp. Full-Proxy oder IPv4-only (oder eben keins von beiden) auswählen.
Somit hätte ich gedacht, dass das keinen Unterschied machen sollte.

Davon abgesehen nutze ich für meine aktuellen Tests auch nur die Subdomain direkt, also ohne weiteren Präfix davor.

Nächstes Thema Zertifikate: prüft denn der CDN-Proxy überhaupt die Gültigkeit von Zertifikaten?
Falls ja, wäre es für manche Szenarien sinnvoll, das abstellen zu können - also neben „HTTP -unsecure“ und „HTTPs - Self/Verified Signed“ noch ein „HTTPs - Unverified Signed“ zu haben!
Denn… manche Backends machen es einem vielleicht schwer, wirklich „gültige“ Zertifikate zu nutzen - vor allem dann, wenn CDN den Service über die aktuelle/dynamische IPv6 anspricht.

Allerdings sollte das in meinem speziellen Fall nicht die Ursache sein, dass es nicht funktioniert - denn ich nutze definitiv ein Let’s Encrypt, bei dem ich den FQDN bei IPv64.net extra mit angegeben habe. Das kann ich auch überprüfen, wenn ich den Service direkt aufrufen, z.Bsp. über die IPv6 Adresse.

7

Richtig. Wobei ich mir aber noch nicht klar darüber bin, ob der Präfix (Subdomain = eigentlich SubSubDomain) die Ursache für das Fehlverhalten ist, oder die Konfiguration von (in meinem Fall) php und nginx. Bei der Konfiguration von könnte der Grund auch zu finden sein, was weitere Tests erfordert. Gründe könnte sein:

  • die trusted_domains in der config.php
  • die server_name in der nginx-Konfigurationsdatei
  • eventuell auch die Tatsache, dass ich ja Zertifikae von Let’s Encrypt auf dem Nextcloud-Server habe, die alle 90 Tage per ACME aktualisiert werden

Die Domain, auf die der CDN-Reverse Proxy zeigt ist ja nicht die nextcloud.Domain.ipv64.net, sondern die Domain.ipv64.net, so wie es ursprünglich war und dazu führte, dass ich nicht auf der Login-Seite der Nextcloud landete sondern auf der CDN-Seite. Die trusted_domains in der config.php sagen aber klar aus, vertrauenswürdig sind nur Aufrufe auf nextcloud.Domain.ipv64.net. Der server_name in der nginx-Konfigurationsdatei hat eine ähnliche Funktion für den Webserver selbst.

Ändert sich das nun durch das Setzen des CDN-Reverse Proxy auf eine Domain ohne den Präfix nextcloud davor, dann sollten richtigerweise php und nginx das als Fehlerhaft erkennen.

Da ist nun eben die Frage, die wohl nur Dennis beantworten kann wie der CDN-Reverse Proxy das handhabt, wenn die weitergeleitete IPv6-Adresse auf nextcloud.Domain.ipv64.net verweist, der CDN-Reverse Proxy selbst aber derzeit zwingend für Domain.ipv64.net konfiguriert werden muss.

Für meine Test gestern hatte ich nun eben eine Domain.ipv64.de zur vorhandenen hinzugefügt und diese Domain auch in die trusted_domains in der config.php und die server_name in der nginx-Konfigurationsdatei eingetragen.

Mit diesen Änderungen klappt es nun. Aber da das ja gleich mehrere Änderungen sind, ist mir noch nicht vollständig klar welche Änderung maßgeblich ist. Das müssen weitere Tests zeigen, die ich mache sobald es mir die Zeit erlaubt.

8

Der CDN-Proxy erzeugt eigene Zertifikate. Rufe ich meine Nextcloud über die gestern angelegte Domain auf, werden die Zertifikate verwendet, die gestern vom CDN erzeigt wurden. Nutze ich die Domain ohne CDN, die ich seit gut einem Jahr nutze, sind es meine eigenen Zertifikate, regelmäßig erneuter per ACME.

Geprüft werden die Zertifikate ja eigentlich vom Browser mit dem man die Nextcloud erreichen will. Bei selbst signierten Zertifikaten fragt der Browser ja ob man denen vertrauen will oder nicht. Keine Ahnung was passiert, wenn es da zwei unterschiedliche Zertifikate für dieselbe Domain gibt.

9

Das ist ja so nicht ganz richtig… nur CDN muss global für die gesamte Subdomain aktiviert werden, der ReverseProxy kann doch (sogar unterschiedlich) je Präfix konfiguriert werden:

grafik
grafik1034×369 27.5 KB

Auch hier würde ich korrigieren: der Browser kommuniziert (bei Nutzung des CDN-ReverseProxy) ja nur mit dem ReverseProxy, verschlüsselt ist somit die Kommunikation zwischen diesen beiden mit dem vom CDN ausgestellten Zertifikat. Der eigentliche INHALT einer Seite wird aber durch den CDN-ReverseProxy vom eigentlichen Service abgerufen, je nach Konfiguration erfolgt das auch verschlüsselt und hier obliegt es dann dem CDN, ob es die Kommunikation wegen ggf. „unschöner“ Zertifikate abbricht. Der Browser würde daraufhin eine sauber verschlüsselte Fehlerseite vom CDN erhalten.

10

Generell ist das ja zunächst noch nicht der ReverseProxy was du da zeigst. Das sind ja lediglich ersteinmal die CDN-DNS-Records, die da an der Stelle deiner Abbildung unterschiedlich gesetzt werden.

Ich habe das soeben schnell auch noch mal für die Hauptdomain aktiviert, allerdings für den Präfix meiner sense, auf der Wiregard läuft. Daher braucht es da keinen CDN-Reverse Proxy sondern nur den Portmapper. Mit dem Portmapper der dann auf den UDP-Port für Wireguard zeigt, gibt es auch rein gar keine Probleme. Das klappt auf Anhieb. Aber beim Portmapperer sind auch weder Let’s Encrypt Zertifikate noch Configs für Webserver und php involviert.

Das bei meine Nextcloud unsaber konfiguriert ist denke ich eher nicht. Sowohl beim Nextcloud Security Scan wie auch beim Qualys SSL Labs Test erreiche ich ein A+-Rating.

11

Das wollte ich damit auch nicht zum Ausdruck bringen.
Aber die Zertifikate gelten bei dynamischen Adressen ja in der Regel nur für den FQDN, nicht aber für die Adresse selbst - denn dann müssten ja die Zertifikate bei jedem Wechsel neu ausgestellt werden.
Wenn du also im Browser zum Test mal die Nextcloud über die IPv6 in eckigen Klammern, also https://[1234::…::abcd]/ aufrufst, bekommst du mit Sicherheit eine Zertifkatswarnung.
Und hier ist dann die Frage, wie halt der CDN-Proxy damit umgeht, da ich denke dass er das so aufrufen MUSS. Aber hier kann wohl auch nur @Dennis_Admin Auskunft geben bzw. es intern prüfen - wissen müssen wir anderen es ja gar nicht. :wink:

12

Hallo @Sven77,

ich glaube wir reden ein wenig aneinander vorbei. Ich sehe auf meiner Seite mindestens drei Stellschrauben, die für die Probleme bei dem CDN Reverse Proxy ursächlich sein könnten.

  • die php Konfiguration
  • die nginx Konfiguration
  • die Art wie mein eigenes Zertifikat erstellt wurde.

Diese Probleme können aber müssen nicht nur von einer dieser drei Stellschrauben verursacht worden sein. Es kann gut auch eine Kombination von zwei oder allen drei sein.

Und ja, die Zertifikate gelten für die FQDN. Bei den von mir selbst erstellten Zertifikaten nur für die SubDomain. also nextcloud.XXX.ipv64.net ausdrücklich also nicht für XXX.ipv64.net. Will sagen, sobald die Anfrage des CLients als NICHT auf nextcloud.XXX.ipv64.net, sondern nur auf XXX.ipv64.net (oder was beliebig anderes), wird der also ein nicht gültiges Zertifikat liefern.

Das CDN erstellt aber Zertifikate für *.XXX.ipv64.net. Also für XXX.ipv64.net und alle denkbaren Subdomains. Und auch die ursprüngliche php-Config und nginx-Config kannten nur die Subdomains, also nextcloud.XXX.ipv64.net. Alles andere war unzulässig.

Nachtrag: ich werde mich erst morgen wieder damit befassen können. Ich werde dann mitteilen, was ich herausgefunden habe, sofern ich es lösen kann.

13

Ja, ich sehe ein dass es bei dir einige Stolpersteine mehr gibt, die kann ich bei mir aber eigentlich ausschließen.
Um das 100% auszuschließen habe ich jetzt:

  • einen weiteren Präfix „cdn.XXXX.ipv64.net“ erstellt
  • für diesen den Full-Proxy aktiviert
  • ausprobiert → ging immer noch nicht
  • einen weiteren Port für unverschlüsseltes HTTP freigegeben
  • das Backend im CDN-ReverseProxy auf diesen Port und „Level1: HTTP - unsecure“ umgestellt
  • ausprobiert, also nur die 50X-Fehlerseite neu geladen → voila! es zeigt die Seite meines Dienstes an
  • Gegencheck: Backend im CDN-ReverseProxy zurück auf den alten Port und „Level2: HTTPs - Self/Verified Signed“ gestellt
  • wieder die Seite aktualisiert → geht immer noch (???)

Daher mit einer zweiten Subdomain, die ebenfalls letzte Woche ging und diese Woche nicht mehr:

  • Port und Level ebenfalls im Backend geändert, auf Deployment gewartet
  • Port und Level im Backend zurückgesetzt und wieder auf Deployment gewartet
  • Test mit dieser Subdomain direkt https://YYYY.ipv64.net/ → geht nicht (???)
  • ebenfalls einen Präfix „cdn“ erstellt und für diesen Full-Proxy aktiviert
  • Test mit https://cdn.YYYY.ipv64.net/ → geht (!)
  • erneuter Test mit https://YYYY.ipv64.net/ → geht nicht (???)

Okay, vielleicht liegt es ja am IPv4-only Proxy der Subdomain direkt, dieser ist aber bei der anderen Domain auch auf IPv4-only gestellt, daher dort nochmal testen:

Jetzt bin ich erstmal ratlos, warum…

14

Nachtrag:
Nach den Änderungen gestern habe ich es heute nochmal von einem anderen Client aus probiert…

Jetzt ist definitiv der Fall, dass beide Subdomains direkt (mit IPv4-only Proxy) die 50X-Fehlerseite zeigen und ein Aufruf über den Präfix „cdn“ (mit Full-Proxy) bei beiden funktioniert.

Somit scheint es wirklich irgendwo ein Problem mit den IPv4-only Konfigurationen zu geben…

15

@Sven77 danke für die Info.

16

Oder auch nicht. Die Testdomain, die ich angelegt hatte um den CDN-Reverse-Proxy für meine Nextcloud zu testen, war eben auch nicht erreichbar. Stattdessen kam nur die CDN-Seite.

Bildschirmfoto_2025-06-05_13-27-59
Bildschirmfoto_2025-06-05_13-27-591255×305 36 KB

Ich habe dann einfach auf der gelben Schaltfläche oben (Disable Proxy) geklickt, den Proxy also ausgeschaltet und danach sogleich wieder mit unveränderten Einstellungen aktiviert. Dann kam sofort wieder meine Nextcloud statt der CDN-Seite.

Seitens meiner eigenen Server-Konfig habe ich nichts verändert gehabt.

17

Ja, das entspricht ja auch in gewisser Weise meinen Beobachtungen - dass es bei jedweder Änderung „erstmal“ geht.
Mich würde nun interessieren, ob es bei dir morgen auch noch geht - ohne weitere Änderungen.

Leider ist auch schwer nachvollziehbar, was der Browser alles zwischenspeichert - eigentlich sollte das ja über die DNS-TTL geregelt werden, aber ich vermute dass sich daran nicht jeder Browser gebunden fühlt - schon gar nicht, wenn er noch hinter einem Proxy hängt.
Scheinbar gibt es zumindest eine Art Cache, ob eine FQDN per AAAA-Record oder A-Record angesprochen wird.

Aber dennoch: sobald die CDN-Fehlerseite zu sehen ist, kann es ja kein Direktaufruf sein.

18

Bis morgen muss ich dazu gar nicht warten. Hat vor einer Stunde schon wieder nur auf die 50X-Seite gezeigt. Jetzt habe ich den CDN-Server gewechselt.

Geht es jetzt (vorerst) wieder.

19

Ich hab jetzt nicht alles im Detail verfolgt, aber klingt ziemlich nach meinen Problemen / Beobachtungen, die ich auch gemacht hab (und weshalb ich hier auch schon andere Threads aufgemacht hatte). Vor allem dieses „geht ne Weile und dann plötzlich nicht mehr“ usw…

Die Frage wäre ja nun wirklich, ob sich @Dennis_Admin sich das ganze mal anschaut, ob es da noch irgendwo Probleme auf ipv64 Seiten gibt.

Ist vielleicht technisch nicht so einfach zu lösen, aber es würde ggf. schon helfen, wenn man eine Art Log einsehen könnte, wo man den Grund sehen kann, warum man die 50x CDN Fehlerseite bekommt. Ist es ein Problem im CDN Proxy? Kann der CDN Proxy meinen Server nicht erreichen? Liefert mein Server einen Fehler? …

Ich nutze im Moment erstmal einen Cloudflare Zerotrust Tunnel. Das ist natürlich nicht das gleiche Prinzip, daher möchte ich da auch keinen Vergleich ziehen. Aber unterm Strich funktioniert das wenigstens zuverlässig. Wäre schön, wenn ich es irgendwann wieder komplett und zuverlässig über ipv64 lösen könnte.

20

Update zu meinen Test mit dem CDN Rerverse Proxy:

Nachdem ich nun gestern den CDN-Server gewechselt war hatte, die CDN-Testdomain und die Nextcloud dahinter, bis ich ins Bett ging (also bis kurz vor 23 Uhr) erreichbar. Die Zwangstrennung heute Morgen kurz vor 5 Uhr hat das nun aber nicht überlebt. Statt der Nextcloud kommt nun wieder die 50X-Seite.

Wichtiger Hinweis: diese Probleme betreffen ausschließlich den CDN Rerverse Proxy und ausdrücklich nicht den CDN-Portmapper oder den DynDNS-Service als solches. Diese beiden Services arbeiten fehlerlos.
In diesem Zusammenhang möchte ich alle anderen vom Problem genervten noch mal darauf hinweisen, dass der CDN sich noch immer im BETA-Stadium befindet und dies auch durch einen entsprechenden Hinweis auf der Konfigurationsseite ersichtlich ist.
Für einen Produktiveinsatz sollte man BETA-Versionen nie nehmen, es sei denn es gibt keine Alternative dazu. Jedem sollte klar sein, BETA-Version bedeutet immer es kann noch Fehler und Probleme geben.

Da ich auf den CDN Rerverse Proxy nicht angewiesen bin, werde ich meine Tests nun vorerst beenden und Dennis die Zeit geben die zweifellos bestehenden Probleme zu beheben. Dem ipv64 DynDNS-Service und dem CDN-Portmapper werde ich weiterhin nutzen und insgesamt ist das was Dennis da auf die Beine gestellt hat ein tolles Angebot.

2 „Gefällt mir“