staging.inyokaproject.org

Hallo Ubuntuusers Forum,

Ich bin neu hier. Meine ersten Erfahrungen habe ich mit einem Raspberry Pi gemacht. Da der Speicherplatz begrenzt ist und einige Dinge dort bereits laufen, habe ich mir ein Intel NUC gekauft und mit Ubuntu aufgesetzt. Ich habe beide Systeme so eingerichtet, dass ich über SSH und RDP auf die Server zugreifen kann. Nun komme ich zu meinem aktuellen Problem, wo ich nicht mehr weiter komme:

- Auf dem Raspi läuft ein Webserver (Port 80 & 443) der muss weiterlaufen... - Auf dem NUC möchte ich nun ein Nextcloud Server einrichten, welcher ebenfalls über Port 80 & 443 läuft.

Die Ports 80 bzw. 443 kann ich ja nur einmal weiterleiten. Nun habe ich nach einer Lösung gesucht und bin auf eine Möglichkeit (Reverse Proxy) gestossen, um das Problem allenfalls zu lösen.

https://indibit.de/reverse-proxy-mit-nginx-mehrere-server-hinter-einer-ip-per-subdomain-ansprechen/

Ist das das richtige Vorgehen, um mein Problem zu lösen? Oder wie kann ich meine Anforderung umsetzen? Ich bin daran den nextcloud auf dem NUC gemäss Annleitung: https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-nextcloud-on-ubuntu-22-04 zu installieren. Beim Punkt "Option 1: Setting Up SSL with Let’s Encrypt" kommt dann die Frage:

2. You must have the domain name(s) for which you want certificates
   pointing at the external IP address of this machine.

3. Both ports 80 and 443 on the external IP address of this machine
   must point to this machine (e.g. port forwarding might need to be
   setup on your router).

Diese kann ich leider nicht mit Ja beantworten, da die Ports in meinem Fall ja auf den Raspi weitergeleitet werden. Ich freue mich über eure Hilfe. Danke im Voraus.

Hallo und willkommen auf uu.de!

Mit Nginx habe ich noch nicht viel gemacht, daher mal der generelle Weg:

• Router mit Portfreigabe bspw. 192.168.2.11:80 und :443 auf einen der Server

• Dieser ist dein „Haupt-“Webserver und muss auf den zweiten Webserver im internen Netz weiterleiten (Proxy) und auch die Antworten verarbeiten

• Bei Apache nennt sich das ProxyPass und ProxyPassReverse. Beispiel:

  …
  ServerName weiterleitung.server.tld
  …
  ProxyPass http://192.168.2.22:12345/
  ProxyPassReverse http://192.168.2.22:12345/
  …

  würde Anfragen an 'weiterleitung.server.tld' an besagte IP/Port weiterleiten und ebenfalls Antworten davon zurückschicken = Proxy.

Dein Zertifikat brauchst du dann nur für Server .11, egal ob da Server .22 hintendran hängt oder nicht.

Hallo,

Danke für die Rückmeldung. So habe ich das bis jetzt auch verstanden. Was ich noch nicht ganz verstehe ist, wie der Proxy die Anfrage von nextcloud dann "erkennt" und an die richtige interne IP weiterleitet.

- Meine öffentliche Adresse ist über no-ip geregelt. xxx.dyndns.net - Die beiden Ports 80 & 443 sind auf den Raspi per Portweiterleitung des Routers weitergeleitet. - Gemäss nextcloud anleitung, kann ich mich danach über die URL, also in meinem fall xxx.dynds.net einwählen:

Step 5 – Logging in to the Nextcloud Web Interface
Now that Nextcloud is configured, visit your server’s domain name or IP address in your web browser:

https://example.com

Da diese URL jedoch auf den Webserver auf dem Raspberry pi zeigt, weiss ich nicht, wie man nextcloud öffnen soll bzw. wie der Proxy merkt, dass ich jetzt auf nextcloud zugreifen will und nicht auf die Webseite..?

