Zugriffsprobleme auf Collabora Online von extern

Kreftig 2021-01-31 15:29:24 UTC #1

Hallo an die Community!
Ich habe ein Problem mit meiner Collabora Online Installation (CODE) in meiner onPrem Umgebung.
Hintergrundinformation: ich greife immer über den FQDN der externen Domäne auf meinen EGroupware Server zu. Im internen Netz gibt es dafür einen DNS Alias, von extern entsrpechend einen Host Record.

Das positive vorweg: innerhalb des internen Netzes ist alles gut, beim Zugriff auf Dateien über den Dateimanager öffnet sich die entsprechende CODE Applikation - passt.
Beim Zugriff von außen (EGroupware mit seinen Modulen funktioniert) passiert genau dies nicht. Ich bekomme ein neues Browser Fenster (Tab), dieses bleibt aber leer.
Wenn ich beim Firefox per “F12” mir die Netzwerkanalyse aufrufe sehe ich beim INTERNEN Zugriff folgendes:

wss://EXTERNE.DOMAIN.de/lool/https%3A%2F%2FEXTERNE.DOMAIN.de%2Fegroupware%2Fcollabora%2Findex.php%2Fwopi%2Ffiles%2F1623%3Faccess_token%3DfnXJarxtbQmiCo9LB3F5h9t0DzcYRRrd%26access_token_ttl%3D0%26reuse_cookies%3D_pk_id.1.2085%253Dea8819e5a6702860.1611428336.%253Alast_loginid%253DStefan%253Alast_domain%253Ddefault%253AeGW_cookie_test%253Denabled%253Asessionid%253D6o73lfrj01pic30vqs30puun0p%253Akp3%253Dy0eHQodfC5HJKq6dFJXGU5n7%253Adomain%253Ddefault/ws?WOPISrc=https%3A%2F%2FEXTERNE.DOMAIN.de%2Fegroupware%2Fcollabora%2Findex.php%2Fwopi%2Ffiles%2F1623&compat=/ws

Dies funktioniert (wie erwähnt DNS Alias im internen DNS Server).

Beim Zugriff von EXTERN sieht die Anforderung wie folgt aus:

wss://192.168.1.234/lool/https%3A%2F%2FEXTERNE.DOMAIN.de%2Fegroupware%2Fcollabora%2Findex.php%2Fwopi%2Ffiles%2F1633%3Faccess_token%3DXGCZqis3WBlhZAgLHNXGZDDU1LF3ZX5g%26access_token_ttl%3D0%26reuse_cookies%3D_pk_id.1.2085%253Dea8819e5a6702860.1611428336.%253Alast_loginid%253DStefan%253Alast_domain%253Ddefault%253AeGW_cookie_test%253Denabled%253A_pk_ses.1.2085%253D1%253Asessionid%253Dm5iespgaon2vhm9cifh0sbgq9a%253Akp3%253De2zdzlfvIqPK7xpmI450Np1T%253Adomain%253Ddefault%26permission%3Dedit/ws?WOPISrc=https%3A%2F%2FEXTERNE.DOMAIN.de%2Fegroupware%2Fcollabora%2Findex.php%2Fwopi%2Ffiles%2F1633&compat=/ws

Ich bräuchte hier einen Tipp, wie ich an die Suche gehen kann. Bin für jede Anregung dankbar.

Stefan

StefanU 2021-01-31 16:06:57 UTC #2

Hi Stefan.

Leer oder ganz leer?

Gibt die Konsole etwas her?

Ist das eine Standard-Docker-Installation?

Ist denn dein CODE nun von außen überhaupt erreichbar?

Stefan

AlexS 2021-01-31 16:11:23 UTC #3

Hallo Stefan,
zunächst solltest Du Dir die Nginx Log und die Collabora Log Datei ansehen da bekommst Du meistens einen guten Hinweis aus das Problem. Auch solltest Du überprüfen ob Du in in der docker-compose.yml (oder der override).
unter Collabora den extra hosts Parameter ausgefüllt hast:

can access EGroupware without the need to go over your firewall
extra_hosts:
- "externe.domain.de:192.168.1.234"

VG
Alex

Kreftig 2021-02-02 19:18:15 UTC #4

Hallo Stefan,
die Firefox Konsole zeigt folgendes:

Das Fenster bleibt nicht vollständig leer sondern zeigt den oberen Rahmen:

