Tntnet hinter einem Apache betreiben

Es gibt viele Gründe, die eigene Tntnet-Applikation hinter einem Apache betreiben zu wollen. Hier ein paar Beispiele die mir spontan einfallen:

• Der Port 80 ist bereits von einer anderen Applikation belegt, die in einem Apache-Webserver läuft (klassischerweise PHP)
• Das ssl/https-Handling möchte man lieber in einem Apache-Webserver abbilden, da sich das Personal damit besser auskennt.
• Es soll eine Funktionalität vorgeschaltet werden, die als Apache-Modul implementiert wurde. Ich denke da z.B. an die Web Application Firewall ModSecurity
• Das Load Balancing-Konzept basiert auf Apache (-Technologie)

Ein Revers Proxy für eine Tntnet-Applikation einzurichten, ist schnell erledigt. Aber zunächst noch kurz erklärt, was ein Revers Proxy macht. Der Revers Proxy in Apache nimmt die Anfragen für die Tntnet-Applikation entgegen und reicht die Anfrage an die Tntnet-Applikation weiter. Diese verarbeitet die Anfrage und gibt sie dem Apache zurück, der die Daten an den Browser ausliefert.

Die Tntnet-Applikation kann dafür jeden beliebigen Port verwenden und auf jedem beliebigen Server laufen, der für den Apache (dem Revers Proxy) erreichbar ist (also auch private IPs aus dem internen Netz). Wenn die Tntnnet-Anwendung auf dem selben Server wie der Apache läuft, kann Tntnnet nicht den Port 80 verwenden, das ist klar.

Hier ist eine Beispielkonfiguration. Die Konfiguration für den Revers Proxy wird am Besten in einer separaten Datei und nicht in die Hauptonfiguration von Apache abgelegt. Alle Dateien die auf .conf enden und auf dem Verzeichnis  /etc/httpd/ liegen, werden automatisch vom Apache gelesen. In diesem Beispiel werden zwei Szenarien abbildet: Es gibt zwei Applicationen,  die auf den selben Host laufen, jeweils auf Port 8001 und 8002. Auf Port 8001 soll die Tntnet-Applikation laufen und auf Port 8002 läuft noch eine Applikation in Tomcat (Jave-Applikation-Server).

Die Anfragen, die von Außen kommen und nach Domain „peruschim.de“ fragen, werden von dem Revers Proxy weitergeleitet auf "http://localhost:8001/". localhost:8002/ander-applikation. Wird wiederum nach "peruschim.de/ander-applikation" gefragt, wird der Revers Proxy die Anfrage auf "localhost:8002/ander-applikation" weiterleiten. Hier die vollständige Datei:

#NameVirtualHost *:80
#NameVirtualHost *:443

<VirtualHost *:80>
    ServerName peruschim.de
    ServerAlias www.peruschim.de

    ProxyPass /ander-applikation   http://localhost:8002/ander-applikation
    ProxyPassReverse /ander-applikation http://localhost:8002/ander-applikation

    ProxyPass /   http://localhost:8001/
    ProxyPassReverse / http://localhost:8001/

</VirtualHost>

<VirtualHost *:443>
    ServerName peruschim.de
    ServerAlias www.peruschim.de

    SSLEngine On
    SSLCertificateFile /etc/httpd/ssl/httpd.pem
    SSLCertificateKeyFile /etc/httpd/ssl/httpd.key

    ProxyPass /ander-applikation   http://localhost:8002/ander-applikation
    ProxyPassReverse /ander-applikation http://localhost:8002/ander-applikation

    ProxyPass /   http://localhost:8001/
    ProxyPassReverse / http://localhost:8001/</VirtualHost>

Im zweiten Abschnitt, der den Post 443 definiert, wird die ssl/https Verbindung konfiguriert,  wenn vom Browser das https-Protokoll über Port 443 angefordert wird, z.B die URL "https://peruschim.de" aufgerufen wird. In diesem Fall nutzt die Tntnet-Application und die Tomcat-Application das selbe Zertifikat. Die ssl-Verbindung wird hier von Apache gemanagt und nicht von Tntnet oder Tomcat. Das ginge zwar auch, aber dann müsste die ssl-Verwaltung mit drei völlig unterschiedlichen Systemen und Konzepten einrichtet werden.

Das hier gezeigte ist erweitertes Admin-Wissen. Da Entwickler selten mit dem Betrieb ihrer Application betraut sind, würde ich dieses Wissen nicht als selbstverständlich voraussetzen. Es gibt noch einen wichtigen Punkt, den vor allem Entwickler wissen müssten, damit ihre Application hinter einem Revers Proxy funktionieren kann. Bei ihren internen Links (die auf Ziele innerhalb der Application zeigen) dürfen sie keine IPs oder Domains verwenden, die nicht von außen erreichbar sind. Wenn man also absolute Pfade wie "http://localost/irgendwas" oder "http://127.0.0.1/irgendwas" verwendet, kann dies Browser aus dem Internet (per DNS) nicht auflösen. Es müssen also relative Pfade wie „/irgendwas“ verwendet werden. Möglich ist es auch, die korrekte Domain zu verwenden. Also wenn wir beim obigen Beispiel bleiben, wäre dies: "http://www.peruschim.de/irgendwas".  Wenn die Tntnet-Applikation selbst nicht weiß, wie sie für das Internet hinter dem Revers Proxy heißt, wird das keine Option sein. Zudem wäre die Lösung sehr unflexibel. Der Domainname könnte nicht geändert werden, ohne den Code anzupassen.

Man kann auch versuchen, den Reverse Proxy in den auszuliefernden HTML-Code schauen zu lassen und die IPs/Domains auszutauschen, die nur Intern bekannt sind. Das ist aber umständlich und fehlerträchtig. Mein Rat an die Entwickler: besser immer relative Pfade verwenden! Für die Admins: wer diesen steinigen Weg aber trotzdem gehen will/muss, der sei auf diesen Artikel über mod_proxy_html verwiesen.

---

Related articles

• Best Practice nicht Best (wahrscheinlich) (bildungundgutesleben.wordpress.com)