DSM 6.x und darunter DSM Port Hotel

[Fusion]

Was heißt "leitet nicht um"?

Ein Proxy ist keine Umleitung. Du redest nur mit dem Proxy und der Proxy mit dem Ziel. Die Antworten gehen auf dem umgekehrten Weg.
Du redest und siehst vom Client aus also nur die Adresse https://cloud.example.com und sonst nix.
Antworten sollte natürlich das Ziel bzw dessen Inhalt angezeigt werden.

 

[sub2010]

Dann habe ich es noch nicht verstanden. Hier noch mal ein Bild.
Ich dachte ich habe es verstanden ?

 

[blurrrr]

Jo, so in der Art, kannste dann z.B. via Subdomain "dsm1.example.com" (NAS1, localhost:5001) und "dsm2.example.com" (NAS2, int.-ip:5001) machen. Je nach Subdomain kannste dann entscheiden, wo Du was ansprechen willst.

 

[sub2010]

Muss ich auf dem NAS 1 noch Einstellungen vornehmen?
Denn ich bekomme im Webbrowser und in der Anwendung Chat die Verbindung fehlgeschlagen.

 

[Fusion]

Ja, vom Weg her schon.
Nur z.B. dynDNS Adresse zeigt bei IPv4 auf den Router (ipv4 NAT) und bei IPv6 auf die NAS (Router Portfreigabe).
Aber wichtig eben, dass alle dienste.example.com per CNAME auf die dynDNS verweisen.

Portfreigabe 5000/5001 brauchst du gar nicht.

Je nachdem wie du auf NAS 2 den Chat eingerichtet hast (Systemsteuerung > Anwendungsportal) musst du auch das Ziel des Reverse Proxy passend wählen.
Auch die Zertifikate per Lets Encrypt für chat.example.com richtest du auf NAS 1 ein und ordnest sie unter Systemsteuerung > Sicherheit > Zertifikate > Konfigurieren dem Reverse Proxy Dienst "chat.example.com" zu.

Und zuerst vielleicht in einem Browser von extern testen.
Dann hast exakte URL und Fehlermeldungen und kannst eher schließen wieso die Chat App dann nicht will.

 

[Benares]

Dein Bild passt ganz gut. Alles läuft über eines der NASe und wird, namensabhängig, von dort weiterverteilt (auch wenn es lokal sein sollte).
Ggf. kann es Probleme geben, wenn dass Ziel in seinem html-Code in den Links wieder andere Namen verwendet. Da muss man halt schauen, was auf dem Client an Code ankommt und auf dem Proxy ggf. dann noch Rewrite-Rules definieren, die den Code ändern. Das geht m.W. aber leider nur per Konsole.

 

[stefan_lx]

so würde ich das konfigurieren:
Portfreigabe auf der Fritz nur 443!, sonst nichts und 443 wird weitergeleitet auf "Haupt-NAS" NAS1... dort landen die Anfragen für cloud.deinedomain.de (und alle anderen CNAME-Anfragen)... auf NAS1 bei den Anwendungen die bei benutzerdefinierten Domains des jeweiligen Dienstes einfach chat.deinedomain.de, drive.deinedomain.de und moments.deinedomain.de aktivieren... weil hier die syno-eigenen Dienste schon einen eigenen Reverse-Proxy mitbringen ist das so rum praktischer..

Jetzt auf NAS1 den Reverseproxy konfigurieren und dort als Ziel jitsi.deinedomain.de eintragen (mit https und Port 443) und als Ziel NAS2 (die IP-Adresse), ob beim Ziel jetzt http/80 der https/443 genommen wird ist egal, geht prinzipiell beides... würde ich das nehmen auf das jitsi gerade "hört"...

Solltest Du noch DSM freigeben wollen, kannst Du für NAS1 z.B. dsm1.deinedomain.de nehmen und im Reverse Proxy als Ziel localhost mit http und Port 5000 oder https mit Port 5001 angeben... für NAS2 unterscheidet sich das nur Feld Hostname, weil Du dann die IP von NAS2 einträgst...

Klar soweit?

Stefan

 

[sub2010]

@stefan_lx vielen Dank für die Erläuterung. Ich habe die Idee verstanden, bin mir aber bei der Umsetzung noch nicht sicher . Gib mir einen Tag, dann gebe ich dir ein Feedback

 

[Thonav]

…und zum Schluss noch die entsprechenden Zertifikate hinzufügen. ?

 

[Aevin]

... das ist ein nicht zu unterschätzender Punkt, wenn das "übersehen" wird, klappt es nicht mit dem Reversezugriff und man sucht sich wund

 

[sub2010]

Hallo Zusammen,

vielen Dank für eure Geduld. Da habt ihr mir eine neue Welt mit eröffnet .
Damit eure Mühe nicht umsonst war, habe ich eine kleine Doku erstellt.
Allerdings stellen sich mir noch zwei Fragen .


1. Domain Provider Einstellungen


2. Router (BSP: FritzBox) können die Ports von der DSM gelöscht werden, da die Weiterleitung über den Reverse Proxy erfolgt
(s. Punkt 3)


3. Proxy Einstellungen


3.1 DynDNS Einstellungen

4. Einstellungen am Ziel
--- Frage ---
Werden so alle Verbindungen auf https umgeleitet?


4.1 DNS Server (falls ihr lokal einen von Synology benutzt)
--- Frage ---
Greife ich dann überhaupt über mein lokales Netzwerk zu?


5. Anwendungen

 

[Fusion]

