CDN / Reverse Proxy: Backend Einstellungen bitte pro Präfix/Entry

IPv64.net - Services
1

Hallo zusammen,
zunächst einmal ein fettes Dankeschön für diesen (auch kostenlos verfügbaren!) Service!

Ich hierher komme auch über den Umweg: eigene Server im LAN, jetzt nur noch IPv6 (CG-NAT) erreichbar und auf der Suche nach einer Möglichkeit, die Server auch aus reinen IPv4-Netzen erreichen zu können…

Zwischendurch erstmal etwas Kritik:
Die Anleitungen sind, sofern überhaup vorhanden, nicht ganz intuitiv - im Fall von CDN liefern die Menüpunkte „Reverse Proxy“ und „Portmapper“ sogar nur eine Beschreibung der Technik - um es zu Konfigurieren muss man über „CDN Service“ anfangen.

ABER: Ich habe dann im Forum von gewissen „Videos“ gelesen und habe dann glücklicherweise über den YouTube-Kanal gefunden, was ich wie konfigurieren muss!

Doch nun zum Problem:
Während man im DynDNS beliebige Präfixe/Entries für verschiedene IPs anlegen kann, gelten die Reverse-Proxy-Einstellungen leider gleichermaßen für alle.
Das ist (zumindest in meinem Setup) etwas suboptimal…

Ich habe - sagen wir mal - drei Dienste, nennen wir sie „FHEM“, „EVCC“ und „JellyFin“.
Wenn alle auf Port 80 (oder 443) lauschen auf unterschiedlichen IPv6-Adressen lauschen würden, könnte man mit einer Subdomain auskommen:

  • Subdomain z.Bsp. „sven77.ipv64.net“, darunter die Enytries:
    fhem.sven77.ipv64.net → AAAA 2a01::1
    evcc.sven77.ipv64.net → AAAA 2a01::2
    jellyfin.sven77.ipv64.net → AAAA 2a01::3
  • CDN für Subdomain aktivieren
  • Reverse-Proxy für alle 3 Entries aktivieren
  • Reverse-Proxy Backend ggf. auf Port (80 oder 443) und Protokoll anpassen
  • „Enable Proxy“ und ggf. „Enable Websocket“ für die Subdomain drücken
  • warten…

Do so einfach geht das leider nicht, wenn alle 3 Dienste auf unterschiedlichen Ports laufen - vielleicht (und das nur mal hypothetisch angenommen) weil alle auf dem selben Gerät im Container laufen und die Standard-Ports für alle 3 ohnehin unterschiedlich sind.

In diesem Fall muss man nämlich für jeden Service (genauer für jede Protokoll/Port-Kombination) eine eigene Subdomain erstellen! Das impliziert dann leider, dass die Adressen nicht mehr so schön „zusammengehören“.
Könnte man das noch erweitern, dass die Backend-Einstellungen je Entry vorgenommen werden können/müssen?

Side fact:
Ich habe anfangs versucht, das über den integrierten Reverse Proxy meiner Synology zu lösen - was aber nicht funktionieren KANN. Denn der Reverse Proxy im CDN leitet den Aufruf ja direkt über die IPv6-Adresse, damit kann die Synology nicht mehr unterscheiden, für welchen Service die Anfrage gedacht ist.
Außer… (richtig) man macht es über verschiedene Ports und landet damit wieder im oben beschriebenen Dilemma.

2

Installiere einen Wiregurad-Server. Richte CDN und Portmapper auf den Wiregurad-Server zeigend ein. Schon kommst du (bei etablierter Wiregurad-Verbindung) auf alle deine Server („FHEM“, „EVCC“ und „JellyFin“). Zugleich ist das Ganze so noch sicherer als bei direkter Anbindung ans Internet der Server („FHEM“, „EVCC“ und „JellyFin“).

Nachtrag: selbst eine Fritte mit aktuellem OS kann als Wiregurad-Server dienen.

3

Ja, vielen Dank - vielleicht ist das wirklich der beste Weg:
Alles normal für IPv6 einrichten und nur bei Nicht-Erreichbarkeit ein vorher konfiguriertes VPN aufbauen.

