Unraid, Nextcloud und swag im Docker, Zugriff über nicht-443-Port

[mr hyde]

Hallo zusammen.

Ich betreibe seit Jahren eine nextcloud Instanz, zuletzt auf ubuntu 18.04 mit apache2 auf dem Heimserver, Zugriff erfolgt über eine no-ip dyndns mit Portfreigabe im router 33xxx auf 443, URL ist dann https://meine.noip.domain:33xxx/nextcloud .

Das hat über Jahre prima funktioniert.

Jetzt setze ich einen unraid Server auf, und möchte das gleiche wie oben mit den nextcloud und swag Dockern von linuxserver.io machen. Schwierigkeit 1: ich bin Docker-Anfänger. Schwierigkeit 2: bisher war es ein apache2 webserver, nun ist es im swag Docker ja nginx.

Ich habe mich an diesen Guide gehalten:
https://medium.com/@chrismorris_822...on-unraid-using-letsencrypt-831905d94f7d#34c4
mit dem Unterschied, dass ich nicht die nextcloud.subDOMAIN.conf sondern die nextcloud.subFOLDER.conf benutzt habe (mit den in der sample.conf beschriebenen Änderungen an der config.php von nextcloud.

Nach etlichen Stunden und nach Lösung etlicher Probleme bin ich nun soweit. Es klappt!

Der Zugriff über WAN Port 443 mit Portfreigabe im Router (external Port 443) klappt mit der URL https://meine.noip.domain/nextcloud.

Was aber NICHT klappt, ist der eigentlich von wir gewünschte Zugriff über WAN Port 33xxx mit Portfreigabe im Router (external Port 33xxxx) mit der URL https://meine.noip.domain:33xxx/nextcloud , so, wie es auf dem ubuntu server ging.
Ich bekomme dann ein "ERR_CONNECTION_CLOSED" im Browser beim Zugriffsversuch.

Ich schätze, ich muss irgendwas in der nginx config anpassen, weil der webserver vermutlich die Portnummer in der URL nicht richtig verarbeitet. Ich habe aber keinen Plan was... gestern Nacht um 2 Uhr habe ich dann aufgehört zu googeln.

Kann jemand eine Idee oder kann mir einen weiteren Ansatzpunkt geben?

 

[ZerHaKKeR]

Port 33xxx in der Unraid firewall für nginx freigegeben ?
Und oder darf nginx auf port 33xxx lauschen ?

 

[Vorgartenzwerg]

Hi, ich habe zwar keine Erfahrung mit Unraid und weiß leider nicht genau was swag Docker ist, aber ich habe selbst eine Nextcloud + Docker + Nginx Konfiguration am laufen.
Dabei habe ich den Nginx Reverseproxy in einem separaten Container vor die Nextcloud geschalten. Dieser löst die TLS Verschlüsselung auf und leitet die Anfragen an den aus dem Internet nicht erreichbaren Nextcloud Container weiter. Dabei kannst du auch den Port verändern, also "listen 33xx" im Proxy und dann "proxy-pass ..." an deinen Nextcloud Container. Für die Konfiguration kannst du dich erstmal an den NGINX Part von hier halten: https://breuer.dev/tutorial/Setup-NextCloud-FrontEnd-Nginx-SSL-Backend-Apache2.html, allerdings fehlen noch die Konfigurationen für calDAV carDAV: https://docs.nextcloud.com/server/1...ation_server/reverse_proxy_configuration.html
Da die Nextcloud nicht weiß auf welcher URL sie läuft, musst du ihr die entsprechenden URLs in der Config unter "trusted_domains" mitgeben.

 

[mr hyde]

Vielen Dank für eure Antworten.

Swag ( https://hub.docker.com/r/linuxserver/swag ) enthält nginx webserver, reverse-proxy und certbot (lets encrypt.

Ich sollte klarstellen, dass der Port 33xxx nur auf der WAN Seite eine Rolle spielt. Schon im Router wird der auf 443 umgeleitet, sodass sowohl der Host-Port (Unraid) als auch der Docker-Port (swag/nginx) 443 lautet.
Also Router extern --> Router intern bzw. Host (Unraid) --> Docker mit nginx
... 33xxx -> 443 -> 443 (diese Config ist gewünscht, geht aber nicht)
... 443 -> 443 -> 443 (diese Config geht)


listen 33xxx in der nginx config bringt also (nach meinem schmalen Verständnis) nix, weil sich der listen... Port auf den Docker bezieht, und der ist ja in beiden Varianten 443.

Ebensowenig nützen würde dann ein Öffnen von 33xxxx in Unraid...

Oder hab ich da einen Denkfehler?

 

[Vorgartenzwerg]

Ah verstehe. Das Problem ist vermutlich, dass dein Reverseproxy nicht weiß, dass er extern auf 33xx horcht, nachdem alles auf 443 ankommt. Die Antwort verweist also auch auf 443, der aber nicht in deiner Firewall offen ist. Am Besten verwendest du 33xx -> 33xx -> 443 oder so ähnlich.

In der Reverseproxy Config hast du im Serverblock vermutlich

proxy_set_header Host $host;

stehen, so weiß die Anwendung dahinter, wo das ganze her kommt. Das macht deine Firewall nicht. Ich würde deshalb den Reverseproxy das Portumbiegen machen lassen.

Ich machs bei mir z.B. immer so: Reverseproxy terminiert alles was reinkommt (egal welcher Port), löst eventuell TLS Verschlüsselungen auf und leitet dann alles an die entsprechenden Dienste dahinter weiter. wenn es blankes tcp/udp ist, kann man dafür z.B. das Stream Modul statt dem http Modul verwenden.