Exchange 2013: Konfiguration von Mailversand interner Geräte

Neben dem Mailversand für Benutzermailboxen muss Exchange oft auch die Auslieferung von Nachrichten für interne Geräte wie Scanner, Storage oder Applikationsserver übernehmen. In diesem Artikel zeigt Markus Hengstler, wie eine ausfallsichere Lösung umgesetzt werden kann.

Autor Markus Hengstler
Datum 30.06.2015
Lesezeit 5 Minuten

Neben dem Mailversand für Benutzermailboxen muss Exchange oft auch die Auslieferung von Nachrichten für interne Geräte wie Scanner, Storage oder Applikationsserver übernehmen. Für einige dieser Szenarien drängt sich eine ausfallsichere Lösung auf: zum Beispiel für eine Monitoring-Software, die Benachrichtigungen an die Administratoren schicken muss oder den SAN-Storage, der den Ausfall einer Disk automatisch an den Hersteller meldet, damit Ersatz geliefert werden kann. In diesem Artikel zeige ich auf, wie dies umgesetzt werden kann.

Ausgangslage

Ich gehe davon aus, dass mindestens 2 Multi-Role Server mit Exchange 2013 vorhanden sind – ich habe ja schon in vorherigen Artikeln auf die Vorteile mehrer Server und der Umsetzung von Microsofts Preferred Architecture hingewiesen. Dies bedeutet auch, dass ein Loadbalancer in Hardware- oder virtueller Appliance-Form implementiert sein muss, um die Client-Zugriffe auf die CAS-Rollen der Server zu verteilen. Wenn ein Kunde schon ein Produkt im Einsatz hat, verwende ich das normalerweise. Falls nicht, empfehle ich die Produkte der Firma Kemp Technologies, da sie ein sehr gutes Preis-Leistungs-Verhältnis aufweisen und einfach zu konfigurieren sind. Die Screenshots in diesem Artikel stammen von einem Kemp Virtual Load Master oder kurz VLM.

Die Umgebung sieht also wie in folgender Zeichnung aus:
konfiguration-mailversand-interne-geraete-exchange-2013-digicomp-1
Üblicherweise wird auf den Loadbalancern nun ein Listener eingerichtet, der auf einer virtuellen IP den Port TCP25 (SMTP) abhört. Den Verkehr leitet er an beide Exchange Server weiter – genauer gesagt an die Client-Access-Rolle und den Frontend-Transport-Dienst. Auf diesem Dienst sind die sogenannten Receive Connectors konfiguriert, die Einstellungen wie Authentisierungsoptionen oder Erlaubnis zum Relayen beinhalten. Ich schlage jeweils zwei Konnektoren für interne Geräte vor: einen zum Versand nur an interne E-Mail-Adressen und einen weiteren, der auch den Versand an externe Empfänger erlaubt. Gesteuert wird der Zugriff auf die Konnektoren über die IP-Adressen der sendenden Geräte. Und da beginnt genau das Problem in diesem Setup …

Microsoft Exchange Trainings

Für mehr Informationen zu Exchange 2013 und 2016 besuchen Sie einen der folgenden Kurse.

Zu allen Exchange-Server-Trainings

Für mehr Informationen zu Exchange 2013 und 2016 besuchen Sie einen der folgenden Kurse.

Zu allen Exchange-Server-Trainings

Das Problem

Wie oben erwähnt dient die Quell-IP-Adresse des SMTP-Senders Exchange als Entscheidungskriterium, welchen Konnektor er verwenden soll und damit auch, welche Sicherheitseinstellungen. Nun werden aber oft die Loadbalancer als NAT Device konfiguriert, d.h. sie ersetzen die Quell-IP-Adresse in den Paketen der Clients mit einer eigenen, damit die Antwort wieder über sie zurückgeroutet wird. Damit kann der Exchange Server den Verkehr nicht unterscheiden. Wir können also zwischen zwei Übeln wählen:

Variante 1

NAT (Setting «Transparency» deaktiviert)konfiguration-mailversand-interne-geraete-exchange-2013-digicomp-7

konfiguration-mailversand-interne-geraete-exchange-2013-digicomp-3

Hier funktioniert der zusätzliche Receive Connector für RELAY nicht und die internen Geräte können nicht nach extern senden.

Variante 2

Ohne NAT (Setting «Transparency» aktiviert – Default)

konfiguration-mailversand-interne-geraete-exchange-2013-digicomp-6

konfiguration-mailversand-interne-geraete-exchange-2013-digicomp-4

Hier wird zwar der RELAY Receive Connector erreicht, aber Netzwerkgeräte wie Router oder erst recht Firewalls blockieren den unangeforderten Verkehr von Exchange zurück zum Gerät, da dieser einen anderen Pfad nimmt.

Die Lösung

Die eleganteste Lösung verwendet einen zweiten Listener auf dem Loadbalancer, der auf einer weiteren IP-Adresse Port TCP25 abhört. Da der Loadbalancer die IP des Listeners als Source für das NATing verwendet, lässt sich der Receive Connector RELAY darauf einstellen. Damit dennoch der Zugriff eingeschränkt werden kann, muss auf dem Listener des Loadbalancers eine IP Whitelist geführt werden. Dies bietet auch noch den Vorteil, dass Anpassungen nur an einem Ort gemacht werden müssen, im Gegensatz zu der Konfiguration der Receive Connectors, die auf allen Exchange Servern durchgeführt werden müsste.

konfiguration-mailversand-interne-geraete-exchange-2013-digicomp-5

Fazit

Die Konfiguration des hochverfügbaren Versands von E-Mails erfordert einiges Wissen über die Netzwerkinfrastruktur und die Funktionsweise der Loadbalancing-Lösung, damit mögliche Stolpersteine umgangen werden können.


Über den Autor

Markus Hengstler

Markus Hengstler arbeitet bei der UMB AG als Senior Systems Engineer in den Bereichen Exchange, Windows und Citrix. Dank seiner Erfahrungen in diesen Bereichen ist er zertifizierter «MCSE: Server Infrastructure». Ausserdem ist er einer von drei «MCSM: Messaging» in der Schweiz. Seit 2001 unterrichtet er als Microsoft Certified Trainer und seit 2010 als Citrix Certified Instructor bei Digicomp.