Leider scheitere ich schon seit Tagen an beidem…
Die Server von IPv64.net scheinen wohl wieder überlastet oder einem Angriff ausgesetzt zu sein, meine eigentlich konfigurierten Services sind nach dem langen Wochenende plötzlich nicht mehr erreichbar (Fehlerseite 50X) und den Portmapper kann ich gerade auch nicht einrichten, da die Seite immer mal wieder down ist.
Schade - eigentlich sah das Konzept für mich stimmig aus, aber von „set it and forget it“ ist es wohl leider aktuell noch weit entfernt.

4

Davon merke ich nichts. Bei mir läuft alles normal.

5

Die Seite ist seit Tagen Online. Keine Angriffe mehr, außer ein paar Probeschüsse. Das CDN ist sehr kompliziert und löst nicht immer für alle Ansätze alles sofort.

6

Nun ja, in meinem Fall funktionierte es ja letzte Woche Dienstag oder Mittwoch endlich.
Seitdem nichts geändert, nicht mal meine IPv6-Adresse - dennoch bekomme ich seit gestern die 50X-Seite.

Und bitte nicht falsch verstehen - ich will hier nichts grundlos kritisieren - aber als ich vorhin den Portmapper einrichten wollte, kam nach Klick auf „PortMapper“ definitiv nur „Seite kann nicht angezeigt werden / erneut versuchen“. Das blieb für einige Minuten so, jetzt ging es wieder und ich werde es weiter einrichten…
Gleiches Bild hatte ich auch Anfang letzter Woche, als ich die ersten Versuche mit CDN gestartet habe.

7

Mit welcher Hard-/Software verbindest du dich eigentlich mit dem Internet? Also Fritzbox (Modell) oder so etwas wie OPNsense, pfsense? Dazu habe ich in deinen bisherigen Angaben nichts gefunden.

Wie und womit werden die AAAA-Records aktualisiert?

8

Das betreffende Netz hängt hinter einer FritzBox 7390 (daher hat die leider noch kein Wireguard).
Die AAAA-Records blieben bis jetzt seit Vertragsbeginn immer gleich, daher aktualisiere ich sie aktuell gar nicht.

Kleiner Erfolg: ich habe jetzt fix den VPN-Server auf meiner Synology installiert und OpenVPN freigegeben, für diesen einen UDP-Portmapper eingerichtet und direkt über die IPv4-Adresse des CDN-Servers verbunden - klappt!

Damit sind wir jetzt nur leider vom Thema abgewichen, da es ja gar nicht mehr um Reverse-Proxy geht. Dennoch auch hier ein ähnliches Problem (wie von mir in einem weiteren Beitrag beschrieben): da ich den Reverse-Proxy als IPv4-only eingerichtet habe, antwortet auf meinen DynDNS-Namen meine eigene IPv6-Adresse und die CDN-IPv4. Wenn ich nun diesen Namen im OpenVPN-Client eintrage, würde der doch sicher auch versuchen über das AAAA-Record eine Verbindung herzustellen, was natürlich auf dem Port 5xxxx vom Portmapper nicht funktionieren kann…

NACHTRAG: Das könnte ich natürlich über einen eigenen Präfix für die VPN-Verbindung lösen, auf dem ich „Full Proxy“ aktiviere. :ok_hand:

9

Damit weichen wir zwar erneut vom Thema ab, aber das letzte verfügbare OS für die 7390 ist aus der Steinzeit, namlich das fritz.os 6-88 aus Sept. 2023. Die Fritte ist somit reif für den Elektroschrott.

10

Ich habe gerade generell ein Problem noch zu verstehen was du nun, also tagesaktuell eigentlich erreichen willst. Du verweist auf andere Beiträge. Mir ist auch unklar, auf welche Ports die

hören. Ein lokaler Proxy bei dir im LAN macht nur Sinn wenn alle drei auf 80/443 lauschen.

11

Ich habe ja gesagt, dass wir inzwischen eigentlich vom Thema abweichen…
Das Thema VPN funktioniert jetzt (auch mit der schrottreifen Fritte), ich beobachte mal ob es so bleibt.

