Hallo miteinander,
ich versuche mich seit mehreren Tagen an der OPNsense, lese allerlei Forenbeiträge und immer wenn ich denke, jetzt hätte ich es verstanden, muss ich feststellen, dass es doch noch nicht tut.
Zu unserem Setup:
Der 7er Server ist im LAN (grün) mit der IP 10.0.0.1
In einer VM haben wir in eine Nextcloud installiert, die in der DMZ (orange) ist mit der IP 10.5.0.1
Übers Internet (rotes WAN) erreichen wir die Cloud über den Port 7344, der dann in die DMZ weitergeleitet wird
Die mobilen Geräte der Lehrkräfte sind im WLAN (blau) mit Adressen 10.4.X.X
In der OPNsense (10.0.0.254) ist noch der WebProxy aktiviert, der auf Port 3128 arbeitet
Der Teil tut soweit, auch, wenn ich mir nicht sicher bin, ob alle Regeln dazu absolut korrekt sind (Korrigiere: Sie sind es sicher nicht).
Was jetzt nicht tut, ist folgendes:
Die Cloud kann aus dem LAN nicht über die normale URL inkl. Port im Browser angesprochen werden (bspw. www.unsere-schule.de:7344), sondern nur direkt über https://10.5.0.1 (ohne Port), was für die Lesezeichen der Kollegen ungünstig ist.
Gleiches gilt auch für die Geräte aus dem WLAN, wodurch die Einstellungen in den ganzen Nextcloud-Apps nicht passen und nichts mehr synchronisiert wird (Dateien, Kalender usw.). Den Workaround über ein zweites Profil mit der 10.5.0.1 finde ich sehr unbefriedigend.
Ich möchte den Nautilus der Ubuntu Clients aus dem LAN gerne über davs mit der Nextcloud verbinden, damit man auf seine Dateien zugreifen kann. Da kriegt er aber keine Verbindung: Einen ping an die 10.5.0.1 schafft er mittlerweile, aber der Port 443 (müsste auch der für davs sein) wird von nmap bspw. als filtered angezeigt. (Könnte das daran liegen, dass die OPNsense auf 443 horcht?)
Wäre es möglich, dass mir jemand zum ein oder anderen Punkt die passende OPNsense-Regel definiert? (An welcher Schnittstelle muss ich was eintragen?)
Vielen Dank für die schnelle Antwort!
Zu meiner Schande muss ich sagen, dass ich das nicht sicher weiß.
Ich glaube schon, aber kann ich das vielleicht irgendwo noch unkompliziert überprüfen?
Hej,
Michael meint, ob ihr den Domainname, den ihr nach außen verwendet (xyz.deine-schule.de), auch intern für den Domänencontroller (server.deine-schule.de) verwendet. Oder ob euer server intern was erfundenes (server.linuxmuster.lan) als Name hat. Im ersten Fall könnte DNS das Problem sein:
Aus Blau funktioniert’s?
Hast Du daran gedacht, den DNS-Eintrag für deine Nextcloud auch auf dem Server zu setzen?
Danke für eure Antworten!
Wir haben intern die linuxmuster.lan und extern den Namen unserer Schule.
Es gibt zwar server.unsere-schule.de aber das ist ein DNS-Eintrag bei BelWü.
Aus Blau funktionierts auch nur über die interne 10.5.0.1 und nicht über die normale URL.
Hallo Wolfgang,
ich glaube, du musst zwei (vielleicht drei) Dinge tun:
Du musst das Routing von Grün → DMZ und Blau → DMZ mit zwei Regeln oder einer Floating Regel explizit erlauben: IPv4 TCP, Source: *, Port: *, Destination: 10.5.0.1, Port 443
ggf. nochmal für deinen Port 7344
Die OPNSense horcht zwar auf 443, aber da das IP-Paket dann an 10.5.0.1 adressiert ist, ist das Ganze kein Problem.
Du musst für deine internen Netze ein Split-DNS machen: Du betreibt ja ein vermutlich ein UnboundDNS für Grün (den Fragt dann der LMN-Server ab) und für Blau. Du erstellst unter Overrides einen Eintrag für Host: www Domain:unsere-schule.de, Type: A, Value: 10.5.0.1
Das biegt dann aber alle Anfragen an www.unsere-schule.de auf 10.5.0.1 um.
Und da bin ich mir nicht sicher: Eventuell musst du 10.5.0.1/24 noch in die NoProxy-Liste auf deinen Clients eintragen. Vielleicht funktioniert es aber auch mit Proxy.
Ohne das Ganze routet OPNsense die IP-Pakete ins Internet (weil im DNS unter www.unsere-schule.de eine nicht-LAN-IP eingetragen ist) und von dort aus können die Pakete aber nicht an dieselbe Adresse zurückgehen, von der aus sie gesendet worden sind.
besten Dank für deine Anleitung!
Nachdem ich dachte alles richtig eingetragen zu haben (wenn auch nicht 100%ig sicher), hat es leider immer noch nicht funktioniert.
Ich habe dann noch ein wenig ausprobiert und das Ergebnis ist, dass ich mich komplett aus der Netz geschossen habe.
Aktuell ist weder die Cloud übers Internet erreichbar (vermutlich auch zerstört), noch komme ich per VPN auf den Server, die OPNsense oder irgendwo hin.
Hoffe, dass ich das morgen vor Ort irgendwie gefixt bekomme.
Vielleicht sollte ich mit so wenig Ahnung einfach die Finger davon lassen…
Weder mit dem Eintrag beim Proxy noch ohne den Eintrag hat es funktioniert.
Ich komme nach wie vor nicht auf die URL im Browser noch klappt die dav-Verbindung im Nautilus.
Habe ich irgendwas übersehen oder hast du noch eine Idee?
schonmal überlegt HAProxy zu verwenden? Das ist als Plugin direkt in der OPNSense installierbar und du kannst alle internen und externen Anfragen über diesen Reverse Proxy laufen lassen. Eine Anleitung dazu gibt es schon in einem anderen Thema (dem Internetlink folgen):
von dem HAProxy hatte ich schon im Zusammenhang mit dem Lets Encrypt-Zertifikat gelesen und fand es eigentlich ganz reizvoll, dass die OPNsense sich um das Zertifikat kümmert.
Würdest du sagen, dass der HAProxy leichter zu bedienen ist/weniger Fehler produziert/mehr Möglichkeiten bietet?
Liebe Grüße,
aktuell nutze ich HAProxy nicht, hatte es aber eine Zeit lang unter lmn6.2 mit Ipfire zuverlässig im Einsatz.
Du kannst damit deine „DNS-Probleme“ in den Griff bekommen: Es werden einfach alle Anfragen, egal aus welchem Netz, an HAProxy gesendet und der leitet dich dann an deinen gewünschten Service, also bspw. Nextcloud, weiter.
Du kannst auch nginx o.Ä. als reverse proxy verwenden, davon habe ich aber keine Ahnung.
Die LE-Zertifikate von der OPNSense habe ich nicht zum Laufen bekommen, kann daran liegen, dass ich es ohne HAProxy versucht habe, ich weiß es nicht. Daher kann ich dir diesbezüglich derzeit nicht weiterhelfen.
bei uns habe die Regeln als Floating-Rules umgesetzt, damit ich die nicht für jedes Netz/Interface definieren muss; das dürfte aber keinen Unterschied machen. Deine Routing-Regeln sehen für mich korrekt aus.
Du könntest schauen, auf welche IP deine Clients auflösen nslookup cloud.******.**** bzw. dig cloud.******.**** - dabei sollte dann 10.5.0.1 herauskommen.
Ich glaube aber, dass dein NoProxy-Eintrag nicht funktioniert. Der Proxy-Server funktionieren erstmal nur für die Standard-Ports 80 und 443; weitere Ports musst du in der Config vom Proxy erlauben - vielleicht würde es dann auch über den Proxy gehen, dann auch ohne die Routing-Regeln.
Du bekommst allerdings trotz NoProxy-Eintrag eine Fehlermeldung von deinem Proxy, der vermutlich den Port 7344 nicht akzeptiert (das solltest du über die log-Files herausfinden können). Die Einstellungen sehen nach den Netzwerk-Einstellungen vom Gnome/Linux aus. Firefox hat aber seine eigenen Einstellungen - schau dir die mal an.
Ich habe gerade noch gesehen, dass die Proxy-Einstellungen im neuen Linux-Client per env-Variablen für Firefox definiert werden: Linux-Client installieren — linuxmuster.net 7.0 Dokumentation
das nslookup kommt bei der 10.5.0.1 raus. Das scheint also nicht das Problem zu sein.
Die Daten im logon - Skript hat unser externer Netzwerkguru nicht eingetragen (vielleicht gabs die damals noch nicht?) aber auch die haben keine Änderung erzielt.
Firefox ist so eingestellt, dass er die Einstellungen des Systems übernimmt. Wenn ich da die Ausnahme dann noch hinzufüge, tut sich aber auch nix. Die Meldung im Firefox ist die gleiche (und das dav will auch nicht).
Du hattest geschrieben, dass man ggf. den Proxy noch konfigurieren könnte um da den Port freizugeben. Kannst du mir sagen, ob es da abgesehen von der WebGUI der OPNsense (oder vielleicht gerade da?!) noch eine Möglichkeit zum einstellen gibt?
ich hätte mir noch vorstellen können, dass das logon-Script mit den env-Variablen Vorrang vor anderen manuellen Einstellungen hat; da eine Änderung aber keine Besserung bringt, kann es das ja auch nicht gewesen sein.
Du kannst auch den FQDN des Servers in die NoProxy-Listen eintragen (cloud.**.), aber nach meinem Verständnis müsste die IP-Adresse genügen.
Bei dir scheint trotz der NoProxy-Einstellungen noch der Proxy dazwischen zu hängen und da habe ich keine Ahnung, warum das so sein könnte… Hast du deinen Proxy als transparenten Proxy konfiguriert?
Das mit den Ports hatte ich vor längerer Zeit mal im Internet gelesen, um zwei verschiedene Dienste unter einer Adresse auf verschiedenen Ports laufen zu lassen. Ich habe das dann aber doch lieber über verschiedene FQDN und SNI gemacht.
Ob es passende Einstellungen in der OPNsense gibt, kann ich dir nicht sagen; ich meine mich zu erinnern, dass man die Ports in die ACL hinzufügen muss. Irgendwer schrieb dann dazu, dass das nicht reiche, und dass man passende pre-routing-Regeln in die iptables schreiben müsse; das war dann für mich der Zeitpunkt das über einen weiteren Hostname und einen Reverse-Proxy umzusetzen.
vielen Dank für deinen ausführlichen Bericht.
Da ich da sowas von mit meinem Latein am Ende bin, würde ich das mal an unseren externen Fachmann weiterleiten und schauen, ob er noch eine Idee hat.
Was ich noch sagen kann ist:
Nein, wir haben keinen transparenten Proxy.
Wir haben einen Rechner in der NoProxy Group von dem das davs auf die Nextcloud ohne Probleme tut.
Mal schauen, ob sich noch ne Lösung findet. In diesem Fall gebe ich sie natürlich für andere Interessierte weiter.
wollte euch nur kurz über den aktuellen Stand informieren (und hoffe, dass ich das einigermaßen korrekt wiedergeben kann):
Unser externer Fachmann hat das ganze jetzt über einen zusätzlichen nginx-Reverse-Proxy gelöst.
Wenn ich es richtig verstanden habe, fängt dieser Port 80 und 443 ab, schaut sich die URL an, über die man in unser Netz gekommen ist, und leitet dann bei cloud… an die 10.5.0.1 entsprechend weiter.
Dadurch brauchen wir auch den Port 7344 nicht mehr und können es sowohl intern als auch extern gleichermaßen nutzen.
In der OPNsense gibts jetzt ein NAT für Port 80 und 443 auf den nginx und eine Firewall-Regel bei DMZ, dass die ngnix auch auf den Server darf.
Nochmal vielen Dank für eure Unterstützung! Ich hatte ihm den Thread gezeigt und er hat ihn aufmerksam durchgelesen.
