cloud URL aus MobileDevices nicht erreichbar

[Stephan Richter]

Die URL cloud.kg-fds.de ist aus dem WLAN MobileDevices sowie aus dem zugehörigen Subnetz nicht erreichbar (z.B. der MacMini im U3-Stützpunkt).

[bau]

Blöd - der Router (ProxMoxLS2) hat die IP 129.143.149.5 und hört auf den Namen cloud.kg-fds.de. Anfragen aus dem MobileDevices leitet er an den BelWUE-Knoten weiter (129.143.149.1) - müsste diese aber direkt an die VM weitergeben. Verzwickt ....

[bau]

Lösung (bitte testen):

• ProxMoxLS2 hat in ipadWLAN die IP 10.2.0.10
• macht dort DNS, Eintrag ergänzt, dass 10.2.0.10 in ipadWLAN nun cloud.kg-fds.de heißt
• PREROUTING-Einträge:

  # Portweiterleitung aus ipadWLAN (http/https/collabora)
  
  post-up iptables -tnat -A PREROUTING -i vmbr17 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.150.8:80
  post-up iptables -tnat -A PREROUTING -i vmbr17 -p tcp -m tcp --dport 443 -j DNAT --to-destination 192.168.150.8:443
  post-up iptables -tnat -A PREROUTING -i vmbr17 -p tcp -m tcp --dport 9980 -j DNAT --to-destination 192.168.150.8:9980
  
  

[bau]

Keine gute Idee, Port 80 und 443 grundsätzlich umzuleiten, denn als Folge kommen die iPads garnicht mehr in's Internet. Habe das rückgängig gemacht, das muss noch auf die eine IP eingeschränkt werden.

[Stephan Richter]

Da ich nächste Woche in der TeacherTool Fobi erklären werde, wie man die verschlüsselte Datenbank automatisch per webdav auf die kepler-cloud backupen kann, erhöhe ich mal die Priorität. Ansonsten werden viele Kollegen ständig Fehlermeldungen von der App erhalten, solange sie in der Schule sind.

[bau]

Tut leider (noch) nicht:

• ProxmoxLS2 (10.2.0.10) ist als Router definiert
• vergibt als DHCP-Server Leases
• default-Route steht auf 10.2.0.10
• DNS ist 10.2.0.10

DNS (Eintrag in /etc/hosts):
10.2.0.10  cloud.kg-fds.de

Route (iptables in /etc/network/interfaces)

iptables -t nat -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
iptables -t nat -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
iptables -t nat -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

Wo genau hakt es denn jetzt noch???
DANKE für's mitdenken!

[Stephan Richter]

Sieht soweit richtig aus...

• Wird die URL tatsächlich auf 10.2.0.10 aufgelöst? --> kann ich morgen testen
• Was sagt traceroute?
• Finden die Antwortpakete des Servers auch wieder zurück zum Gerät? (evtl. dumme Frage, da hört mein NAT-Wissen auf)

[Stephan Richter]

Die URL wird von cloud.kg-fds.de nicht nach 10.2.0.10 sondern auf die öffentliche IP aufgelöst. Somit greift die NAT-Regel nicht und die Pakete werden maskiert....:

;; ANSWER SECTION:
cloud.kg-fds.de.	1020	IN	A	129.143.149.5

;; Query time: 2 msec
;; SERVER: 10.2.0.10#53(10.2.0.10)

[bau]

Suppi - tatsächlich hat es geholfen, den Namen ohne TLD auch in die Datei einzutragen.
Bitte zur Sicherheit auf den Tablets probieren.

[Stephan Richter]

Funktioniert. Danke!

[bau]

Ich habe mal den Nameserver auf proxmoxLS2 auf die Nameserver von BelWUE umgestellt.
Wichtig ist ja aber nur, dass dnsmasq im MobileDevices die Adressen korrekt auflöst:

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

Das ist nach wie vor korrekt - habe das grade getestet.

Frage: Nutzen die iPads nach dem Update den lokalen Nameserver 10.2.0.10 ?

Die Route ist nach wie vor korrekt eingetragen:

-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

[Stephan Richter]

Ja, 10.2.0.10 ist eingetragen. Im Browser komme ich ja auch auf cloud.kg-fds.de. Prinzipiell scheint das zu funktionieren. Auch die Nextcloud-App läuft.

Es kann eigentlich nur sein, das TeacherTool für WebDav einen anderen Port verwendet, obwohl das ja eigentlich über https laufen soll.

Wie bekommen wir heraus, auf welchen Port die App es versucht? TT im Gastnetzwerk triggern und im log mitlesen, auf welchen Port der NC-Server angesprochen wird!?

[Stephan Richter]

Nach TT-Doku sollte es eigentlich passen:

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.

[Stephan Richter]

Das Problem hier passt eigentlich nicht mehr zum Ticket-Titel und wir sollten das in #4179 diskutieren.