Ich hoffe man versteht was ich meine

Könnte das über die config.php von nextcloud gelöst werden? Habe hier ein Beitrag gefunden:

https://help.nextcloud.com/t/nextcloud-with-apache-reverse-proxy/19742

I’m coming back to you for this problem, it’s solved…
My Config in config.php is
’overwritehost’ => ‘app.***.net’,
‘overwriteprotocol’ => ‘https’,
‘overwritewebroot’ => ‘/nextcloud’,
‘overwritecondaddr’ => ‘^192.168.1.3$’,
‘overwrite.cli.url’ => ‘https://app 188.***.net/nextcloud/’,

192.168.1.3 is IP of my reverse Proxy
192.168.1.5 is IP of my Nextcloud server

Configuration of my Apache Reverse Proxy :
ProxyPass /nextcloud http://192.168.1.5/nextcloud 56
ProxyPassReverse /nextcloud http://192.168.1.5/nextcloud 56
ProxyPassReverseCookiePath /nextcloud /nextcloud

So wie ich das verstehe, könnte ich dann z.B. über die url xxx.ddns.net/nextcloud, welche danach vom config.php file durch die interne ip des nextcloud servers ersetzt würde den zugriff regeln?

Ich möchte es erst verstehen, bevor ich hier die Config Files anpasse und dann nichts mehr geht 😐

magcat schrieb:

Da diese URL jedoch auf den Webserver auf dem Raspberry pi zeigt, weiss ich nicht, wie man nextcloud öffnen soll bzw. wie der Proxy merkt, dass ich jetzt auf nextcloud zugreifen will und nicht auf die Webseite..?

Das (aus meiner Sicht) einfachste ist eine subdomain zu nutzen. Ob diese dann intern auf eine Nextcloud zeigt oder sonst wo hin ist dabei egal, sie muss nur von außen erreichbar sein. Inwiefern das mit deinem DynDNS funktioniert, kann ich aber nicht abschätzen.

Bspw: hat der Hauptserver dann meinedomain.tld und die Subdomain wolke.meinedomain.tld. Beide Anfragen muss der Webserver beantworten und Mithilfe von virtual hosts korrekt auflösen (was über die internen Proxys läuft). Die IP ist dabei gleich, die Unterscheidung findet nur im Webserver statt.

Schau dir Docker-Beispiele an, bspw. unter https://github.com/nextcloud/docker. Dort läuft im Docker-Container ein Webserver, der lokal auf 127.irgendwas oder 10.irgendwas lauscht. Der wird mit ReverseProxy im Haupt-Webserver behandelt und bekommt dessen Zertifikat.

Vielleicht findest du da ein konkreteres Beispiel das deinem Setup entspricht. Ich könnte dir meine Konfiguration zwar zukommen lassen, allerdings ist meine Cloud lokal beschränkt und ohne Internetanbindung und daher für dein Vorhaben ungeeignet. Funktioniert aber genau so. Aufgelöst wird subdomain.localserver.tld, per Apache (in meinem Fall) mit obigen ReverseProxy einträgen auf eine Docker-Instanz umgeleitet, die innerhalb einen Nginx verwendet. Auf dein Setting übertragen würde also der Raspi die Weiterleitung vom Router bekommen, dessen Webserver den Proxykram beinhalten und deine auf dem anderen Server laufende Nextcloud nur lokal lauschen.

Inwiefern das mit deinem DynDNS funktioniert, kann ich aber nicht abschätzen.

Mit no-ip.com kann man nur einen Hostnamen angeben. also xyz.ddns.net und nicht wolke.xyz.ddns.net. Das wäre ja das was du meinst mit subdomain, richtig?

Was ich jetzt aber unter no-ip gesehen habe, ist, dass es hier eine Option gibt, welche "Web Redirect" heisst. Die Beschreibung lautet: "Ein Web-Redirect ermöglich die Umleitung eines Hostnamens auf eine URL oder IPv3-Adresse an einem bestimmten Port."

