Subdomain pro Docker Anwendung

[Whoisfoxmulder]

Hallo Zusammen

Ich bin neu hier und hoffe auf Euch Experten

Vorab meine Komponenten:

• Domain
• DDNS eingerichtet
• SSL Zertifikat Let's Encrypt für Domain "domain.ch" eingebunden in DSM
• Fritzbox 5490 mit vielen kleinen Löchern (offene Ports)

Nun möchte ich die vielen offenen Ports auf meiner FW schliessen.

Ich habe mir eine Domain gegönnt und habe vorgesehen pro Docker Container eine Subdomain einzurichten.

Beispielsweise bazarr (Untertitelsuche) soll via bazarr.domain.ch erreichbar sein und nicht mehr unter domain.synology.me: port, plex unter plex.domain.ch usw.

Die Diskstation selber ist per Domain erreichbar. Sprich wenn ich www.domain.ch eingebe erscheint mein NAS-Login. So weit, so gut.

Habe es bereits mit Reverse Proxy versucht ohne Erfolg.

Auch habe ich versucht eine Weiterleitung beim Domainanbieter zu erstellen, aber das führt zum unschönen Ergebnis, dass dann die andere Domain in der Adresszeile steht.

Habt ihr einen Ansatz, wie man es lösen könnte?

Liebe Grüsse

 

[haydibe]

Ein Reverse-Proxy wird ja genau dafür genutzt einen Einstiegspunkt zu haben, der dann auf Basis von Subdomains (über manuell erstellte Nginx Konfiguration auch für URL-Pfade möglich) eine Weiterleitung an IP und Port eines Backendsystems durchführt. Soweit so gut. Die UI erlaubt nur http Reverse Proxying für Subdomains und oder Eingangsport. Über die manuelle Konfiguration kann man mittels "Stream" auch Reverse Proxy regeln für TCP und UDP zu erzeugen - alles was nicht http bzw. https als Protokoll verwendet wird ohne nicht funktionieren.

Alle Subdomains, die der Reverse Proxy behandeln soll, müssen natürlich auch entsprechend beim DNS-Hoster so gepflegt werden (manuell bzw. über DDNS?) das sie auf die WAN IP des Routers zeigen. Danach reicht die Weiterleitung von Port80/443 an die DS.

Was wir alles nicht wissen:
- wir die Subdomain auf die WAN IP aufgelöst?
- ist für Bazar wirklich der Port 49208 am Host gebunden?
- blockiert auf der DS evtl. die Firewall den Traffic?

Was funktioniert den genau nicht?

 

[Whoisfoxmulder]

Hi @hydibe
Habe es nach Recherche herausgefunden. Es fehlte der CNAME Eintrag beim Domainanbieter... *facepalm*
Nun wollte ich aber eine SSL Verbindung erstellen, das klappt nicht. Auch nicht mit dem NGINX Reverse Proxy. Erhalte beim Erstellen von Zertifikaten dort immer einen internen Fehler. Auch funktioniert die Weiterleitung von Nginx nicht. Beim hauseigenen DMS Reverse Proxy klappt es einwandfrei.

Zu Deinen Fragen
- wir die Subdomain auf die WAN IP aufgelöst? ja (sofern ich die Frage korrekt verstehe), habe ich beim Domainanbieter hinterlegt.
- ist für Bazar wirklich der Port 49208 am Host gebunden? ja
- blockiert auf der DS evtl. die Firewall den Traffic? nein, FW auf DS ist aus

 

[luddi]

@Whoisfoxmulder Nach dem Thema "Subdomain pro Docker Anwendung" ist anzunehmen dass der Service "bazarr" als Docker Container läuft?
D.h. der Docker läuft auch auf der Diskstation selbst oder auf einem anderen Device im Netzwerk?

Somit ergibt sich folgende Frage zu Screenshot #2 "bazarr_reverse.png" Was ist hier als Ziel eingetragen? Ist das die IP-Adresse der Diskstation?

 

[haydibe]

Habe es nach Recherche herausgefunden. Es fehlte der CNAME Eintrag beim Domainanbieter... *facepalm*

Das ist eine indirekt Antwort auf meine Frage #1. Du hast also irgendwo noch einen Dyndns, der auf Deine WAN-IP zeigt und der CNAME deiner Subdomain zeigt nun auf den Dyndns-Namen (Bspw. myfritz-Addresse).

Hast Du denn auch ein Zertifikat hinzugefügt? Über die UI kannst Du ein Letsencrypt-Zertifikat für die Subdomain (weitere können als Alternative Name mit hinterlegt werden) anlegen. Das funktioniert NUR, wenn die DS über die Subdomain auf Port 80 erreichbar ist! . Im Nachgang kann man das Zertifikat dann dann dem Reverse-Proxy-Eintrag (unter `Zertifikat ->Konfigurieren`) zuordnen. Ohne Zertifikat kein HTTPS! Der Name SSL ist ein Überbleibsel in den Köpfen, defacto wird heutzutage statt SSL ausschließlich TLS (idealerweise v1.2 oder v1.3) eingesetzt.

 

