Mit dem Aufsetzen eines neuen Servers auf Basis von Debian 9 kamen wieder einige neue Dinge auf mich zu. Da ich mich für die Mailserver-Groupware Mailcow-Dockerized von André Peters entschieden hatte, musste ich mich erstmals mit einem Reverse Proxy auseinander setzten.
Wozu brauche ich einen Reverse Proxy?
Auf dem neuen Server sollte neben dem Webserver ein Mailserver installiert werden. Da Mailcow-Dockerized eine Container-Lösung ist und in diesem Container neben Postfix, Dovecot und Co. auch der Webserver Nginx läuft, würden aber die Ports 443 und 80 mit dem zuvor installierten Apache, auf dem eine Test-Webseite aktiv ist, kollidieren.
Um Mailcow zu installieren, musste zuerst der Apache gestoppt werden. Der Mailserver wurde dann in ein paar Minuten aufgesetzt und eingerichtet. Das Mailcow UI konnte wie gewünscht via HTTP und HTTPS erreicht werden. Im Anschluss wurde die Konfiguration nochmals geöffnet, um die Bindung an die Ports 80 und 443 entsprechend in 8080 und 8443 in der /root/mailcow.dockerized/mailcow.conf zu ändern.
|
1 2 3 4 5 |
HTTP_PORT=8080 HTTP_BIND=127.0.0.1 HTTPS_PORT=8443 HTTPS_BIND=127.0.0.1 |
Natürlich hätte man das auch während der Installation durchführen können, jedoch wollte ich zuvor die testen, ob der Mailserver ordnungsgemäß läuft.
Nach dem nochmaligen Durchlauf der Konfigurationsänderungen, konnte nun das Mailcow UI natürlich von außen nicht mehr aufgerufen werden.
Nun wurde der Apache wieder gestartet und die Test-Websites ging wieder online.
Erstellen eines neuen VirtualHost
Um nun auch den Nginx in Mailcow-Dockerized zu erreichen, musste ein Reverse Proxy eingerichtet werden. Dazu habe ich einen VirtualHost, welcher auf Port 80 und Port 443 lauscht, in einer neu erstellten /etc/apache2/sites-available/proxy.conf mit folgendem Inhalt eingerichtet. Dieser leitet die Anfragen von mail.domain.tld an den Nginx im Container weiter. Das hatte zur Folge, dass die alten Zertifikate aus Mailcow-Dockerized unbrauchbar wurden. Ich habe darauf hin mein bestehendes Zertifikat um die Subdomain https://mail.domain.tld erweitert. Der Ort, wo die Zertifikate hinterlegt sind, musste im Codeblock (siehe unten) noch eingetragen werden.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
<VirtualHost *:80> ServerName mail.domain.tld RewriteEngine On RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L] ProxyPass / http://127.0.0.1:8080/ ProxyPassReverse / http://127.0.0.1:8080/ ProxyPreserveHost On ProxyAddHeaders On </VirtualHost> <VirtualHost *:443> ServerName mail.domain.tld ProxyPass / http://127.0.0.1:8080/ ProxyPassReverse / http://127.0.0.1:8080/ ProxyPreserveHost On ProxyAddHeaders On # This header does not need to be set when using http RequestHeader set X-Forwarded-Proto "https" SSLCertificateFile /etc/letsencrypt/live/domain.tld/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/domain.tld/privkey.pem Include /etc/letsencrypt/options-ssl-apache.conf </VirtualHost> |
Nach einem erneuten Neustart des Apache2 lief alles wie gewünscht, sowohl die Test-Webseite, als auch das Mailcow UI.
Weiterführende Infos und Anleitungen findet man auf der Projektseite von Mailcow-Dockerized unter: https://mailcow.github.io/mailcow-dockerized-docs/
Nachtrag
Zu beachten gilt, dass für die Subdomain mail.domain.tld ein separates Zertifikat erstellt werden muss, da das in Mailcow-Dockerized vorhandene nicht mehr funktioniert. Zur Erstellung eines validen SSL-Zertifikats kann man auf die Anleitung „Let’s Encrypt auf dem Raspberry Pi“ zurück greifen.
Toller Blogeintrag!!! Da ich mich gerade mit Docker beschäftige bzw. einlese kommt mir dein geschriebenes wie gerufen. Nur frage ich mich wieso dein Webserver nicht in einem Container läuft. Gibt es dafür einen Grund?
Danke für den Kommentar!
Warum mein Webserver nicht in einem Container läuft ist schnell zu beantworten. Ich sehe dafür im Moment keinen Bedarf. Ich bin ehrlich gesagt froh, dass im Moment alles rund läuft. 😉
You are the best! Thanks so much.
Hi, läuft das Setup soweit noch vernünftig? Habe auch einen Apache2 laufen und möchte Mailcow in der Dockerized Variante nutzen, ohne den Apache in den Container zu packen bzw. meine Website. Empfiehlst du das Setup noch so weiter mit dem Reverse Proxy?
Der Artikel ist schon drei Jahre alt, aber der Reverse Proxy läuft fast noch ganz genau so. Ich habe nur HTTP/2 inzwischen eingepflegt.