bin gerade dabei zu versuchen Nextcloud 10 auf einem ubuntu 16.04 Server in der DMZ zu installieren. Hab mich an die Anleitung gehalten und hat alles soweit super funktioniert. Nur erreiche ich den Rechner jetzt nicht über den Browser. Der Server ist virtualisiert in der DMZ und hat die IP 172.16.17.1. ich erreiche ihn aus dem Schulnetz über SSH und kann ihn auch anpingen. Aber im Browser bekomme ich beim Aufruf von http://172.16.17.1/nextcloud die ipfire Meldung, dass die URL nicht gefunden werden. Meine Firewallregeln sehen so aus:
Außerdem noch die Frage kann auch eine aktuellere Version von nextcloud
eingesetzt werden?
ja: ich würde in jedem Fall gleich die aktuelle NC 15 installieren.
Dein Vorgehen zum Erreichen der Nextcloud ist aber falsch: du solltest
sie in jedem Fall über eien URL und nicht über eine IP ansprechen: für
eien IP bekommst du kein lets Encrypt Zertifikat und die IP ist im
Internet auch nicht erreichbar (ist ja aus dem privaten Bereich).
Also brauchst du erst mal eine Domain unter der deine NC erreichbar ist:
deswegen würde ich sie auch nach Rot stellen, nicht nach Orange („Rot“
ist ja auch hinter einem Router und damit Quasi Orange).
Dann ist die Nextcloud aus dem Schulnetz erreichbar.
jetzt habe ich extra eine DMZ noch nachträglich installiert, daher würde ich sie auch gerne nutzen und wissen wie das geht. Von der Möglichkeit weitere Rechner in Rot zu stellen habe ich erst jetzt gelesen (von Belwue hätte ich ja sogar noch IP Adressen). Aber eigentlich muss das doch auch mit der DMZ funktionieren.
Ich wollte ja jetzt erstmal nextcloud einrichten und habe aus dem Schulnetz versucht die IP zu erreichen. Von außen würde ich gerne den nextcloud server so erreichen wie auch unseren Linuxmusterserver, also mit https://nextcloud.hans-baldung-gymnasium.de. Unter https://server.hans-baldung-gymnasium.de ist unser Server mit den publichtml Verzeichnissen und den Mysql Server problemlos erreichbar.
ich hatte meinen Webserver mit NC auch in der DMZ.
Du brauchst eine Firewallregel bei ausgehend von orange auf die IP des Webservers in orange.
Ok, dann brauchst du noch einen ReverseProxy auf dem IPfire, damit die Anfrage von außen über Port 443 an den richtigen Server (LMN oder Webserver) weitergeleitet wird.
Ich hatte damals Pound, aber das gibt’s beim aktuellen IPFire nicht mehr. Es gibt aber eine Alternative. Ich weiß nur nicht auswendig, wie die heißt.
Am einfachsten geht das, wenn du Belwue bittest, einen cname-Eintrag https://nextcloud.hans-baldung-gymnasium.de auf eine noch nicht benutzte IP zu erstellen.
Dann brauchst du keinen Revers Proxy.
Danach kannst du den IPFire so konfigurieren, dass er auch auf diese weitere externe IP reagiert und Anfragen an den NC-Cloud-Server in der DMZ weiterreicht (auf den Ports, die man möchte).
Dabei kannst du zwischen zwei Varianten wählen
NC-Server hat nur eine IP (die interne 172.16.17.*), dann muss der IPfire NAT machen
NC-Server hat zwei IP-Adressen (intern und extern), dan auf dem IPFire kein NAT
Beim IPFire musst du bzgl Regeln unterscheiden: Kommt die Anfrage von außen oder von innen und dementsprechend Quelle und Ziel richtig wählen
NC als Quelle: NC soll ins Internet kommen, z.B. um Updates einzuspieln
NC als Ziel: „übliche“ Betriebsart, aus dem Internet kommen Anfragen
IdR haben alle Geräte aus grün Zugriff auf Geräte in Orange (DMZ), da brauchst keine Regeln, event. musst du aber auch da eine Regel analog zu rot erstellen
stimmt, wenn die IPs von denen man von extern kommt verschieden sind, dann geht das. Wobei… welche IP „sieht“ denn die IPFire am Belwü-Router, sprich, merkt die IPFire denn überhaupt, dass die Anfrage von einer anderen (externen) IP stammt?
Wenn nicht, dann braucht er doch den ReverseProxy, der anhand des Dienstes bzw. Virtual Host bzw. URL entscheidet, an welchen Server die https- Anfrage weitergeleitet werden muss.
ich hab mein Problem gelöst. Es lag nicht an der Firewall sondern am Apache. Ich hatte noch kein Serverzertifikat. Ich habe Nextcloud 15 installiert und den LDAP Zugriff eingerichtet. Aus dem pädagogischen Netz klappt das.
Jetzt möchte ich noch die Homeverzeichnisse einbinden und den Zugriff von außen ermöglichen. Nach euren Vorschlägen will ich jetzt mal einen reverse Proxy (HAProxy) ausprobieren.
HAProxy eignet sich dann gut, wenn du load balancing machen willst. Für Reverse Proxy von Webservern empfiehlt sich auch nginx.
Der ist für load balancing nicht so gut geeignet. Wann nutze ich was? Der Reverse Proxy nimmt die Anfragen für alle Webserver an und leitet sie intern an die jeweils unterschiedlichen Webserver weiter. Der LoadBalancer macht das gleiche, verteilt
die Anfragen aber an gleichartige Webserver zB zwei redundante Nextcloud Server, Mail oder LDAP Server. Bsp. Du hast zwei Samba Ad Server und vorgeschaltet HAProxy und machst eine externe LDAP Authentisierung z.B. über Moodle. HAproxy nimmt die Anfrage an
und schickt die intern an Samba-AD1 oder Samba-AD2.
Es kommt darauf an, was du machen willst. HAProxy macht nicht immer und überall unmittelbar Sinn, wenn du einen Reverse Proxy für Webserver haben willst, ist nginx evtl. besser geeignet. nginx kann z.B. auch Webinhalte cachen, über den eigenen
Webserver selbst bereit stellen und nur die Anfragen, die er selbst nicht beantworten kann an den dahinter liegenden Webserver weiterreichen. Das eignet sich auch prima für ssl offloading in Kombi mit Lets Encrypt oder Wildcards.
An dieser Stelle sei noch angemerkt, dass bisher für den Docker in der
lmn7 nginx verwendet wird als reverse Proxy.
Wenn du dich nun auch für diesen entscheidest, dann bist du für die lmn7
schon eingearbeitet.
Loadbalancng brauchen wir in der Schule ja vorerst noch nicht.
Hab jetzt Apache als Reverse Proxy eingesetzt und funktioniert problemlos. In der default site habe ich im Bereich <VirtualHost *:443> folgendes ergänzt:
SSLProxyEngine On
ProxyPass /nextcloud https://172.16.17.1/nextcloud
ProxyPassReverse /nextcloud https://172.16.17.1/nextcloud
Hallo Holger.
Kommt der Reverse Proxy wirklich als extra Container? OPNSense kann nginx doch auch direkt als Modul installieren. Vor-/Nachteile??
Schönen Gruß,
Michael
kann man auf der opnsense machen.
Aber dann isses halt kacke.
oder genauer: die konfiguration des nginx sollte nicht „von hand“ passieren, oder nur wenn nötig.
Es wurde jetzt entschieden das auf einem dockerhost in der DMZ zu machen. Ob im Container oder nicht, wird man dann noch sehen.
Es ist halt ein komplexes Ding: beliebige Dienste, LE-Zertifikate, DNS-Auflösung von außen und innen. Damit das alles für den Standard-Admin mit den STandarddiensten funktioniert, ist das auf dem OpnSense vermutlich nicht der richtige Ort.
So rum formuliert würde ich sagen: nö.
Die OPNSense-FW schirmt die DMZ inkl. dem Docker ab.
Die FW reicht den externen Port 443 (und vermutlich 80 für LE-Zertifikate) weiter an den Dockerhost.
Der Dockerhost steht hinter der FW.
NAtürlich kann man den Dockerhost auch neben die FW stellen, dann ist es keine DMZ mehr, sondern der Dockerhost steht eben in ROT.
ABer ich gehe mal davon aus, dass er standardmäßig für alle externen Dienste eher in ORANGE/DMZ, also hinter der FW steht.
ROT/ORANGE ist denke ich sowieso ziemlich ähnlich, weil bei belwue z.B. kein ROTer rechner ungeschützt im Internet steht…
Dann sehe ich doch nicht 100%ig ein, warum es nicht direkt auf der OPNSense FW laufen kann (mal davon abgesehen, wie/von wem nginx konfiguriert wird). Aber sprich nur weiter – ich höre zu
(mal davon abgesehen, wie/von wem nginx konfiguriert wird). Aber sprich nur weiter – ich höre zu