Das wäre doch genau, das was ich versuche einzurichten...(?) Da könnte ich den Web Redirect auf irgendeinen Port setzen und diesen dann im Router auf den zweiten Server weiterleiten...? Das wäre ja das einfachste?

Ansonsten, was denkst Du über die Möglichkeit das ganze über die config.php von nextcloud zu steuern?

hmm, jetzt bin ich grade ein bisschen verwirrt. Hab jetzt folgendes gemacht:

- Im Router Port 4444 auf den Port 80 des zweiten servers umgeleitet und Port 4445 auf Port 443 des zweiten Servers. - wenn ich nun "xyz.ddns.net:4444" eingebe, wird mir die nextcloud Seite mit dem Hinweis, dass der Domain noch nicht auf der "trusted Liste" steht angezeigt. → Also im Prinzip das was ich möchte. 😇 - Mit https:// bzw. Port 4445 (443) funktioniert es noch nicht. Da fehlt wohl noch das Zertifikat..?

Ist das ein guter Weg, diese Umleitung so zu machen? Und Falls ja, kann ich nun auf dem Server 2 das SSL - Zertifikat für nextcloud installieren und das sollte dann funktionieren? Oder spricht da was dagegen, den zweiten Server über einen selbst definierten Port anzusprechen?

Ich habe auch die ssh und xrdp Umleitung für den zweiten Server so umgeleitet (also über eine hohe Port Weiterleitung) Jetzt vermute ich, dass das sicherheitstechnisch nicht die beste Variante ist? Wäre die saubere Lösung hier auch die Lösung über den Proxy? Habe mich bis jetzt noch nie mit einem Reverse Proxy befasst, daher die vermutlich blöde Frage?

magcat schrieb:

Inwiefern das mit deinem DynDNS funktioniert, kann ich aber nicht abschätzen.

Mit no-ip.com kann man nur einen Hostnamen angeben. also xyz.ddns.net und nicht wolke.xyz.ddns.net. Das wäre ja das was du meinst mit subdomain, richtig?

Richtig. Das wäre das sinnvolle vorgehen, womit du dann direkt virtual hosts unter der Subdomain ansprechen könntest. Wenn das nicht funktioniert, wird das ganze etwas kompliziert, weil du dann mit adresse.ddns.net/wolke arbeiten müsstest, was über sowas wie mod_alias gehen könnte. Habe ich aber so auch noch nie verwendet. Wäre dann sowas wie

<VirtualHost *:80>
	ServerName xyz.ddns.net
	Redirect /wolke http://cloud.localer.server
</VirtualHost>

<VirtualHost *:80>
	ServerName cloud.localer.server
        ProxyKram…
</VirtualHost>

Was ich jetzt aber unter no-ip gesehen habe, ist, dass es hier eine Option gibt, welche "Web Redirect" heisst. Die Beschreibung lautet: "Ein Web-Redirect ermöglich die Umleitung eines Hostnamens auf eine URL oder IPv3-Adresse an einem bestimmten Port." Das wäre doch genau, das was ich versuche einzurichten...(?)

Ich glaube dann schreiben wir aneinander vorbei.

Mein Gedanke war so: Du hast von außen nur einen Webserver erreichbar. Den Pi unter xyz.dns.net:443 und wahlweise :80 (für certbot). Dieser bietet dann die Cloud neben seiner anderen Webserver-Tätigkeit an, ursprünglich gedacht als {Reverse,}Proxy, jetzt mit Redirect/Alias und ggf. zusätzlichem Proxy. Der Zweitserver.nur.lokal wäre dann ebenfalls unter 80/443 erreichbar, aber eben nur lokal über seine IP, einem lokalen DNS oder einem Eintrag in der /etc/hosts, nicht aber von außen. Für den Zugriff von außen ist es ja egal, was im internen Netzwerk passiert. Du kannst ja auch bspw. die Cloud auf dem Pi haben und die Datenplatten im anderen Server, wenn diese dann über NFS im Pi eingebunden wären. Aus Sicht des Klienten ist das egal — außer natürlich im lokalen Netz, da du dort wieder korrekt auflösen musst.

