Reverse Proxy auf DS220+ - Website wird nicht angezeigt

[p-mob]

Hallo Leute.
Ich wende mich mal hier ans Forum. da ich ein komplexeres Problem mit meiner neuen DS220+ habe.
In den letzten Tagen habe ich meine ganzen Applikationen die ich vorher auf VMWare laufen hatte auf die DS migriert. Entweder nutze ich dafür Applikationen von Synology oder Docker Container.
Hat soweit alles super geklappt, bis auf eine einzige Sache.
Ich habe Airsonic als Docker Container laufen. Dieser ist in meinem Netz unter der IP Adresse 192.168.1.1 (Die DS220+) auf Port 4040 erreichbar und funktioniert.
Nun soll das ganze über den Reverse Proxy (Synology Anwendungsportal) mit einem Lets Encrypt Zertifikat veröffentlich werden.
Die Anforderung des Zertifikats und die Bindung ging auch ohne weiteres. (Bei der Konfig hab ich mich hier orientiert: Synology Reverse Proxy Server Set-Up — GRHMLGGT (grahamleggat.com))
Nur kann ich die Website von extern leider nicht mit dem Browser aufrufen. Seltsamerweise funktioniert es über die App (Subsonic, Ultrasonic etc.) ohne Probleme.
Meine Logik ist folgende:
- Fritzbox nimmt Port 443 (HTTPS) an
- Port wird an die interne IP des NAS Port 444 weiter geleitet bzw umgebogen, da ja leider 443 vom System belegt ist (siehe: Anwendungsportal | Synology Inc.)
- Das Anwendungsportal/Reverse Proxy der Synology nimmt auf Port 444 an, und gibt das an "localhost" (ist die oben genannte 192.168.1.1:4040) weiter
Wie gesagt, seltsamerweise funktioniert der Aufruf von extern per App, aber nicht per Browser.
Wäre toll, wenn mir hier jemand weiter helfen könnte.
Danke schon mal!
Screenshots hab ich auch ein paar mit ran, evtl. hilft das.

 

[Benares]

Ich betreibe nextcloud in Docker auf ähnliche Weise. Da musste ich zusätzlich unter /usr/local/etc/nginx/sites-enabled noch eine Datei nextcloud-redirect.conf (Name ist egal, nur .conf ist wichtig) mit folgendem Inhalt anlegen:

server {
        listen 80;
        server_name nextcloud.meinedomain.de;

        return 301 https://$host$request_uri;
}

Bei dir wär das dann halt Port 4040 und server_name xxx.mooo.com, passend zur Reverse-Poxy-Konfiguration.
Meines Wissens bewirkt das, dass der Code von http in https umgeschrieben wird.

Das Zertifikat muss xxx.mooo.com auch in der Liste "Alternative Antragstellername" enthalten

 

[p-mob]

Okay. Ich hab mir mal ne "sites.conf" erstellt. Allerdings bekomme ich beim reinkopieren per WinSCP die Meldung "Permission Denied"...

 

[Benares]

Musst halt per putty/ssh/telnet als root machen. Anmeldung als admin, dann "sudo -i". Etwas vi-Kenntnisse können auch nichts schaden.

 

[Fusion]

Lass den reverse proxy einfach auf 443 lauschen... Das geht parallel. Unterscheidung anhand des Hostnamens.

 

[p-mob]

Das ganze komplett auf 443 umzustellen hat nix geholfen. Ist auch lt. der Doku von Synology (siehe mein Startbeitrag) nicht so gedacht.
Die .conf Datei per VI...
Das mach ich morgen.

 

[Fusion]

Entschuldige, aber ich glaube du hast die Anleitung da zu eng ausgelegt.
Reverse Proxies sind genau dafür gedacht um sie z.B. als Proxy vor einen Docker Container zu setzen.
Das ist übliche Praxis und funktioniert, eben damit man sich z.B. nicht innerhalb des Containers um SSL Zertifikate etc. kümmern musst.
Habe ich so mit einer Hand voll Dienste am Laufen, alles auf 443 und Trennung nach Server Hostname.
Es kommt natürlich noch dazu welche Dienste man hinter dem Proxy betreibt, ob die mit Proxies können. Oft geht es direkt, manchmal muss man passende Header noch im Proxy setzen, oder einfach mal /airsonic hinten an den Namen hängen im Browser (was die APP vielleicht von selbst macht ohne es dir anzuzeigen) und in einzelnen Fällen geht es dann mit den Syno Mitteln wirklich nicht.

Edit:
https://airsonic.github.io/docs/proxy/prerequisites/

 

[p-mob]

Ist das nicht eine Trennung nach Hostname, so wie ich das konfiguriert habe?

 

[Fusion]

Na ja, du sagst "laut Synology nicht dafür vorgesehen". Wo du das heraus liest ist mir schleierhaft.

Den Rest habe ich dir ja schon geschrieben und verlinkt.
Teilweise eben nur die URL im Browser, dass es mit example.com/airsonic geht, ohne nicht.
Oder dass das Ziel auf 127.0.0.1 geht anstatt localhost (IP statt Namen).
Es an den passenden Headern für den Proxy fehlt.
...

 