4) nein, nicht global alle Verbindungen. Aber für die meisten Syno-Anwendungen reicht es vermutlich.

5) nein, lokal bitte nur sub.example.de bearbeiten. Nix mit dynDNS oder CNAME. Einfach normale Resource Records.
Bsp. chat.example.com > A-record > 192.168.178.20 (lan IP auf der der chat Server läuft)

 

[sub2010]

Danke dir!

Erzwingen kann ich es nicht, oder?


Ich hab da noch ein Frage
Ich habe einen Plex Server am laufen. Aber dieser arbeitet nicht korrekt mit dem Port 443.
Manchmal ist der Port in Ordnung, manchmal ist der Fernzugriff deaktiviert.


Reverse Proxy

 

[Fusion]

Vergiss das was dir Plex bei Remote access anzeigt. Erstens liegt die Erkennung nicht immer richtig und zweitens ist sie falsch zusammen mit dem Reverse Proxy.
Der Proxy lauscht auf plex.example.com und nicht auf ip:443
Du kannst den Remote Access sogar deaktiveren.

Du musst nur unter Plex > Einstellungen > Netzwerk > "Custom server access URLs" deine "https://plex.example.com:443" (genau so, ohne Gänsefüßchen) eintragen. Dann wird das in deinem Plex Konto für deine verbundenen Geräte so veröffentlicht.
Die 443 Weiterleitung bringt dich zur NAS und der Abgriff des Hostname bringt dich dann zum PMS.

So sieht das hier aus, und funktioniert trotzdem wunderbar von überall.


Bezüglich benutzerdefinierter Header sind folgende empfohlen

Spoiler

proxy_set_header        Upgrade            $http_upgrade; 
proxy_set_header        Connection            $connection_upgrade; 
proxy_set_header        Host            $host; 
proxy_set_header        X-Real-IP            $remote_addr; 
proxy_set_header        X-Forwarded-For            $proxy_add_x_forwarded_for; 
proxy_set_header        X-Forwarded-Proto            $scheme; 
proxy_set_header        Sec-WebSocket-Extensions            $http_sec_websocket_extensions; 
proxy_set_header        Sec-WebSocket-Key            $http_sec_websocket_key; 
proxy_set_header        Sec-WebSocket-Version            $http_sec_websocket_version;

Bezüglich deiner allgemeinen http > https Umleitung.
Muss man halt schauen wie welcher Dienst reagiert. Wenn es irgendwo nicht umgeleitet wird muss man eben nacharbeiten.
Das kann z.B. eine .htaccess im /web Ordner sein.

Spoiler

RewriteEngine On

# only ssl
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R,L]

Eine globale Einstellung für ALLES gibt es nicht.

 

[sub2010]

Danke für die Hilfe, ich hatte eine Zwischen Ding gerade hinbekommen.

Und zwar, hab ich die Einstellung:
- Plex > Einstellungen > Netzwerk > "Custom server access URLs" deine "https://plex.example.com" gesetzt, und den Port unter Remote Access auf 443 gesetzt. Scheint genau das zu sein, wie es auch funktioniert.
Die anderen Einstellungen nehme ich mit, ich muss mich schlau machen ob ich diese brauche .

4) nein, nicht global alle Verbindungen. Aber für die meisten Syno-Anwendungen reicht es vermutlich.

5) nein, lokal bitte nur sub.example.de bearbeiten. Nix mit dynDNS oder CNAME. Einfach normale Resource Records.
Bsp. chat.example.com > A-record > 192.168.178.20 (lan IP auf der der chat Server läuft)

Ich habe die A Record´s im lokalen DNS Server gesetzt. Genau wie oben beschrieben.
Jetzt bekomme ich aber bei meinen Anwendungen (Chat) Probleme. Fehlerhafte Verbindung. Wie kann das denn sein?

 

[stefan_lx]

zu Deinem Bild in #31...
ich würde der Reverse Proxy auf die 4 (also NAS1) setzen, weil dort - vermute ich jetzt - chat, drive usw. laufen sollen, den Reverse Proxy würdest Du aber nur für plex und ggf. für DSM selber benötigen... oder gleich alles auf der 3 (NAS2) aktivieren... die Adresse von Chat in Bild 5 sollte eigentlich chat.deinedomain.de heissen.... oder?

Stefan

 

[sub2010]

An einem Umzug habe ich auch schon gedacht. Bin mir aber noch unsicher wo mehr läuft...
Nein, dass war schon richtig, meine Idee ist: Das alle meine genutzten Anwendungen wie Chat Moments... über die URL cloud.exmaple.de aufgelöst werden. So ist das für den Benutzer einfacher, sich diese zu merken.

 

[sub2010]

4) nein, nicht global alle Verbindungen. Aber für die meisten Syno-Anwendungen reicht es vermutlich.

5) nein, lokal bitte nur sub.example.de bearbeiten. Nix mit dynDNS oder CNAME. Einfach normale Resource Records.
Bsp. chat.example.com > A-record > 192.168.178.20 (lan IP auf der der chat Server läuft)

Gilt das auch wenn der Proxy auf NAS2 läuft und die Anwendung auf NAS1?

 

[stefan_lx]

entweder hast Du für jeden Dienst einen eigenen Namen (cloud.deinedomain.de, chat.deinedomain.de, drive.deinedomain.de usw.) oder Du musst an cloud.deinedomain.de noch /drive, /chat anhängen und das in der Systemsteuerung der Syno bei den Diensten aktivieren...

Stefan

 

[sub2010]

Ich verweise ja auf die DSM. Und somit auf alle Apps.