Exchange 2016 Reverse Proxy mit pfSense 2.4 und HAProxy

Motivation für diesen Beitrag: Veröffentlichung von Exchange 2016 mittels Reverse Proxy und vorhandener pfSense. Es bietet sich HAproxy an, denn es gibt ein recht gut gepflegtes Package dafür. Weiterhin besteht die Möglichkeit neben dem Loadbalancing auch ACLs zu nutzen um z.B. Pfade zu filtern. Oftmals wird es nicht genutzt weil die Verknüpfung der Frontend ACLs nicht so trivial ist. Um euch die Einarbeitung zu ersparen habe ich mal schnell ein paar Screenshots gemacht. Diese sollten bei euch direkt zu einem „Aaaahhh“ Effekt führen. Ich fange jetzt nicht an wie man das Package installiert und die HAproxy Grundeinstellungen macht wie Zertifikate einspielen oder die Stats-Seiten aktivieren etc.
Ich nutze für mein Beispiel mal den Fall von zwei Anwendungen die über eine externe IP per Subdomain zugänglich gemacht werden sollen. Der primäre Service ist natürlich der Exchange, der zweite Dienst wird „shared“ eingerichtet:Wir benötigen ein Frontend auf die externe IP und den Realserver (Exchange) im Backend. Hier meine Definition vom Backend für den Exchange 2016:

Wenn man mehrere Exchange Server im DAG Cluster betreibt, muss man einfach die weiteren Realserver unter Punkt 2 hinzufügen.
Nun gehts an Frontend. Hier der Überblick über die zwei angelegten Frontends:

In der Definition vom Frontend entscheidet sich welche URL wird aufgerufen, welcher Port und welcher Pfad.
Grundlegend wird festgelegt auf welche IP (WAN Address) und Port der Service hören soll:
Nun werden die ACL und ACTION erstellt. Das ist wohl der Grund warum viele Howtos hier mit einer einfachen TCP Weiterleitung vorlieb nehmen. Dabei ist das gar nicht so schwer:
Folgende Annahme: die externe URL ist „exchange.domain.tld“ und der Pfad „/owa“ oder „/mapi“. Also der Aufruf wäre https://exchange.domain.tld/owa.
Wenn nun eine Anfrage am HAproxy ankommt, muss er diese Anfrage in URL und Pfad zerlegen, erkennen und verarbeiten können. Dafür müssen wir als erstes einige Definitionen unter „Access Control lists“ anlegen die wir in den „Actions“ nutzen können. Den Hostnamen legen wir als ACL „hostname_exchange“ mit der Bedingung „Host matches“ und dem Wert „exchange.domain.tld“ an. Anschliessend definieren wir die Pfade mit der ACL „path_exchange“ mit der Bedingung „Path contains“ und den entsprechenden Werten der Pfade wie „/owa, /mapi etc“. Diese kann man bei „Path contains“ durch Leerzeichen getrennt eingeben.
Nun können wir aus diesen zwei Bedingungen eine „Action“ bauen. Beide Bedingungen müssen ja zutreffen. Damit die beiden angelegten Bedingungen auch „UND“ verknüpft werden, muss man sie in der „Action“ bei „Condition acl names“ einfach hintereinander durch Leerzeichen getrennt hinschreiben. Wenn also die Bedingung „hostname_exchange“ und „path_exchange“ zutreffen wird auf das Backend „Exchange_Backend“ weitergeleitet. Jede andere nicht definierte URL oder Pfad wird mit einem Fehler seitens des HAproxys quitiert.
Nun noch das Zertifikat für dieses Frontend angeben:
Jeder andere Service wird wie dieser Exchange als „shared“ Frontend veröffentlicht:

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*