Nun zurück zur Ursprungsfrage (diesmal ganz ausführlich):
Da ich das böse Wort mit „S“ ja jetzt ohnehin schon erwähnt habe, ganz konkret am Beispiel der 3 genannten Dienste.
Um mein Link-Limit zu umgehen, schreibe ich statt „http“ immer „hxxp“.

Ich habe auf einer Synology 3 Docker-Container für jeden Dienst und dort jeweils deren Default-Ports freigegeben. Somit sind alle 3 im LAN über die IPv4 und auch IPv6 der Synology erreichbar:
FHEM unter hxxp://synology.fritz.net:8083/
EVCC unter hxxp://synology.fritz.net:7070/
Jellyfin unter hxxp://synology.fritz.net:8096/

Als nächstes sollen diese aus dem Internet erreichbar werden (von der Sinnhaftigkeit bitte mal absehen, ich habe die 3 nur als Beispiel für unterschiedliche Ports gewählt), also gehe ich in die Fritte und richte eine IPv6-Freigabe für die Ports 8083, 7070 und 8096 für die IPv6 der Synology ein und suche mir einen DNS-Anbieter, bei dem ich ein AAAA-Record für die Synology eintragen kann, bspw. als „sven77.ipv64.net“.
Von jetzt an ist alles schick und die Dienste sind von extern erreichbar:
FHEM unter hxxp://sven77.ipv64.net:8083/
EVCC unter hxxp://sven77.ipv64.net:7070/
Jellyfin unter hxxp://sven77.ipv64.net:8096/

ABER - natürlich nur, solange der Client und das Netz auch IPv6 können!
Da das leider heutzutage immer noch nicht alle Netze mitmachen, hätte ich gern (nur für diese Ausnahme) einen ReverseProxy, über den ich die Dienste dennoch erreiche.
Aus Faulheit aber bitte recht transparent, ohne mir alle Lesezeichen doppelt für IPv4 und IPv6 abzuspeichern.

Problem 1: das geht nicht, weil ich den CDN-ReverseProxy nicht zum Lauschen auf den Ports 8083, 7070 und 8096 überreden kann.

Daher der nächste Zwischenschritt: ich aktiviere den in DSM integrierten ReverseProxy und richte für alle 3 Services ein eigenes AAAA-Record mit Verweis auf die gleiche IPv6-Adresse ein. In diesem Zuge kann man dann auch gleich hxxpS aktivieren, auch wenn die eigentlichen Dienste das nicht können oder wollen. (Falls hier jemand mitliest, der das nutzen möchte: weiterhin trage ich alle 3 als Ausnahme beim DNS-Rebind-Schutz der Fritte ein).

Von nun an sind die Dienste (über IPv6!) mit folgenden URLs erreichbar:
FHEM unter hxxps://fhem.sven77.ipv64.net/
EVCC unter hxxps://evcc.sven77.ipv64.net/
Jellyfin unter hxxps://jellyfin.sven77.ipv64.net/
Die Verteilung auf die verschiedenen Ports je nach genutzem FQDN übernimmt der ReverseProxy der Synology.

Damit zurück zur IPv4-Erreichbarkeit von außen bzw. Problem 2:
Der CDN-ReverseProxy kann die Anfragen ja nur direkt an die IPv6-Adresse der Synology weiterreichen, ohne einen FQDN zu nutzen (denn der führt ja zu ihm selbst). Daher kann der ReverseProxy in der Synology nun nicht mehr wissen, welcher Service denn gewünscht wird.

Also weiter zum 2. Zwischenschritt:
Zusätzlich zu den o.g. Namen richte ich drei weitere ReverseProxy-Einträge ein, die unabhängig vom benutzten Namen auf verschiedenen Ports lauschen:
FHEM unter hxxps://*:58083/
EVCC unter hxxps://*:57070/
Jellyfin unter hxxps://*:58096/
Dann gebe ich diese 3 Ports ebenfalls in der Fritte frei und bin endlich soweit, dass ich für jeden der 3 einen CDN-ReverseProxy konfigurieren kann.

Doch hier kommt dann eben Problem 3:
Für die 3 verschiedenen Präfixe „fhem“, „evcc“ und „jellyfin“ kann ich zwar verschiedene AAAA-Records anlegen, in meinem Fall sind die aber alle identisch und ich müsste vielmehr verschiedene Backend-Ports eingeben!