Das Installation ist eine Standard-Docker-Installation. CODE nach der Anleitung auf euren Seiten installiert.
Wenn ich das korrekt verstanden habe, benötige ich doch keine weiteren NAT Regeln für den Zugriff auf die CODE Installation, oder? Das Ganze läuft doch über den integrierten reverse Proxy. Sprich: von extern NAT auf 443 und gut is. Die EGw Installation mit allen Features ist von extern erreichbar. CardDAV bspw. funktioniert auch mit dem Smartphone. Öffentlich gültiges Lets Encrypt Zertifikat vorhanden.

Beste Grüße
Stefan

Kreftig 2021-02-02 19:22:58 UTC #5

Hallo Alex,
ich konnte im Nginx Log keine Fehler finden. Zum Collabora Log bräuchte ich noch mal einen Hinweis wo ich das finde?
Die docker-compose.yml habe ich in beiden Varianten ausprobiert, natürlich mit Neuerstellung des Containers zwischendurch. In beiden Fällen gab es das gleiche Ergebnis.

Beste Grüße
Stefan

StefanU 2021-02-02 20:09:31 UTC #6

Yep. Genau so ist das in der Standard-Installation gedacht.
Damit ist der Betrieb von solchen Dienste für den “Installateur” ein einfaches.

Da wird versucht etwas über deine interne IP zu erreichen. Die ist sicherlich nicht von extern erreichbar(?).
Hattest du ja weiter oben auch schon gezeigt.

Ich kann mir denke wofür du das machst. Ich hätte die gleiche Aufgabenstellung bei einer Installation. Ich hätte gerne bei einem Ausfall des Routers/Internetanschlusses die EGw von innen erreichbar…
Allerdings hört an der Stelle mein Verständnis dafür auf. Darum habe ich das auch noch nicht umgesetzt.

Kannst du noch etwas erzählen?:

Wo sitzt der DNS?
Was für eine Firewall setzt du ein?
Du löst mit dem DNS Alias auf die interne IP der EGw auf?
Gründe/Ziele dafür diese Konstruktion?

Stefan

Kreftig 2021-02-03 19:01:39 UTC #7

Hallo Stefan,
vielen Dank für die Rückfrage. Hier die Details:

mein interner DNS befindet sich im internen LAN Segment.
Nach außen wird das durch eine zweistufige Firewall abgesichert: Internet – FritzBox (NAT) – Sophos SG Firewall (NAT mit Hostheader Auswertung) – Internes LAN
Korrekt. Der DNS Alias externe.domain.de löst intern auf die 192.168.1.234 auf. Als Ergänzung: um die Ubuntu Installation möglichst reibungslos in der Namensauflösung zu haben ist auch der Hostname des Linux Systems externe.domain.de
Beruflich bin ich u.a. als Exchange Admin unterwegs. Wenn es um Groupware Systeme geht versuche ich die immer so nahtlos wie möglich in allen erdenklichen Zugriffsscenarien zu haben. Beispiel: ein Smartphone User will per CardDAV / CalDAV auf den Groupware Server zugreifen. Dies möchte er sowohl im internen WLAN als auch von extern können, ohne irgendetwas auf seinem Device umzustellen. Bei Exchange trifft dies Outlook Clients in gleicher Weise: User klappt im Büro sein Notebook zu und will per Outlook von extern genauso auf sein Postfach zugreifen wie im Büro. Interne DNS Alias auf den externen Namen ist die Lösung.Von extern greift ja dann wieder der externe DNS Record.

So - jetzt habe ich aber ausreichend “die Hosen runter gelassen”
Stefan

RalfBecker 2021-02-04 05:35:57 UTC #8

Wir untersuchen gerade das gleiche Szenario bei einem Kunden. Sieht so aus als würde die Sophos die etwas ungewöhnlichen URLs von Collabora blockieren

Der Kunde hat das jetzt zum Sophos Support eskaliert.

Aktuell kann ich nur empfehlen auf der Sophos statt dessen einen Portforward einzurichten.

Ralf

RalfBecker 2021-02-04 14:48:24 UTC #9

Der folgende Eintrag bei Sophos erklärt was das Problem ist und wie man es lösen kann, durch Patchen der Firewall:

https://community.sophos.com/utm-firewall/f/general-discussion/92242/utm-9-reverse-proxy-configuration/436406

Here a summary and extension for a better understanding of Onno vdL’s patch. It enables not only to configure AllowEncodedSlashes On, but rather ProxyPass nocanon to proxy services like GitLab through the Sophos UTM.