[Whoisfoxmulder]

@Whoisfoxmulder Nach dem Thema "Subdomain pro Docker Anwendung" ist anzunehmen dass der Service "bazarr" als Docker Container läuft?
D.h. der Docker läuft auch auf der Diskstation selbst oder auf einem anderen Device im Netzwerk?

Somit ergibt sich folgende Frage zu Screenshot #2 "bazarr_reverse.png" Was ist hier als Ziel eingetragen? Ist das die IP-Adresse der Diskstation?

Ja richtig, die IP der Station. Könnte auch localhost sein. Das funktioniert nun alles tiptop. Nur der SSL resp. https:// Zugriff will nicht
Sprich wenn ich statt Port 80, Port 443 angebe (und natürlich https://) fliegt er auf die Schna*ze.

 

[luddi]

So wie ich das sehe hast du bereits eine Subdomain für bazarr.domain.tld angelegt. Hast du hierfür auch ein Zertifikat z.B. über Let´s Encrypt über die Diskstation erstellt?

 

[Whoisfoxmulder]

Das ist eine indirekt Antwort auf meine Frage #1. Du hast also irgendwo noch einen Dyndns, der auf Deine WAN-IP zeigt und der CNAME zeigt nun auf diesen Dyndns namen (Bspw. myfritz-Addresse).

Hast Du denn ein Zertifikat hinzugefügt? Über die UI kannst Du ein Letsencrypt-Zertifikat für die Subdomain (weitere können als Alternative Name mit hinerlegt werden) angelegen und im Nachgang unter Konfigurieren dem Hostnamen: port des Reverse-Proxy-Eintrags zuordnen (Wichtig: hierbei MUSS die DS über die Subdomain auf Port 80 erreichbar sein!). Ohne Zertikat kein TLS! Der Name SSL ist ein überbleibsel in den Köpfen, defacto wird heutzutage keine SSL Version, sondern ausschließlich TLS (idealerweise v1.2 oder v1.3) eingesetzt.

Moment, ich zeig Dir rasch anhand des Bazarr-Case was passiert. Richte ich die Reverse Proxy Geschichte mittels http / 80 ein, funktionierts. Richte ich es mittels https / 443 tut sich nix mehr. Sprich die Website kann mittels bazarr.DOMAIN.ch nicht mehr aufgerufen werden (Timeout). Wenn man https://bazarr.DOMAIN.ch eingibt, erscheint die Seite zwar aber mit einem durchgestrichenen HTTPS.

Spoiler: HTTP Config

Spoiler: HTTPS Config

 

[Whoisfoxmulder]

So wie ich das sehe hast du bereits eine Subdomain für bazarr.domain.tld angelegt. Hast du hierfür auch ein Zertifikat z.B. über Let´s Encrypt über die Diskstation erstellt?

Das macht es doch beim Anlegen einer HTTPS Reverse automatisch oder nicht? (vgl. meinen Post oben, welche auf Freischaltung wartet - ).

 

[luddi]

Das macht es doch beim Anlegen einer HTTPS Reverse automatisch oder nicht?

Wieso sollte das automatisch angelegt werden? Wenn es aber der Fall ist, kannst du doch im DSM einmal unter "Systemsteuerung --> Sicherheit --> Zertifikat" nachschauen ob ein Zertifikat für genau diese gewünschte Subdomain existiert.

Und welchen Post meinst du mit "wartet auf Freischaltung"?

 

[Whoisfoxmulder]

Das ist eine indirekt Antwort auf meine Frage #1. Du hast also irgendwo noch einen Dyndns, der auf Deine WAN-IP zeigt und der CNAME deiner Subdomain zeigt nun auf den Dyndns-Namen (Bspw. myfritz-Addresse).

Hast Du denn auch ein Zertifikat hinzugefügt? Über die UI kannst Du ein Letsencrypt-Zertifikat für die Subdomain (weitere können als Alternative Name mit hinterlegt werden) anlegen. Das funktioniert NUR, wenn die DS über die Subdomain auf Port 80 erreichbar ist! . Im Nachgang kann man das Zertifikat dann dann dem Reverse-Proxy-Eintrag (unter `Zertifikat ->Konfigurieren`) zuordnen. Ohne Zertifikat kein HTTPS! Der Name SSL ist ein Überbleibsel in den Köpfen, defacto wird heutzutage statt SSL ausschließlich TLS (idealerweise v1.2 oder v1.3) eingesetzt.

Ein kleines Erfolgserlebnis. Wenn ich ein separates Zertifikat erstelle, und dieses nach dem Reverse Proxy dann verbinde, funktioniert es. Allerdings nur wenn ich es mit https eingebe. Ohne https erscheint nach wie vor ein Timeout.

 

[Whoisfoxmulder]

Wieso sollte das automatisch angelegt werden? Wenn es aber der Fall ist, kannst du doch im DSM einmal unter "Systemsteuerung --> Sicherheit --> Zertifikat" nachschauen ob ein Zertifikat für genau diese gewünschte Subdomain existiert.

Und welchen Post meinst du mit "wartet auf Freischaltung"?

Den siehst Du eben nicht der wartet auf einen Moderator.
Also wenn ich ein HTTPS Reverse Proxy Eintrag erstelle, wird mein bestehendes Zertifikat automatisch ergänzt um diesen Eintrag. Aber offensichtlich funktioniert das nicht sauber. Hab nun wie oben beschrieben, ein sep. Zertifikat erstellt und dieses dann mit dem Reverse Proxy verbunden. Ein wenig mühsam für jede Subdomain ein Zertifikat zu beantragen, aber immerhin gehts dann. Nun muss ich nur noch herausfinden, wie ich automatisch nach https umleiten kann, wenn man kein https eingibt

 

[luddi]

Den siehst Du eben nicht der wartet auf einen Moderator.

Ah... jetzt komme ich mit. Was ist denn da drin dass der erst freigegeben werden muss?

Ja so kenne ich es persönlich auch, dass ich zuerst ein Zertifikat pro Subdomain anlege und diese dann mit dem jeweiligen Dienst oder Reverse Proxy Eintrag verknüpfe. Ich gebe dir auch recht dass es nicht sonderlich komfortabel ist für jede einzelne Subdomain ein eigenes Zertifikat anzulegen und manuell zu konfigurieren. Kommt natürlich darauf an um wie viele Subdomains es sich handelt.
Und leider gibt es bisher keine Möglichkeit Wildcard Zertifikate von Let´t Encrypt für eigene Domains direkt aus DSM heraus zu erstellen. Dies ist momentan nur für Synology.me Domains möglich soweit mir bekannt ist.

Aktuell laut Screenshot hast du einen Reverse Proxy Eintrag für HTTP 80 --> 49208 erstellt. Was ist denn der HTTPS Port für die Anwendung?
Ich habe bei mir z.B. einen Reverse Proxy Eintrag für HTTP 80 --> 80 und einen weiteren Eintrag für die gleiche Domain für HTTPS 443 --> 443.
Kann es sein dass es evtl. daran liegt?

 

[Whoisfoxmulder]

Ah... jetzt komme ich mit. Was ist denn da drin dass der erst freigegeben werden muss?

Ja so kenne ich es persönlich auch, dass ich zuerst ein Zertifikat pro Subdomain anlege und diese dann mit dem jeweiligen Dienst oder Reverse Proxy Eintrag verknüpfe. Ich gebe dir auch recht dass es nicht sonderlich komfortabel ist für jede einzelne Subdomain ein eigenes Zertifikat anzulegen und manuell zu konfigurieren. Kommt natürlich darauf an um wie viele Subdomains es sich handelt.
Und leider gibt es bisher keine Möglichkeit Wildcard Zertifikate von Let´t Encrypt für eigene Domains direkt aus DSM heraus zu erstellen. Dies ist momentan nur für Synology.me Domains möglich soweit mir bekannt ist.

Aktuell laut Screenshot hast du einen Reverse Proxy Eintrag für HTTP 80 --> 49208 erstellt. Was ist denn der HTTPS Port für die Anwendung?
Ich habe bei mir z.B. einen Reverse Proxy Eintrag für HTTP 80 --> 80 und einen weiteren Eintrag für die gleiche Domain für HTTPS 443 --> 443.
Kann es sein dass es evtl. daran liegt?

Wahrscheinlich Links oder die Bilder. Keine Ahnung nichts gefährliches.

Alles klar. Ja das mit dem Wildcard Zertifikat hab ich eben auch gelesen hoffentlich geben die das mal frei. Aber ja, nicht motzen - es ist immerhin gratis und was ist heutzutage schon gratis

Also ich habe nun alle auf https umgepolt. Sprich 443:49208 (abgekürzt ) Einen Eintrag 80:80 und 443:443 habe ich nicht erstellt. Braucht es den dafür wohl?

 

[Benares]

Also wenn ich ein HTTPS Reverse Proxy Eintrag erstelle, wird mein bestehendes Zertifikat automatisch ergänzt um diesen Eintrag

??? - Hab ich noch nie gesehen . Du hast höchsten einen zusätzlichen Dienst, dem du eins deiner Zertifikate zuordnen kannst.
Du solltest dir im Vorfeld überlegen, welche Sub-Domains du jetzt und in Zukunft brauchst, und dann ein Zertifikat für deine Domain erstellen, das alle Sub-Domains als "Alternate Names" enthält. Wildcard ginge auch, aber das ist etwas aufwendiger anzulegen/zu pflegen.

 

[luddi]

Einen Eintrag 80:80 und 443:443 habe ich nicht erstellt. Braucht es den dafür wohl?

Nein, damit wollte ich nur sagen dass du einmal versuchen solltest einen Eintrag explizit für HTTP und einen anderen explizit für HTTPS zu erstellen.
Wenn du natürlich andere listening Ports verwendest als 80 und 443 dann meinte ich in deinem konkreten Fall folgendes.

Reverse Proxy Rule:
a.) 80:49208
b.) 443:49208