[p-mob]

Also ein /airsonic am Ende wars nicht.
Wenn ich die Website zum Test von meinem Smartphone aufrufe (also von extern via https://domain.xxx) bekomme ich immer eine Fehlerseite das http://domain.xxx:5000 (!!!) nicht erreichbar ist.
Erstens: Warum http und nicht https?
Zweitens: Warum Port 5000?
Wie geschrieben werd ich morgen erst mal versuchen so eine .conf Datei per VI anzulegen, dann sehen wir weiter.

 

[Fusion]

Ist example.com eine dynDNS?
Oder eine Domain per festem A-Record auf die WAN IP deines Routers?
Oder per CNAME record auf eine dynDNS gesetzt?
Oder eine irgendwie geartete http Weiterleitung beim Domain-Provider?
Ist example.com außer im reverse Proxy noch so an irgendeiner anderen Stelle im DSM, Web Station oder webserver config Dateien eingetragen?

Smartphone ist synonym für Mobilfunknetz, oder hängt es zu diesem Zeitpunkt im WLAN?

Die Umleitungserscheinung taucht normal (bei Werkseinstellungen) auf, wenn die Web Station nicht installiert ist und die Anfrage auf Port 80 kommt. Dann greift eine automatische Umleitung auf 5000 (ohne Portweiterleitung eben nicht erreichbar Fehler)
Welche Konfiguration aktuell bei dir dafür sorgt, dass eine Anfrage via 443 dann auf DSM http landet kann ich dir aus der Ferne so nicht aus dem Stand beantworten.

 

[p-mob]

Namensauflösung mache ich mit Freedns. Ist ein Anbieter für dynamisches DNS.
Das es einen CNAME braucht um das rückwärts aufzulösen, hatte ich dann auch noch gesehen.
Ist nun angelegt, denke aber ich muss das Lets Encrypt Zertifikat dann erneuern.

Du hast recht, Smartphone heißt Mobilfunknetz, WLan ist natürlich in dem Moment aus, sonst bin ich ja weiterhin im internen Netz.
Ich nutze das einfach nur um von extern den Aufruf mit dem Browser zu testen, und eben mit der App.

Eine Sache noch am Rande:
Das hat sogar schon mal sauber funktioniert, allerdings hatte ich da einen Docker Container mit Subsonic statt Airsonic laufen.
Leider hab ich aber keinen Container gefunden, der FFMPEG bereits integriert hatte, und bin deswegen zu Airsonic gewechselt.
Fazit: Scheinbar funktioniert die Konfig an sich schon, aber Airsonic hat da irgend ein Problem.
Nur scheitere ich leider an der für mich doch recht komplexen Konfig von NGinx, besonders da ich da noch nie was damit zu tun hatte.

 

[Penthys]

Hab mal Airsonic im Docker eingerichtet und mit Reverse Proxy ausprobiert. Funktioniert soweit mit Zugriff auf die Oberfläche und Streaming. Also muss schon gehen

 

[p-mob]

@Penthys
Ich wüsste jetzt nicht was ich verkehrt gemacht haben sollte.
Einrichtung ist wie oben schon beschrieben.
Die Dockerversion von Airsonic ist die hier: linuxserver/airsonic - Docker Hub
Was extrem komisch ist, das die Apps funktionieren, aber die Website nicht. Ich bin echt ratlos.

 

[Penthys]

Das linuxserver-Image habe ich auch benutzt. Wo Synology sagt, dass man 443 nicht verwenden soll, sehe ich nicht. Extra wieder einen Port aufreißen ist nicht sehr sinnvoll. 80/443 gehen an den Server und der sortiert das dann schon. Hast du JAVA_OPTS=-Dserver.use-forward-headers=true gesetzt? Laut der Hub-Seite zu linuxserver-airsonic ist das bei manchen Reverse Proxy nötig. Ich habe es mit eingetragen und auch die Websockets im Reverse Proxy aktiviert (Benutzerdefinierte Header). Grundsätzlich auch die http->https Umleitung wie von @Benares bereits beschrieben eingerichtet, aber das geht schon in Richtung Bequemlichkeit und hat mit der Funktion nichts zu tun.

Docker:

Reverse Proxy:

 

[Penthys]

Auf der Github-Seite zu airsonic-advanced steht, dass die Websockets für Reverse Proxy wichtig sind. Daher hier nochmal genau um was es geht.
Bei Erstellen auf den Pfeil rechts klicken und WebSocket auswählen. Damit bekommt man die beiden Zeilen darunter erstellt. Das Upgrade nötig sein soll wurde da explizit erwähnt.

 

[p-mob]

@Penthys
Mensch, tausend Dank.
Das wars. Läuft!
Leider bin ich heute erst zum probieren gekommen.
Danke, echt! Ich würde Dir gern ein virtuelles Bier/Kaffee ausgeben.
Hab mir da echt nen Wolf gesucht.