Reverse Proxy mit IPv6

Moinsen Leute, ich bin gerade dabei mit einen Reverse Proxy auf meiner Synology Nas einzurichten um genau zu sein nginx und stolper hier alle 2minuten über ein und das nächste Problem.

Der Fall:

Es soll sich von außerhalt des Netzwerkes verbunden werden, Jellyfin, Navidrome usw. - was auch gut klappt, meine IPv6, Port 3000, die Synology leitet 3000 dann an 8096 weiter und alles klappt aber eben nur in http, weil wenn ich auf https umstelle komme ich zwar über den Browser auf Navidrome nachdem ich das Risiko akzeptiert habe, aber z.B. die App "Tempo" kann auf den Server dann nicht mehr zugreifen, anscheinend, da das Zertifikat fehlt.
Dazu:
Ich habe eine fixe IPv6 und da geht der Spaß los.

Nginx verlangt ja nach einer Domain um den Proxy anzulegen, es geht aber keine IPv6, da eckige Klammern nicht erlaubt sind.
Nun will ich aber nicht zusätzlich via DynDNS oder so meine IP irgendwo "Listen" lassen. Ich habe eine fixe IP und brauche das doch eigentlich garnicht.

Kann mir da mal jemand Licht ins Dunkle bringen? Ich habs auch schon mit Chatgpt probiert....das kannste voll vergessen...

Das muss doch irgendwie zu lösen sein, ohne irgendwelche Wahnsinns Umwege?

P.S.: Ich könnte auch bei http bleiben, da die Accounts eh "Read Only" wären, aber wenn man dochmal Jellyfin oder so aus einem fremden Wlan nutzen will...

Als Proxy eignet sich sicher eher Caddy.
Aber das http Problem dürfte daran liegen, dass der Proxy das HTTPS machen muss und intern in HTTP übersetzt und weiterleitet.
Also muss der komplette Zertifikatszauber vom Proxy gemanaged werden. Ein Zertifikat ohne Domain ist jetzt eher untypisch, geht aber, weil man als ON durchaus eine IP genutzt werden kann.
Sauberer ist es aber das über einen DNS mit Let's Encrypt zu lösen - weil dann ist das auch ein "offizielles" Zertifikat, ohne Beschränkungen.
Denn manche insbesondere Apps akzeptieren schlicht keine Self-Signed Certs... So wie sagen wir mal als Beispiel die GMAIL Mail App, wo man dann "alle Zertifikate akzeptieren" wählen kann, wenn es self-sigend ist.

Moinsen
du hängst da an zwei Punkten: Zertifikat/HTTPS und Name (Domain) – nicht so sehr an nginx selbst.

Wenn du über https gehst und der Browser nur nach “Risiko akzeptieren” funktioniert, ist das i. d. R. ein nicht vertrauenswürdiges Zertifikat (self-signed / falsch passend). Viele Apps (z. B. Tempo/Subsonic-Clients) lehnen das dann komplett ab, auch wenn der Browser es noch „durchwinkt“.

Wichtig: Für „sauberes“ HTTPS brauchst du praktisch immer einen Hostnamen, damit Let’s Encrypt ein Zertifikat ausstellen kann (SNI/Domain im Zertifikat). Rein über IPv6 direkt ist das in der Praxis leider oft frickelig.

Lösung ohne „Wahnsinns-Umwege“​

• Du brauchst kein DynDNS, wenn deine IPv6 wirklich fest ist.
  Hol dir irgendeine Domain (oder Subdomain) und setz einen AAAA-Record auf deine feste IPv6 → dann kann Let’s Encrypt ein gültiges Zertifikat ausstellen.
• Danach per Reverse Proxy (Synology RP oder Nginx Proxy Manager) auf Jellyfin/Navidrome weiterleiten → Apps funktionieren dann auch sauber mit HTTPS.

Nginx Proxy Manager auf Synology?​

Ja, geht in der Regel problemlos über Docker/Container Manager auf der Synology. Damit kannst du die Proxy-Hosts und Let’s-Encrypt-Zertifikate bequem per Web-UI verwalten.