Ob man die Zertifikate auch nutzen kann, wenn andere Ports verwendet werden, müsste ich selbst nachlesen. Dann könntest du natürlich separate Einträge verwenden und auf beide Webserver vom Router aus weiterleiten und bspw. deinen 4444/4445 nutzen. Bei dem Punkt können vielleicht andere besser helfen, die von außen erreichbare Dienste haben. Ich dümpel nur lokal rum, habe da einen eigenen DNS und diverse Webserver auf verschiedenen Geräten die ich mit oben erwähntem Proxy auf dem „Hauptserver“ vereine.

Richtig. Das wäre das sinnvolle vorgehen, womit du dann direkt virtual hosts unter der Subdomain ansprechen könntest. Wenn das nicht funktioniert, wird das ganze etwas kompliziert, weil du dann mit adresse.ddns.net/wolke arbeiten müsstest, was über sowas wie mod_alias gehen könnte. Habe ich aber so auch noch nie verwendet.

Ich habe jetzt subdomains bei meinem dyndns Anbieter aktiviert.

Leider schaffe ich es nicht, den Reverse Proxy richtig einzurichten.

Ich habe ein zweites cloud.conf erstellt und aktiviert.

<VirtualHost *:80>
        ServerAdmin admin@example.com
        ServerName cloud.mydomain.tld
        ProxyRequests Off

        <Directory />
          AllowOverride all
          Require all denied
        </Directory>

        <Location />
                ProxyPreserveHost On
                ProxyPass http://10.0.1.10:80
                ProxyPassReverse http://10.0.1.10:80
        </Location>

     # Uncomment the line below if your site uses SSL.
     SSLProxyEngine On
     RewriteEngine on
     RewriteCond %{SERVER_NAME} =cloud.mydomain.tld
     RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</VirtualHost>

Wenn ich nun cloud.mydomain.tld eingebe, kommt die Meldung "Service Unavailable" bzw. Seite Funktioniert nicht cloud.mydomain.tld hat keine Daten gesendet ERR-EMPTY_RESPONSE

unter http://10.0.1.10:80 läuft der zweite Server und sollte eben Nextcloud ansprechen. Die Weiterleitung auf Port 443 habe ich auch schon versucht, ohne erfolg.

Muss ich im Vhost für Port 443 auch noch den Proxy einrichten?

Hab soeben beim Schreiben noch was rausgefunden. hab jetzt die ganze Zeit auf den falschen Port weitergeleitet. 😬 Die Reverse Proxy Einstellungen funktionieren!

Aber nur ohne https

Sobald http auf https umgeleitet wird, funktioniert es noch nicht. Ich möchte aber gerne, dass ich von aussen per https://cloud.mydomain.tld auf die Daten des Servers auf http://10.0.1.10 komme....

Kann mir da jemand auf die Sprünge helfen?

Mal als Beispiel:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

