Jan 2021
1 / 12
Feb 2021
Feb 2021
Kreftig
Jan '21

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.de1/lool/https%3A%2F%2FEXTERNE.DOMAIN.de1%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.de1%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.de1%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.de1%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

  • created

    Jan '21

  • last reply

    Feb '21
  • 11

    replies

  • 2.7k

    views

  • 4

    users

  • 3

    links

  • 3
StefanUEGroupware GmbH
Jan '21

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
Jan '21
1

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
Feb '21
StefanU

Hallo Stefan,
die Firefox Konsole zeigt folgendes:

grafik
grafik.jpg2016x184 187 KB

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

grafik
grafik.png2050x618 17.3 KB

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
Feb '21
AlexS

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

StefanUEGroupware GmbH
Feb '21

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
Feb '21

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” :wink:
Stefan

RalfBeckerEGroupware GmbH
Feb '21

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 :frowning:

Der Kunde hat das jetzt zum Sophos Support eskaliert.

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

Ralf

RalfBeckerEGroupware GmbH
Feb '21

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/43640625

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:

png-992x1330
6675.Guide_AllowEncodedSlashes.png-992x1330.png992x1330 135 KB

Edit default Site Path Routing entry for virtual webserver:
png-989x939
2185.Guide_ProxyPass_nocanon.png-989x939.png989x939 115 KB

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
Feb '21

Hallo Ralf,
vielen Dank für die Infos. Da scheint mein Wochenende zum testen ja gerettet :wink:
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:

grafik
grafik.png922x356 32.3 KB

grafik
grafik.png2268x254 84.1 KB

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
Feb '21
RalfBecker

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

RalfBeckerEGroupware GmbH
Feb '21

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