Extra-Tipp (falls IPv6 doch mal wechselt / du’s einfacher willst)​

Du kannst auch kostenloses DDNS nutzen und das dann mit Nginx Proxy Manager + Let’s Encrypt kombinieren. Dann hast du einen festen Hostnamen, NPM holt dir automatisch Zertifikate, und du musst dich nicht ständig um IP-Änderungen kümmern.

Unterm Strich: HTTPS ohne Warnungen = gültiges Zertifikat = fast immer Domain/Hostname.
Wenn du willst, schreib kurz, ob du Ports 80/443 forwarden kannst (oder nur 443), dann kann man dir den passenden Let’s-Encrypt-Validierungsweg nennen (HTTP-01 vs. DNS-01).

Ja mich wurmt es ehrlich gesagt etwas meine IP in eine öffentliche Domain umzuwandeln, natürlich ist das alles das selbe, ob man jetzt die IP hat oder die Domain, ABER irgendwo ist es ja gelistet...und wo Listen existieren sind viele Daten, die Interesse wecken und potentielle Leaks beherbergen...

Mir missfällt da einfach der Gedanke...

Das ist doch absurd bzw. Paranioa. Ob es eine IP oder Domain ist - das ist beides blöd, eine feste IP insbesondere.
Mehr oder weniger ist es sogar komplizierter an die Domain als an die IP zu kommen. Das Netz wird dauergescanned, die IP-Ranges sind bekannt. Die sind längst hinreichend katalogisiert. Deswegen kann man mit den IPs ja auch Geo-Fencing machen, weil ja bekannt ist, welche IP in welche Region gehört. Für eine Domain ist das schon etwas schwerer. Da müsste man erst einmal die IP scannen und dann schauen ob man die per Reverse-DNS auflösen kann.
Am Ende ist das Jacke wie Hose. Allein die Tatsache, dass du eine feste IP hast, macht jede Art von "Versteckspiel" an dem Punkt obsolet. Deine IP ist längst als Endpoint in Datenbanken gelandet. Das geht sogar soweit, das genau geschaut wird, welche Services an dieser IP existieren - und das landet gleich mit in der Datenbank. In meiner Firefall landen täglich duzender solcher Port-Scan versuche, die die Firewall zwar blockt - aber was nutzt es effektiv? Dann geht ein Scan plötzlich von einer anderen IP an den Folgeports los - ganz klar Bot-Netze die durch Internet crawlen.
Dann bist du perfekt Inventarisiert. An jedem Port lässt sich nahezu immer der dort gehoste Service feststellen. Tauchen irgendwo nun Schwachstellen in Softwarepaketen auf, dann werden genau diese Datenbanken durchforstet und die Endgeräte angegriffen, bevor du selber von der Schwachstelle durch die Presse überhaupt erfahren hast...
So läuft die Realität.

Am Ende bringt es nichts. Ein Let's Encrypt Cert bekommst du nicht ohne DNS. Das stellen anders nicht aus.
Denkbar wäre ein HTTPS Cert kaufen - wüsste aber jetzt keinen, der das ohne DNS Namen macht. Verstößt meine ich sogar gegen die selbst auferlegten Regeln, die die Herausgeber sich gegeben haben. Da bin ich aber nicht 100% im Thema.

Andere Option ist nur noch, ein eigenes Self-Signed Root-Cert erzeugen, davon ein Cert ableiten und das Root-Certs (den Public-Teil) als "Trusted Authority" in das Endgerät einspielen. Auf manchen Plattformen geht das mit unter aber nicht. Windows wäre recht einfach, Android ist schon nervig (ständig die Warnung "übrprüfen sie dieses Zertifikat..."). Apfel weiß ich nicht, so wie ich den Laden kenne wird das da aber vermutlich gar nicht gehen.
Self-Signed geht halt nur, wenn die zugreifende Applikation es a) zulässt selbst zu signieren (und damit nicht abgesichert) und b) keine Reverse-Auflösung erzwingt um den Host sicherzustellen.

