Automatisches Backup für Teachtool auf NextCloud

[shul]

Beim Erstellen des automatischen Backups für Teachertool in der Schule (mit dem mobile device wlan) erscheint eine Fehlermeldung und ist somit nicht möglich.

[Stephan Richter]

Bei mir das gleiche Problem.

Im Gastnetzwerk und von zu Hause funktioniert es. Interessanterweise scheint die Nextcloud-App im MobileDevices dennoch Kontakt zum Server zu haben.

[Rüdiger Kupper]

Interessant, am langsamen Zugriff kann es nicht mehr liegen, das habe ich endlich gelöst.

Seid ihr sicher, dass der Speicherversuch wirklich in einem Ordner unterhalb von „Fileserver“ erfolgt? Könnte es sein, dass die App versucht, direkt im Ordner „Fileserver“ etwas zu schreiben? Um das zu testen kann euch euch da gerne mal Schreibrechte geben.

Im auth-Log sehe ich regelmäßig misslungene Anmeldeversuche mit uid „rich@…“. Also ganze Email statt Nutzername. Kann das damit zusammenhängen?

Allerdings, wenn es sich bestätigt, dass im Gastnetzwerk und von extern geht, dann muss es am MobileDevices-Netz liegen...

[Rüdiger Kupper]

Noch eine Frage: habt ihr die Wahl zwischen dav:: und davs:: ? Und habt ihr beides probiert?
Bei Anfragen von außen mappt der Apache auf 10.16.112.17 http-Anfragen automatisch auf https. Doch vielleicht routet Jens den Zugang im MobileDevices-Netz direkt auf den cloud-Server 10.16.112.16). Dann kann das einen Unterschied machen.

[Stephan Richter]

Nachdem jetzt sowohl das Netz als auch die Nextcloud bei mit stabil laufen, habe ich es nun nochmal probiert:

• im Gastnetzwerk ist ein Upload per Webdav aus TeacherTool problemlos
• sobald ich das WLAN auf MobileDevices wechsle, bekomme ich immer sofort einen "Login nicht möglich" Fehler
• das passiert sowohl mit einer http als auch einer https Adresse

Alle anderen Einstellungen (Ordner, user, PW) bleiben natürlich unverändert.

Irgendwie scheint die Routing-Regel #4063 nicht mehr zu funktionieren.

[Stephan Richter]

Das Problem ist m.M. nach der Port. Aber die TT-Doku sagt:

Port: Dies ist der Port, unter dem der WebDAV-Dienst auf dem Server läuft. Normalerweise wird für http der Port 80 benutzt und für https der Port 443 – geben Sie hier nichts anderes an, benutzt TeacherTool automatisch diese Standardports.

Wenn ich in TT den Port explizit auf 443 setze, geht es trotzdem nicht.

[Rüdiger Kupper]

Kannst Du das gleiche mal mit einer anderen Nextcloud probieren? Du hast bei doch auch eine llaufen. Oder meine: rcloud.dynv6.net.
Passiert da das selbe?

[Stephan Richter]

Replying to kup:

Kannst Du das gleiche mal mit einer anderen Nextcloud probieren? Du hast bei doch auch eine llaufen. Oder meine: rcloud.dynv6.net.
Passiert da das selbe?

Nein, wenn ich auf meine eigene Nextcloud gehe, geht das auch aus dem MobileDevices WLAN.

@kup: Können wir einmal gemeinsam schauen, auf welchem Port TeacherTool? da tatsächlich arbeitet!?

[Stephan Richter]

Rüdiger und ich haben gestern untersucht, welche Anfragen beim Apache auf cloud.kg-fds.de ankommen:

• TeacherTool webdav aus dem Gastnetzwerk : JA
• TeacherTool webdav aus dem MobileDevices : Nein
• http Anfrage (Browser Safari) aus dem MobileDevices : JA

Wir verstehen leider nicht, wo der Unterschied zwischen einer https Anfrage aus Safari und einer webdav via https Anfrage aus TeacherTool ist.

Uns ist aber aufgefallen, dass es eine Dopplung der IP 10.2.0.10 gibt:

