Kopano4S Reverse Proxy oder Virtual Host

[webcook]

Hallo zusammen,

ich habe erfolgreich von Zarafa (Julian Dohle, v0.6.0, Zarafa 7.1.10) auf Kopano4S (Tosoboso, v1.0.9, Kopano 9.0.2) umgestellt und möchte das Kopano-Webinterface nun schon wegen des WAF unter derselben Adresse erreichen wie seinerzeit das Zarafa-Webinterface, i.e. https://[B]email[/B].meinedomain.tld.

Voraus geschickt sei, dass ich bei der Installation des Kopano4S-Pakets die Option zur Erzeugung eines eigenen Reverse-Proxy ausgelassen/vergessen habe.
Dies habe ich nun im DSM unter Systemsteuerung => Anwendungsportal => Reverse Proxy nachgeholt. Leider kann ich hier das Ziel nur bis zum Hostort (https://localhost:9443) definieren. Das hat nun aber den kleinen Schönheitsfehler, dass ich meiner externen Adresse ein /webapp (https://email.meinedomain.tld[B]/webapp[/B]) anstellen muss, sonst komme ich immer bei der vorgeschalteten "Got lost"-Seite raus. Dass es hier zu den Emails gehen soll, ergibt sich ja schon aus der Wahl der Subdomain.

Damals residierte die Webapp des Zarafa unter DSM5 im web-share und war dort einer Konfiguration als Virtual Host zugänglich, das ist aber bei Kopano4S als Container-Lösung nicht möglich.

Gibt es also einen einfachen Kniff, wie ich das Kopano-Webinterface von extern direkt unter https://email.meinedomain.tld erreichen kann?

Danke und Grüße
webcook

 

[mic777]

Hallo webcook,

Das gleiche habe ich auch gemacht. Du hast sicherlich 2 DS (DSM6.x mit Kopano +DSM 5.x mit Zarafa).
Du brauchst 2 Third-Level-Domains (mail1.domain.de und mail2.domain.de), die beide durch die Ports 80/443 durch den Router auf der DS mit DSM 6.x auflaufen. Von dieser DS machst du einen Reverse-Proxy auf die andere DS mit DSM 5.x. Umgekehrt geht das nicht, da DSM 5.x das nicht kann.

Viel Glück!
Gruß mic777

 

[FricklerAtHome]

Glück Auf Kopanois

es geht (zumindest bei) mir auch einfacher. Ich betreibe zahlreiche Dienste auch mit einem Zugang aus dem Internet. Für jeden der Dienste gibt es eine durch meinen Provider legitimierte Sub-Domäne mit einer entsprechenden DynDNS Aktualisierung.
Also für 3 Beispieldienste: post.meinedomain.de, cloud.meinedomain.de und vpn.meinedomain. de. Am Router ist lediglich ein hoher Port z.b. 55555 als Weiterleitung für die SubDomains an den Reverse-Proxy der Synology freigegeben.
Je nach nach dem welchen Dienst der Client nun nutzen möchte, benötigt er nur folgende Server-Adresse: https://(beliebige Subdomäne).meinedomain.de:55555.
Jede entsprechende Anfrage landet also beim Reverse Proxy. Dieser entscheidet dann mittels entsprechender Subdomäne wohin er die Anfrage weiterleiten soll. Es funktioniert nur über Subdomän-Anteil der Adresse und nicht über den PORT!
Ensprechend habe ich im Reverse-Proxy 3 Weiterleitungsziele eingerichtet. "POST" geht an die eine Maschine in meinem Netzwerk mit einem individuellen Port ( also z.B. https://192.168.1.2:9443 ) usw.
Der Reverse-Proxy hat ein WildCard Let's Encrypt-Zertifikat für alle SubDomains installiert und in den Zertifikatseinstellungen auch für diese aktiviert. Damit man diese Zertifikate bekommt müssen die SubDomänen auch über das DNS meines Providers im Internet auflösbar sein.
Somit können alle Clients ein registriertes SSL bzw. HTTPS Zertifikat entgegen nehmen und ich kann ungesicherte Zugänge z.b. auf Port 80 einfach ausschalten.
Für meinen KOPANO-Server reicht es vollkommen aus ihn mit https://post.meinedomain.de:55555 für die Webapp bzw. mit post.meinedomain.de:55555 für Z-PUSH anzusprechen um alles was e-mail angeht nutzen zu können. Ergänzungen wie die Adresserweiterung "/webapp" sind nicht nötig.

Immer ein Licht bei der Nacht
F@H

 

[Matis]

.. das mache ich auch so, nur über 443, das ist genauso sicher und ich brauche nicht immer umständlich den port mit angeben.

 

[FricklerAtHome]

@Matis

der hohe Port scheint zwar lästig, wird aber erheblich seltener von extern "Internet-Usern" gescannt. Meine Paranoia geht da sogar noch weiter. Im internen LAN / WLAN nutze ich eine Domain, für Zugriffe von extern eine ganz andere und meine E-Mail Domäne hat einen dritten nochmals anderen Namen. Wer also meine E-Mail Adresse hat findet über den Domän-Namen noch lange nicht meinen "offenen Internetzugang" und ich kann mit den zusätzlich Sicherungen mittels Fail2Ban interne Zugriffe feiner von externen trennen.
Ja,- alles möglicherweise Paranoia, aber möglicherweise auch einen Tacken sicherer. Mittlerweise gibt es ja Suchmaschinen die dir anzeigen welche Server im Netz welchen "Standart-Port" offen haben. das spielte zum Beispiel bei den Recherchen zur Sicherheit des deutschen "Gesundheitsnetzwerkes" eine Rolle. Da hat jeder die unsicheren Router der Telematik-Infrastruktur für Ärzte und Krankenhäuser einfach finden können.

Ob es wirklich hilft, kann ich nicht sagen, aber Vorsicht und ggf. etwas höherer Aufwand sind die Mutter der Porzelankiste.

immer ein Licht bei der Nacht
F@H

PS.: Wenn man keinen vollwertigen Dual-Stack Internetzugang (also volles IPv4 und IPv6) kommt man eh nicht um einen hohen Port herum. Zumindest habe ich für die betreute Nachbarschaft noch keinen Anbieter wie zB. "feste-ip.de" mit entsprechenden Angebot gefunden.

 

[Tosoboso]

Hallo zsaummen,
die Frage wurde bereits im Post "Webapp-Got-lost?" beantwortet: https://www.synology-forum.de/showthread.html?106760-Webapp-Got-lost
Konkret ist der k4s Reverse Proxy das Äquivalent zum Virtual Host Alias im Legay JD. Zarafa, es leitet also auf Basis eines Verzeichnisses um (~/webapp, ~/z-push, ~/Microsoft-Server-ActiveSync).
Wenn man den k4s Directory Reverse-Proxy verwendet braucht man keine Subdomains, aber das ist Frage des Anwendungsfalls und Einige haben den k4s Reverse Proxy deaktivert, weil er Probleme macht (bei mir nicht, aber ich kann nicht 100e Synology Settings Nachstellen).
Der Synology Reverse Proxy unterstützt nur Subdomain auf / also Root und da Kopano unter Webapp läuft, wurde unter Root die Got-Lost Page erstellt, die mitlerweile übrigens nach Webapp ein Redirect macht. Sollte gg. verwirren, aber kein Problem sein.
Es muss eben auch möglich sein, mit Z-Push bzw. Active Sync auf k4s zugreifen zu können und ein "Verbiegen" des Reverse Proxy von / root auf /webapp kann unschöne Nebeneffekte haben.
Man könnte auch im k4s nginx / also Root immer auch webapp Umleiten und für z-push einen Alias setzen, das ist ggf. eleganter, aber müste Implementiert und Getestet werden, das ist gerade nicht Prio-1..
-TosoBoso