IPv4 only Proxy - richtig verstanden?

IPv64.net - Services DynDNS2
1

Hallo zusammen,

Ich habe eine DS-Lite Anschluss und damit nur eine IPv6 Adresse.

ich habe meinen TrueNAS Server via Fritz-Box und Nginx Proxy Manager und über eine DynDNS-Domäne hier ans Laufen gebracht (Reietr DynDNS).

Dabei habe ich div. Subdomains definiert, die dann vom NPM ausgewertet und auf die einzelnen TrueNAS Services „verteilt“ werden.

Da ich auch aus IPv4 Netzen (Hotel WLANs…) auch erreichbar sein will, habe ich für die Subdomains den IPv4-only Proxy aktiviert.

Korrekt sehe ich dann für jede Subdomain meine eigene IPv6 IP Adresse sowie die IPv4 Adresse des CDNs.

Meine Annahme ist, dass ein entsprechender Proxy den Zugriff auf die IPv4 Adresse des CDNs im DNS auf meine IPv6 abbildet bzw. den IP Traffic eben „proxied“.

Erwartung ist so, dass ein curl -v -6 https://sub.haupt.domäne.de (natürlich nicht meine wirkliche Domäne ;-)) auf den Service in TrueNAS zugreift und dabei meine durch NPM „erzeugtes“ SSL Zertifikat validiert. Das funktioniert auch korrekt so. Der Zugriff ist über die DynDNS Domänen hier einwandfrei.

Allerdings funktioniert dies nicht bei einem curl -v -4 https://sub.haupt.domäne.de (hier sollte ja der Proxy wirken). In diesem Fall gibt curl einen Fehler zurück, da ich ein abgelaufenes Zertifikat bekomme.

Ein Full-Proxy scheint mir nicht sinnvoll, weil ich mehr Traffic durch die IPv64.net Infrastruktur schleife, ohne dass wir alle einen Nutzen davon haben (oder?).

Das gelieferte Zertifikat ist in meinem Fall:

21:26:25.162924 [0-0] * Server certificate:
21:26:25.162950 [0-0] * subject: CN=homenet.srv64.de
21:26:25.162989 [0-0] * start date: Jan 8 14:22:51 2025 GMT
21:26:25.163025 [0-0] * expire date: Apr 8 14:22:50 2025 GMT
21:26:25.163062 [0-0] * issuer: C=US; O=Let’s Encrypt; CN=E6

Die zurückgegebene Seite ist eine IPV64.net Fehler-Seite („The requested website is currently not available.“).

Mir ist bekannt, dass ich grundsätzlich auch den Reverse Proxy des CDNs statt des NPMs nutzen könnte. Will ich aber nicht.

Mir ist bekannt, dass es eine DDoS gab, aber laut Status sind alle Services up and running.

„Change Server“ und „Reset Services“ habe ich durchgeführt. Führte zu keiner Änderung.

Der Portmapper ist aktiv (Hauptdomäne => Wireguard Port der FritzBox).

Fragen:

  • Verstehe ich die Funktion des IPv4-only Proxies falsch? Mein Eindruck war, dass es in der Vergangenheit funktioniert hat!?
  • Warum ist meine Seite unter IPv4 angeblich nicht erreichbar?
  • Was kann ich in meinem Setup tun, damit es funktioniert?
  • Problem bei IPV64.net oder mir? Wenn bei mir, wie bekomme ich es weiter analysiert?

Beste Grüße
Tim

2

Wer mag mir den im Zweifel mit einem einfachen „sollte funktionieren“ oder „das ist so nicht richtig, weil…“ antworten?

3

Hi Framstag,
ich habe mich nun auch ein wenig mit dem Thema beschäftigt, da ich ähnliche Anforderungen habe.
Du wirst deinen eigenen Reverse Proxy (der nach URL den richtigen Service auswählt) nicht vom CDN-Proxy nutzen können. Denn dieser kann ja den „echten“ IPv6-Dienst nur über die IPv6-Adresse, nicht aber den DNS-Namen nutzen - denn dieser zeigt ja auf den CDN.
Ich denke, das wäre zu kompliziert zu programmieren, dass ein „IPv4 only Proxy“ dann nur AAAA-Records abfragt, um den eigentlichen Service zu nutzen.

Ich habe bei mir folgenden Workaround: zusätzlich zu den DNS-Namen gebe ich für jede Subdomain einen eigenen Port frei und richte diesen zusätzlich im Reverse Proxy (in deinem Fall auf TrueNAS) ein.
Bis hierhin sollten deine Dienste doppelt erreichbar sein, z.Bsp.:

Genau genommen aber unter allen URLs, die zu der IPv6-Adresse zeigen, also auch unter Angabe der Adresse selbst, z.Bsp. https://[2a01::dead:beef]:50001

Wenn das erstmal funktioniert, kannst du beim Backend der CDN-Proxys jeweils den richtigen Port hinterlegen und es sollte dann auch darüber laufen!

PS: An dieser Stelle sei erwähnt, dass aktuell für jede Subdomain eine eigene IPv64.net-Subdomain erstellt werden muss, siehe meinen Beitrag hier.