Das ist eben die Frage ob der Port 49208 sowohl auf HTTP als auch auf HTTPS Anfragen reagiert.
Du scheinst ja das Problem zu haben dass wenn eine Anfrage über http:// (sprich Port 80) kommt dann diese in einem Timeout resultiert obwohl du eingerichtet hast alle http Anfragen auf HTTPS weiterzuleiten.
Deshalb meine Vermutung dass jetzt eine zusätzliche Reverse Proxy für explizit 443 vorhanden sein muss damit die Umleitung auch aufgelöst werden kann.

 

[Whoisfoxmulder]

??? - Hab ich noch nie gesehen . Du hast höchsten einen zusätzlichen Dienst, dem du eins deiner Zertifikate zuordnen kannst.
Du solltest dir im Vorfeld überlegen, welche Sub-Domains du jetzt und in Zukunft brauchst, und dann ein Zertifikat für deine Domain erstellen, das alle Sub-Domains als "Alternate Names" enthält. Wildcard ginge auch, aber das ist etwas aufwendiger anzulegen/zu pflegen.

Wahrscheinlich weil ich bei der Hauptdomain gesagt habe, dass es das Standardzertifikat sei. Ja das ist schön und gut, aber meine Dienste, welche ich via Subdomain erreichen möchte wachsen und schrumpfen. Daher ist der Weg (wenn auch unübersichtlich) wohl der von "luddi" beschriebene für mich

 

