Manuelle Konfiguration via ssh vs. Reverse Proxy

[2U1C1D3]

Hallo zusammen,
ich glaub, hier passt meine Frage am Besten rein.
Wie schon an anderer Stelle hier im Forum geschrieben, kann ich meine Syno von Außen nur über eine einzige Subdomain erreichen und muss sämtliche Dienste über den https-Port routen. Das war eine Sicherheitsvorgabe. Somit bin ich gezwungen mit "Subdirectorys" für die einzelnen Dienste zu arbeiten. Über "cloud.example.com" erreiche ich meine Syno-Drive-Anwendung, über "cloud.example.com/calendar" lande ich auf dem Kalender, usw. Das Ganze habe ich umgesetzt, in dem ich via ssh die Datei /etc/nginx/sites-enabled/server.forwarding.conf angelegt habe. In dieser Datei habe ich (exemplarisch) folgende Einträge:

server {
    listen 443;
    server_name cloud.example.de;

    location / {
       proxy_set_header        Host                $http_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        Upgrade             $http_upgrade;
       proxy_set_header        Connection          $connection_upgrade;
       proxy_intercept_errors  on;
       proxy_http_version      1.1;

       proxy_pass https://localhost:meinport/;
    }

    location /chefsache/ {
       proxy_set_header        Host                $http_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        Upgrade             $http_upgrade;
       proxy_set_header        Connection          $connection_upgrade;
       proxy_intercept_errors  on;
       proxy_http_version      1.1;

       proxy_pass https://localhost:5001/;
    }

    location /photo/ {
       proxy_set_header        Host                $http_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        Upgrade             $http_upgrade;
       proxy_set_header        Connection          $connection_upgrade;
       proxy_intercept_errors  on;
       proxy_http_version      1.1;

       proxy_pass https://localhost:nocheinport/;

Was sich im Detail hinter den Einträgen versteckt, weiß ich nicht; die Einträge sind durch jemanden erstellt worden, der mich hier ein wenig supported hat.
Der erste Eintrag führt mich direkt auf die Anwendung Drive. Hier soll Ottonormalverbraucher automatisch landen. Der zweite Eintrag bringt den Admin auf's DSM und der dritte Eintrag führt zur Photostation.

Jetzt habe ich auf einer anderen Syno einen Docker nach einem HowTo aus dem Internet installiert. Hierbei habe ich gesehen, dass ich exakt die gleichen Parameter über das DSM erstellen könnte Nämlich im Anwendungsportal unter Reverse Proxy, ff.
Getreu dem Motto "never change a running system" habe ich jetzt natürlich Angst, dass ich mit meiner Bastelei "auf's Ma_l" fall und die Syno, bzw. die funktionierende Konfiguration schrotte. Das kann ich mir nicht erlauben. Ebenso funktioniert es leider nicht, dass ich mein Spielchen auf der anderen Syno ausprobiere, weil hier die Umgebungsvariablen komplett andere sind.
Deshalb die Frage an euch: Verhalten sich die Einträge im Reverse Proxy exakt identisch zu den Einträgen in der selbst erstellten "server.forwarding.conf"?

Danggö für Rat und Meinung!

 

[Benares]

Der Reverse Proxy basiert eher darauf, dass man seine Dienst über mehrere DNS-Namen anspricht, wie etwa cloud.example.de, chefsache.example.de, photo.example.de usw. Steht nur eine Domain zur Verfügung (z.B. cloud.example.de) muss man das halt anders abfrühstücken und mit Alias-Namen arbeiten und das hinten anhängen (z.B. cloud.example.de/photo), wie in deinem Beispiel gezeigt.
Edit: Der Reverse-Proxy macht da im Prinzip nicht viel anderes, eben halt mit einer weiteren Datei pro Namen.
Was genau ist deine Frage?

 

[2U1C1D3]

Hallo @Benares ,
vielen Dank, dass du wieder auf mein Problem anspringst!

Meine Frage anders beschrieben:
Ist es möglich, dass ich das was ich mit der server.forwarding.conf erreiche, auch mit bereits zur Verfügung gestellten Mitteln aus dem Standard-Funktionsumfang des DSM erreiche, OHNE über die Konsole im System manipulieren zu müssen?

Wie du bereits sagst: Das mit den DNS-Namen geht über den Reverse-Proxy einwandfrei. Mit einem Alias, bzw. Subdir geht das jedoch nicht (also zumindest im Reverse-Proxy nicht, sondern eben nur über die konsolenbasierte Konfiguration von nginx).

 

[Benares]

Also zumindest für die Standard-Apps kannst du auch im Anmeldeportal einen Alias setzen. Aber im Hintergrund passiert dann auch nichts anderes.
Schau dich doch einfach mal in /etc/nginx/sites-enabled um.

 

[Ulfhednir]

Der Nginx ist ja der Reverse Proxy, der im Frontend von DSM angesprochen ist. Das Problem ist jedoch, dass das Frontend stark beschnitten ist und in der Regel keinen Alias / Subfolder zulässt. Entweder du popelst weiter per SSH an dem Nginx herum (der schlimmstenfalls kein Update übersteht) oder du verwendest einen anderen Reverse Proxy, mit dem du ohne Risiken experimentieren kannst.
Meine Empfehlung wäre hierzu Nginx Proxy Manager oder SWAG zu verwenden. Der Proxy Manager hat eine charmante UI.
SWAG ist mächtiger, hat kein wirkliches Frontend zur Konfiguration.

 

[2U1C1D3]

Hallo @Ulfhednir
neben dem Gefrickel mit der Arbeit auf der Konsole, ist das mit dem Update tatsächlich ein Big-Problem. Nachdem die Datei iwa mal weg war, backuppe ich sie bei jeder Änderung. Wir vermuten, dass es damals eben ein Update war.
Ich habe mir beide Empfehlungen von dir dazu angesehen. Naja, was soll ich sagen, NPM wäre mein Favorit. Mit SWAG wäre ich, glaub ich, über die Konsole besser dran. Das kenn ich wenigstens schon )
Kannst du mir Hilfe geben wie ich via NPM konfigurieren muss? Meine eigenen Gehversuche verlaufen im Sand und alles was im I-Net an How-To's zu finden ist, zielt auf Subdomains und nicht auf Subdirectorys ab...

Ich habe jetzt nämlich noch ein weiteres Problem festgestellt: Eine Anwendung welche im Docker läuft, kann ich über Einträge in der server.forwarding.conf nicht erreichen. Auch wenn ich den Dienst aus dem Docker (Portainer) ganz normal über das Adminstrationsnetzwerk über SYNO-IPort erreiche, wenn ich diesen Port nach o.g. Schema in der Datei mit aufnehme, heißt es "Synolgoy - Es tut uns Leid, die von Ihnen gesuchte Seite konnte nicht gefunden werden." Meine Anfrage, bzw. meine Einträge in der Datei führen also in's Leere. Ich vermute, dass es dabei dann am "localhostort" liegt. Weil der Docker ja eben nicht der localhost ist. Aber auch die IP vom virtuellen Docker-Netzwerk bringt kein Ergebnis.

 

[Ulfhednir]

Nichts NPM - reine Dockerlehre ist hier angesagt. Du wirst dich hier einfach durch die Installationshinweise durcharbeiten müssen.
https://github.com/linuxserver/docker-swag
https://docs.linuxserver.io/general/swag
https://www.linuxserver.io/blog/2020-08-26-setting-up-authelia

Wenn du SWAG installiert hast, findest du unter (nginx/proxy-confs) für etliche Anwendungen fertige .sample-Files (subfolder.conf.sample & subdomain.conf), die du beliebig anpassen kannst.

Kalkuliere mal für deine autodidaktischen Gehversuche einen Vormittag ein bis es denn mal rund läuft.

 

[2U1C1D3]

Kalkuliere mal für deine autodidaktischen Gehversuche einen Vormittag ein bis es denn mal rund läuft.

Das ist ne Antwort ganz nach meinem Geschmack: Klare Ansage und auch gleich noch Links wo ich mir die Info's rausholen kann
Hätte ich meine Frage früher gestellt, dann hätte ich wahrscheinlich ein bisschen mehr vom Wochenende gehabt...

Vielen Dank! Etz muss es nur noch funktionieren!