• es ist die Standardgateway für Geräte im MobileDevices
• es ist gleichzeitig die IP für den Host cloud.kg-fds.de
• sie findet sich entsprechend in der NAT-Regel (#4063)

@bau: Bist du sicher, dass das so funktioniert? Ein Paket mit Destination Standardgateway (auf den entsprechenden Ports) würde dann auch an 192.168.150.8 umgeleitet werden.... .

[bau]

Ja, das ist so:

• 10.2.0.10 ist die IP von proxmoxls2 im Netz mobileDevices
• Pakete von draußen kommen über den ciscoRouter (129.143.149.1)
• auf den proxmoxls2 (129.143.149.5) und gehen von dort per iptables-Rule auf den 192.168.150.8:

  root@proxmoxls2:~# iptables -tnat -S
  -P PREROUTING ACCEPT
  -P INPUT ACCEPT
  -P OUTPUT ACCEPT
  -P POSTROUTING ACCEPT
  -A PREROUTING -i enp3s0f0.3 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.150.8:80
  -A PREROUTING -i enp3s0f0.3 -p tcp -m tcp --dport 443 -j DNAT --to-destination 192.168.150.8:443
  -A PREROUTING -i enp3s0f0.3 -p tcp -m tcp --dport 9980 -j DNAT --to-destination 192.168.150.8:9980
  -A PREROUTING -i enp3s0f0.3 -p udp -m udp --dport 11194 -j DNAT --to-destination 192.168.150.11:11194
  -A PREROUTING -d 10.2.0.10/32 -i vmbr17 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.150.8:80
  -A PREROUTING -d 10.2.0.10/32 -i vmbr17 -p tcp -m tcp --dport 443 -j DNAT --to-destination 192.168.150.8:443
  -A PREROUTING -d 10.2.0.10/32 -i vmbr17 -p tcp -m tcp --dport 9980 -j DNAT --to-destination 192.168.150.8:9980
  -A POSTROUTING -s 192.168.150.0/24 -o enp3s0f0.3 -j MASQUERADE
  -A POSTROUTING -s 10.2.0.0/16 -o enp3s0f0.3 -j MASQUERADE
  
  

• von mobileDevices ist zunächst mal der proxmoxls2 (10.2.0.10) der router (das ist die Masquerade-Regel am Ende)
• Wenn Anfragen direkt an den proxmoxls2 (also als Ziel) reinkommen, greifen die drei Regeln, die an 192.168.150.8 weiterleiten

Alternativ könnten wir natürlich auch dem apache (192.168.150.8) ein Interface in VLAN17 spendieren und diese Adresse im proxmoxls2-DNS für die Namensauflösung cloud.kg-fds.de und collabora.kg-fds.de eintrtagen.

Der Apache leitet die Anfragen dann weiter an den cloud (192.168.150.7) bzw. den collabora (192.168.150.12)

[bau]

Ich habe nun dem apache.kg-fds.de eine IP im Subnetz von MobileDevices gegeben (10.2.0.9) und die DNS-Einträge auf !ProxMoxLS2 umgebogen (jeweils auf 10.2.0.9):

• services.kg-fds.de
• cloud.kg-fds.de
• collabora.kg-fds.de

Damit wird nun der !ProxMoxLS2 komplett umgangen, die Abfragen laufen direkt auf den apache.

Kann das mal jemand probieren, ob das aus MobileDevices heraus nun tut? - DANKE!

[Stephan Richter]

Leider kommt weiterhin die gleiche Fehlermeldung.

Hier nochmal ein traceroute:

traceroute to cloud.kg-fds.de (10.2.0.9) , 5 relative hops max, 52 byte packets
   1 cloud.kg-fds.de (10.2.0.9) 24.935 ms 29.106 ms 31.301 ms

[bau]

OK, dann liegt es definitiv nicht an der Route, direkter kann man NextCloud nun wirklich nicht anbinden!
Nun gut, der apache könnte noch auf dem nextcloud.kg-fds.de direkt laufen, das sollte aber kein Problem darstellen.
Komisch ist nur, dass das Ganze auf dem Langen Weg vom Internet über den ProxMoLS2 an den apache -> nextcloud ja geht. Das hier ist der deutlich kürzere Weg!

[Stephan Richter]

Aus dem Gastnetzwerk geht es ja ebenfalls. Wie unterscheidet sich hier die Route im Vergleich zum MobileDevices?

[bau]

Bislang war das im Gastnetzwerk so, dass es auf dem einen Router mit dessen öffentlicher IP rausging (129.143.149.4) und dann auf der öffentlichen IP des ProxMoxLS (129.143.149.2, die IP wird aufgelöst, wenn paedml.kg-fds.de oder angefragt wird) bzw. ProxMoxLS2 (129.143.149.5) wieder reinkam.

Nun ist es seit dem Betrieb mehrerer Router im Gastnetzwerk so, dass die internen Anfragen an paedml.kg-fds.de nun auf die Adresse 192.168.150.254 (interne Adresse des paedml in der DMZ), die an cloud.kg-fds.de gehen an 10.0.0.7 (das ist die interne Adresse des apache im Gastnetzwerk).

Frage: Geht es noch immer im Gastnetzwerk?

[Stephan Richter]

Nein, es geht im Gastnetzwerk nicht mehr.

Interessant ist, dass ich, wenn ich im MobileDevices die IP-Adresse 10.0.0.7 statt der URL in TT angebe, dann erhalte ich eine andere Fehlermeldung (keine Leserechte). Der Login scheint da aber zu funktionieren....?

Die Antwort im TT Forum war erstmal wenig hilfreich, aber falls ihr dort mitreden wollt: ​https://teachertool.de/board/index.php?thread/2900-webdav-backup-schlägt-fehl-via-nat-route/&postID=13593#post13593

[Stephan Richter]

Seit heute (?) funktioniert plötzlich der Upload von TeacherTool auf die Nextcloud.

• @bau und @kup: habt ihr irgendetwas geändert?
• evtl. war es das Update auf iPADOS 15.3.1?
• oder die aktuelle TeacherToolVersion?

[Rüdiger Kupper]

Ich habe am Samstag ein Update von Nextcloud gemacht (allerdings nur eine Minor Version, von 22.5.3 auf 22.5.5). Keine Ahnung, das damit zusammenhängen kann?
Hier ist das Changelog, vielleicht findest Du dort einen Hinweis:
​https://nextcloud.com/changelog/#latest22