[Whoisfoxmulder]

Nein, damit wollte ich nur sagen dass du einmal versuchen solltest einen Eintrag explizit für HTTP und einen anderen explizit für HTTPS zu erstellen.
Wenn du natürlich andere listening Ports verwendest als 80 und 443 dann meinte ich in deinem konkreten Fall folgendes.

Reverse Proxy Rule:
a.) 80:49208
b.) 443:49208

Das ist eben die Frage ob der Port 49208 sowohl auf HTTP als auch auf HTTPS Anfragen reagiert.
Du scheinst ja das Problem zu haben dass wenn eine Anfrage über http:// (sprich Port 80) kommt dann diese in einem Timeout resultiert obwohl du eingerichtet hast alle http Anfragen auf HTTPS weiterzuleiten.
Deshalb meine Vermutung dass jetzt eine zusätzliche Reverse Proxy für explizit 443 vorhanden sein muss damit die Umleitung auch aufgelöst werden kann.

Also ich habe nun alle mit b) umgesetzt.

Testeshalber habe ich noch

c) 80:443 umgesetzt

Das funktioniert nun ebenfalls einwandfrei.
Ich zeige von 80 auf 443 und dort wird man dann sauber auf https umgeleitet.

Unschön, dass ich nun jeden Eintrag 2x machen muss, aber es funktioniert...

a) führt dazu, dass https nie aufgerufen wurde bei mir.

 

[luddi]

D.h. du hast jetzt eine Lösung gefunden die deiner Vorstellung zumindest in der Funktionsweise entspricht?

 

[Whoisfoxmulder]

Also ich habe nun alle mit b) umgesetzt.

Testeshalber habe ich noch

c) 80:443 umgesetzt

Das funktioniert nun ebenfalls einwandfrei.
Ich zeige von 80 auf 443 und dort wird man dann sauber auf https umgeleitet.

Unschön, dass ich nun jeden Eintrag 2x machen muss, aber es funktioniert...

a) führt dazu, dass https nie aufgerufen wurde bei mir.

Ich nehms zurück. Es funktioniert genau beim ersten Eintrag so mittels c)
Nach Recherche im Netz müsste man es mittels einem apache lösen.
Zitat:

It's a bit tricky to do but I had the same problem once and you need to set up webstation with apache (2.4) and put a virtual host on it. In this virtual host you set up a htaccess rule to rewrite http to https and put it on any free port. Then you set a a reverse proxy on http 80 to the virtual host port http and voila the http connection will be https (443). You maybe will need another reverse proxy (https) to the plex port (either http or https, doesn't matter)