Edit reverseproxy script:

fw:/var/mdw/scripts # diff -Nura reverseproxy.orig reverseproxy
--- reverseproxy.orig 2020-04-28 20:28:39.536059392 +0200
+++ reverseproxy 2020-04-28 15:39:37.171411346 +0200
@@ -35,7 +35,34 @@
 ${APACHE2CTL_LOG}
 }

+apache_allowslashes() {
+ grep -q 'PATH "/AllowEncodedSlashes/"' ${CHROOT}/usr/apache/conf/reverseproxy.conf
+ MYRESULT=$?
+
+ if [ ${MYRESULT} -eq 0 ]; then
+ echo "AllowEncodedSlashes found - fixing" | log
+ sed -i 's|WAFExceptions PATH "/AllowEncodedSlashes/" SkipAntiVirus|AllowEncodedSlashes On|g' ${CHROOT}/usr/apache/conf/reverseproxy.conf
+ else
+ echo "AllowEncodedSlashes not found - skipping" | log
+ fi
+}
+
+apache_nocanon() {
+ grep -q '/ProxyPassNocanon/' ${CHROOT}/usr/apache/conf/reverseproxy.conf
+ MYRESULT=$?
+
+ if [ ${MYRESULT} -eq 0 ]; then
+ echo "ProxyPassNocanon found - fixing" | log
+ sed -i 's|/ProxyPassNocanon/" lbmethod|/" nocanon lbmethod|g' ${CHROOT}/usr/apache/conf/reverseproxy.conf
+ sed -i 's|/ProxyPassNocanon/|/|g' ${CHROOT}/usr/apache/conf/reverseproxy.conf
+ else
+ echo "ProxyPassNocanon not found - skipping" | log
+ fi
+}
+
 apache_conftest() {
+ apache_allowslashes
+ apache_nocanon
 chroot ${CHROOT} ${APACHE2CTL} configtest 2>&1 | log
 if [ $? -ne 0 ]; then
 return 1

Add Firewall Profile Exception for virtual webserver:

Edit default Site Path Routing entry for virtual webserver:

Wem das zu kompliziert oder zu gefährlich erscheint - man patch ja die Firewall - dem rate ich statt der WebApplicationSecurity für EGroupware und Collabora einen einfachen PortForward zu machen.

Ralf

Kreftig 2021-02-04 19:31:10 UTC #10

Hallo Ralf,
vielen Dank für die Infos. Da scheint mein Wochenende zum testen ja gerettet
Allerdings habe ich aktuell durch das viele ausprobieren ein anderes Problem. Ich greife auf die EGw natürlich per HTTPS zu, nach einer Änderung (ich weiß leider nicht mehr welcher) endet der Zugriff aus dem Dateimanager (der erfolgt noch per HTTPS) beim Start des Libre Office Online in einer HTTP Verbindung:

Ich habe bereits den Collabora Container neu erstellen lassen - gleiches Ergebnis.
Wo kann ich dann hierzu noch suchen? Bislang lief das…
Bis dann
Stefan

Kreftig 2021-02-06 11:42:39 UTC #11

Hallo Ralf,
ich habe das heute mal prüfen können und kann bestätigen, das mit Nutzung einer einfachen NAT Regel das problem nicht auftritt.
Für mich reicht dies erstmal als Erkenntnis, da ja auch die Nutzung von Guacamole über die WAF der Sophos etwas schwierig wird. Ich werden also bis zur Ablösung meiner derzeitigen Lösung nichts weiter unternehmen und dann auf eine NAT Regel umstellen.

Das andere Thema mit der Umleitung auf HTTP statt HTTPS für die Collabora Nutzung hat sich wie von Geisterhand geklärt?? Eine Erklärung habe ich allerdings nicht. Wie bei meinen Nutzern: haben Sie was geändert? NEEEIN!!

Eine schönes Wochenende.
Stefan

RalfBecker 2021-02-09 07:09:00 UTC #12

Danke für die Info. Bitte markiere das dann noch als Lösung des Problems.

EGroupware selbst richtet ja kein Zertifikat ein und kann daher auch schlecht automatisch auf https redirecten.
Wenn Du z.B. mit Certbot das Zertifikat einrichtest wirst Du am Ende gefragt, ob Du eine automatische Weiterleitung auf https einrichten willst, was Du bejahen solltest.

Ralf