Erst dann könnte ich die einfachen FQDNs nutzen, die dann im Falle von IPv4 (oder für „Full Proxy“ in jedem Fall) folgenden Weg gehen, diesmal nur an einem Beispiel:

hxxps://fhem.sven77.ipv64.net/ → CDN-ReverseProxy → hxxps://[2a01::1234]:58083/ → Synology-RevervseProxy → hxxp://127.0.0.1:8083/

Da aber die ReverseProxy-Einstellungen für ALLE Präfixe einer Subdomain gleich sind, ginge das aktuell nur über 3 verschiedene Subdomains, z.Bsp. „fhem-sven77.ipv64.net“, „evcc-sven77.ipv64.net“ und „jellyfin-sven77.ipv64.net“.
Das macht aber einerseits die Zertifikatsverwaltung umständlicher und limitiert letztlich im freien Account auch auf 3 Dienste…

12

Das was du da machen willst ist ja nun wirklich fernab dessen, was normale Homelab-User so üblicherweise wollen.

Das bedeutet doch: selbst im LAN sind die server auch per IPv4-Adresse nur so (Beispiel):

  • FHEM unter hxxp://192.168.178.10:8083/
  • EVCC unter hxxp://192.168.178.20:7070/
  • Jellyfin unter hxxp://192.168.178.30:8096/

erreichbar. Würdest du die alle unter 443 erreichbar machen, könntest du auch einen Proxy im LAN verwenden und den CDN-Rervere Proxy auf diesen lokalen Proxy (z.B. nginx) zeigen lassen.

Immerhin sollen die ja alle via http, besser https, erreichbar gemacht werden. Warum also die abweichenden Ports und die damit verbundenen Probleme?

13

Naja, wie gesagt: alle laufen im Docker auf der Synology. Somit haben auch alle die gleiche IP.
Somit sind sie im LAN ohne jeglichen Proxy erreichbar über:

  • FHEM unter hxxp://192.168.178.10:8083/
  • EVCC unter hxxp://192.168.178.10:7070/
  • Jellyfin unter hxxp://192.168.178.10:8096/

…aber wie viele normale Homelab-User das so oder so ähnlich machen, habe ich vorher nicht untersucht. Da es aber sehr viele Anleitungen für Anfänger gibt und die verschiedenen Dienste ja nunmal auch verschiedene (Standard-)Ports nutzen, könnte ich mir vorstellen dass es noch 1-2 weitere gibt, die mehr als einen Dienst betreiben und diese nicht auf die Standardports 80/443 umkonfigurieren.
Allerdings sind wir mit dieser Frage auch wieder weg vom Thema. :wink:

14

Habe ich überlesen bzw. nicht bedacht. Ist das alte Docker-Problem. Ich nutze kein Docker. Ich virtualisiere per KVM/QEMU. Da hat jede VM eine eigene IPv4- und IPv6-Adresse.

15

Das gleiche Problem hat man aber auch, wenn auf einer (von mir aus sogar physikalischen) Kiste 2 Dienste auf 2 Ports laufen.
Teilweise werden auch User- und Admin-GUIs auf verschiedenen Ports bereitgestellt…
Kannst mir doch nicht erzählen, dass du dazu deiner Box dann 2 IP-Adressen gibts und jede Oberfläche auf dem Standard-Port an eine eigene IP bindest?

Von daher - so gaaaaaanz ausgefallen ist doch die Problemstellung nun wirklich nicht!

16

Ich würde unter gar keinen Umstständen wollen, dass ein Admin-GUI (sofern es über einen anderen Port erreichbar ist) direkt aus dem www erreichbar ist. Es hat ja einen Grund, warum man das dann auf verschiedenen Ports trennt.

Bei mir wäre so ein Admin-GUI dann nur per Wireguard-Tunnel erreichbar.

Genau darum virtualisiert man doch. Jeder Dienst bekommt seine eigene VM.

17

Gut, lessons learned - vielen Dank dafür.

Können wir dann zurück zum Thema kommen und uns um die Fragestellung kümmern?