Ich habe es letztlich bei mir auch per Let's Encrypt gelöst - für mehrere Sub-Domänen meiner Hautpt-Domain.

Jo, meine Server Experimente laufen auch alle mit Let's Encrypt. Ist ja auch kinderleicht das zu erstellen. DynDns leitet alles um.

xNecromindx schrieb:

Bitte, Anmelden oder Registrieren um den Inhalt zu sehen!

Zum Vergrößern anklicken....

Ja ist es auch
Es ist sowieso keine Diskussion wert HTTPS mit Lets Encrypt vs. HTTP ohne Zerftifikate.
Letzteres ist von außerhalb des eigenen Netzwerkes immer ein Problem...

Ja, natürlich. Aber du sagst es: Von außen... da würde ich kein HTTP machen.
Es ist zwar extrem unwahrscheinlich, aber über den Weg können dir deine Credentials abhanden kommen. Was einfach der Hauptgrund für SSL/TLS ist.
Hätte HTTP einen sicheren Credential-Austausch-Mechanismus, bräuchten viele Applikationen, die heute TLS fahren es gar nicht bzw. nicht besonders dringend.

Bei mir ist es auch so, dass Client im Intranet HTTP Zugriff machen, während alles nach außen nur Zugriff per HTTPS erhält.
Manches ist von außen auch gar nicht erreichbar. Das Datenbank-Webfrontend z.B. Zwar auch gesichert, aber zu heikel, sollte man darauf Zugriff bekommen.
Das erreicht man nur in einem speziellen Intranet VLAN.

Netzwerksicherheit macht schon Sinn. Netzwerk-Paranoia bringt aber keine Sicherheit

Aber an sich, mal nüchtern betrachtet:

Wenn ich z.B. Jellyfin nur Intern administriere und von extern nur Zugänge benutze die nur normale Nutzerzugänge haben, dann kann ja erstmal nix passieren, richtig?
Also das schlimmste wäre ja, dass jemand die Zugangsdaten für diesen normalen Zugang hätte -> die Konsequenz wäre den entsprechenden Account bei infiltration zu deaktivieren bzw das Passwort via Admin Zugang zu ändern.
Es entstünde ja quasi kein Schaden?

(Vorrausgesetzt man ist kein Idiot und nimmt User "Admin" Passwort "fergthgre" und als Nutzer Account dann zwar einen anderen Namen aber das selbe oder ein nachvollziehbares Passwort xxxxxD )

Und die Chance besteht ja nur in einem Fremden W-Lan oder einem infiziertem Endgerät?

Ja, im Grunde hast du recht.
Es könnte jemand einen Nutzer-Account abfischen und "missbrauchen". Natürlich würde das mittelfristig auffallen.

Das schlimmste was passieren könnte wäre, zumindest was ich mir jetzt ausdenken kann, dass jemand den Account abfischt und dich anscheißt wegen Verbreitung illegaler Inhalte.
Dann bist du 1:1 in der selben Bedrängnis wie jemand der bei dem Tauschbörsen-Prinzip aufgefallen ist und abgemahnt wird. Die Filme kann man ja einsehen und das Angebot ist klar dokumentierbar.

Allerdings stellt sich halt schon die Frage, wie es dazu kommen soll!? Natürlich wäre zum einen ein fremdes WLAN so eine möglich Falle, aber natürlich auch jedes andere Fremdnetz in das man sich einklinkt.
Ich würde es schon als sehr hypothetisch betrachten, dass so ein worst case Fall eintritt.
Das jetzt irgendwer an Internetknotenpunkten den kompletten Trafic überwacht und Jellyfin-Instanzen heraus fisched, naja... und selbst wenn dem so wäre, interessieren die sich dann ganz sicher nicht dafür, dass du deiner Oma ihre Lieblingsserie zur Verfügung stellst. Zumal das durchaus unter Computer-Spionage fällt - die für sich genommen einen weit höheren Straftatbestand darstellt...

Wenn es also wirklich nur Read-Only Nutzeraccounts sind... so what!?