derzeit verzweifele ich an einem mysteriösen Problem. Ich habe eine lmn7 und eine Nextcloud 22 mit External Storage laufen, einen CODE-Server gibt es auch.
Für den Zugriff gibt es derzeit das grüne Netz, das CaptivePortal und VPN.
Alles funktioniert einwandfrei beim Zugriff über das CaptivePortal und VPN.
Vom grünen Netz aus kann ich mich anmelden, Textdateien anlegen, Collabora Online benutzen, Ordner erzeugen und Dateien herunterladen. Was ich nicht kann, ist Dateien hochladen, aber nur von Clients im grünen Netz aus! Vom CaptivePortal und VPN aus kann ich Dateien hochladen, getestet mit demselben und unterschiedlichen Rechnern.
So als ob die Webseite daran scheitert, dass es einen direkten SMB-Weg vom Client zum Server gibt, dabei müsste es der Webseite doch egal sein, in welchem Netz der Client ist. Die Datei wird doch zum Webserver geladen und der lädt die Datei über External Storage auf den Server, oder?
Hat jemand eine Idee, wo ich da ansetzen kann? Oder sogar eine Lösung?
Sorry und Kommando zurück!
Ist ein Routing-Problem. Der Nextcloudserver hat aus Gründen der eigenen Faulheit 2 Netzwerkkarten. Ruft man die Cloud über die IP der Netzwerkkarte auf, die im grünen Netz ist, klappt auch der Upload.
=> Dies zur Info für euch.
Für mich heißt es, Routing-Problem lösen, denn das Zertifikat läuft auf den Namen, den der Cloudserver im blauen Netz hat. Wenn ich das Problem gelöst habe, poste ich es hier.
Also, das Problem habe ich nicht gelöst, sondern umgangen:
Der Cloudserver hat nun ein Zertifikat mit 2 Namen, die Namen werden von der Opnsense auf die Netzwerkkarten in den jeweiligen Netzen geroutet (per Überbrückung im UnboundDNS).
Bekannt ist aber nur ein Name, der für die Benutzer aus dem grünen Netz eigentlich falsch ist. Damit die aber auch Dateien hochladen können, gibt es folgende Erweiterung in der .htaccess-Datei der Nextcloud. Sie wurde unter „#### DO NOT CHANGE ANYTHING ABOVE THIS LINE ####“ geschrieben in der Hoffnung, dass Nextcloud-Updates diesen Teil dann behalten.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REMOTE_ADDR} ^10\.20
RewriteCond %{REMOTE_ADDR} !^10\.20\.0\.0$
RewriteCond %{REMOTE_ADDR} !^10\.20\.255\.255$
RewriteCond %{HTTP_HOST} ^cloud\.intern\.schuldomain\.de$ [NC]
RewriteRule ^(.*)$ https://cloudserver.intern.schuldomain.de/nc/ [R=301,L]
# Durch das L in der eckigen Klammer wird die Regel beendet, es folgt die nächste
RewriteCond %{SERVER_PORT} !=443
RewriteRule ^(.*)$ https://cloud\.intern\.schuldomain\.de/$1 [R=301,L]
</IfModule>
Was weiterhin nicht funktioniert, ist das Einfügen von Bildern in ein Collabora Dokument, sofern man sie direkt hochlädt. Zuerst hochladen und aus der Cloud einfügen, klappt. Der Grund hierfür ist, dass ich keine passende Anleitung zum Reverse Proxy für Collabora gefunden habe. Alle Anleitungen benutzen die Ports 80 und 443, die auf meinem „echten“ Server (keine Docker) schon belegt sind. Somit greifen die Clients direkt auf Collabora zu und aus dem grünen Netz entsteht dasselbe Problem wie zuvor mit der Nextcloud, nur dass ich bei Collabora nicht 2 Ansprechwege habe. (Das ist aber verschmerzbar, und wenn irgendwann das MEP-WLAN eingebaut wurde, wird die Netzstruktur reorganisiert.)
So, dass ist jetzt ein Monolog. Wenn ihn niemand braucht, kann den ganzen Thread gerne ein Admin löschen. Nur offen stehen lassen wollte ich die Frage nicht.