<VirtualHost *:443>
        ServerName cloud.hauptserver.tld
        ServerAdmin admin@hauptserver.tld

        # Anmerkung: Hab ich bei meiner Nextcloud so drin. Gab mal irgendwelche Fehler vor Ewigkeiten die sich damit lösen ließen.
        # Läuft heutzutage glaube ich über die .htaccess in der cloud. Schadet aber auch nicht.
        Header always set Strict-Transport-Security "max-age=15552000; includeSubDomains"

        # Module laden (falls nciht schon woanders geschehen)
        LoadModule proxy_module modules/mod_proxy.so
        LoadModule proxy_http_module modules/mod_proxy_http.so

        # https://httpd.apache.org/docs/2.2/mod/mod_proxy.html#ProxyPass
        # Keine Ahnung warum, aber wenn die das schreiben gehört das so ;)
        ProxyRequests Off

        # keine Spezialitäten, balancer, etc.: Stupides *
        <Proxy *>
                Require all granted
        </Proxy>

        <Location />
                # PreserveHost kann ich nix mit anfangen → hat wohl was mit durchreichen der vom client eingegebenen url zu tun
                ProxyPass http://10.0.1.10:80/  # Nebenserver taucht nur hier auf
                ProxyPassReverse http://10.0.1.10:80/  # und hier natürlich ;)
        </Location>
      
        # lets encrypt zeuch
        Include /etc/letsencrypt/options-ssl-apache.conf
        SSLCertificateFile /etc/letsencrypt/live/hauptserver.tld-0001/fullchain.pem
        SSLCertificateKeyFile /etc/letsencrypt/live/hauptserver.tld-0001/privkey.pem

        # Rewrite würde ich erstmal weglassen, das verkompliziert. Brauchst du auch vorerst nicht.
</VirtualHost>

Falls du noch zusätzliche Directory-Directiven brauchst, die sind hier nicht berücksichtigt.

Danke für dein Beispiel: Es klappt ☺ Herzlichen Dank für deine Hilfe.

Was jedoch noch nicht klappt ist, dass ich mich auf Nextcloud anmelden kann. Es kommt die Meldung, dass der Eintrag in der "trusted_domains" fehlt.

Ich habe dort jedoch folgendes eingetragen:

cloud.mydomain.tld https://cloud.mydomain.tld

Trotzdem kommt das Anmeldefenster nicht. Hast Du hier evt. auch noch einen Trick ☺

Mal noch eine Frage zu den SSL Zertifikaten. Muss hier tatsächlich für jede domain ein eigenes Zertifikat erstellt und verknüpft werden? Denn wenn ich hier ein bestehendes Zertifikat genommen habe, kam die Meldung, dass dem Zertifikat nicht getraut werden kann, weil es eben von einer anderen domain kommt.

Ok, selbst rausgefunden ☺ Muss dort ja die IP vom eigenen Server, also 10.0.1.10 noch zu der trusted list hinzufügen. Es klappt jetzt zumindest ☺

magcat schrieb:

Danke für dein Beispiel: Es klappt ☺ Herzlichen Dank für deine Hilfe.

Was jedoch noch nicht klappt ist, dass ich mich auf Nextcloud anmelden kann. Es kommt die Meldung, dass der Eintrag in der "trusted_domains" fehlt.

Suchmaschine fragen. Im Docker-Container habe ich in der Nextcloud ein 'overwritehost' => 'cloud.heimknecht.ck' drinstehen, ebenso noch 'overwriteprotocol' => 'https', und ein paar andere. trusted hab ich nur nen Proxy:

  'trusted_proxies' => 
  array (
    0 => '172.17.0.1',
  ),

(172. sind alles Docker-Container).

Muss hier tatsächlich für jede domain ein eigenes Zertifikat erstellt und verknüpft werden?

Klar. Und die Subdomains auch (ist ein Abwasch bei letzfetz. Da kann man mehrere Subdomains mit angeben). Also da gibts ein Zertifikat für alle. Allerdings kann ich dir da keine Beispiele bringen, da „heimknecht.ck“ nur hier lokal korrekt auflöst — wobei es die tld ck mittlerweile wirklich gibt. Könnte also klappen 😀

Aber wie gesagt: Für „von außen erreichbar“ bin ich nicht zuständig. Ich tue alles dafür, das so wenig wie möglich rein und raus geht. Hatte das zwischenzeitlich mal, als ich länger außer Haus musste. Aber da war vieles umzustellen, letsencrypt war da noch der einfache Teil. Ich traue mir keine Absicherung zu.