Vor knapp zwei Jahren erstellte ich hier einen Artikel, wie man grundsätzlich einen SMTP Relay mit NetScaler konfigurieren kann (hier). Im Rahmen einer Datacenter Migration kam das Thema ACL für diesen Relay auf. Im genannten Artikel wurde sauber beschrieben, wie man den Exchange auf den ADC als Quelle konfigurieren kann. Wie kann man nun aber die Quellen seitens Loadbalancer einschränken?

Wer schon mit dem ADC gearbeitet hat weiss, dass dieser Access Control List (ACL) als Funktion bietet, jedoch ist die Konfiguration dieser eher statisch als dynamisch. Ich arbeite jedoch in einem Umfeld, in welchem die zugelassenen Server immer wieder mal ändern können (bei über 1000 Servern kein Wunder). Daher habe ich ein wenig Recherchiert und bin auf einen Lösungsansatz mittels Responder Policies gestossen, welchen ich hier dokumentiere.

Als erstes muss das Loadbalancing für den SMTP Relay konfiguriert werden. Ich nehme dazu als Basis den letzten Artikel und schmücke diesen mit ein wenig mehr Backend-Servern aus:

add server pitex01 192.168.100.31
add server pitex02 192.168.100.32
add service svc-smtp-pitex01 pitex01 TCP 25
add service svc-smtp-pitex02 pitex02 TCP 25
add lb vserver lb-vsrv-mailrelay.domain.pit-SMTP TCP 192.168.100.90 25 -persistenceType SOURCEIP -timeout 10 -netprofile NP-192.168.100.12
bind lb vserver lb-vsrv-mailrelay.domain.pit-SMTP svc-smtp-pitex01
bind lb vserver lb-vsrv-mailrelay.domain.pit-SMTP svc-smtp-pitex02

Nun bauen wir unsere Responder Policy. Damit die Pflege der Quell IPs ein wenig einfacher ist, nutzen wir dazu die sogenannten Data Sets (ähnlich wie Pattern Sets, jedoch für Daten wie IP Adressen) und verweisen in unserer Policy darauf. Als Aktion nehmen wir die vordefinierten „RESET“ Aktion.

add policy dataset DS_MailRelay ipv4
bind policy dataset DS_MailRelay 192.168.100.21 -index 1
bind policy dataset DS_MailRelay 192.168.100.22 -index 2
add responder policy rs_pol_ACLMailRelay "CLIENT.IP.SRC.TYPECAST_TEXT_T.CONTAINS_ANY(\"DS_MailRelay\").NOT" RESET

Schlussendlich müssen wir nur doch die neu erstellte Policy dem SMTP Relay Loadbalancer zuweisen und ab sofort nimmt dieser nur noch Anfragen von IPs an, welche im Data Set „DS_MailRelay“ definiert sind.

bind lb vserver lb-vsrv-mailrelay.domain.pit-SMTP -policyName rs_pol_ACLMailRelay -priority 100 -gotoPriorityExpression END -type REQUEST

alias „Restore-Exchange-Services-After-Failed-Update-Skript“

Bei einer Installation von Exchange Updates deaktiviert das Setup als erstes die relevanten Dienste und stoppt diese um das System zu schützen. Bei einem Fehlschlag der Installation kann dies jedoch dazu führen, dass danach alle Dienste deaktiviert bleiben. Passiert schon nicht? Leider habe ich dies schon auf einem Kunden- sowie auf meinem Testsystem gesehen.

Microsoft bietet einen entsprechenden KB-Artikel, in welchem alle Dienste inkl. dem Standard-Startmodus aufgeführt sind. Man kann nun die Liste akribisch durchgehen und anschliessend die Dienste starten, oder aber man nutzt ein Skript.

Ich habe mit meinen bisher noch kleinen PowerShell Kenntnissen ein kleines Skript zusammengestellt, welches folgendes durchführt:

• benötigte Windows Dienste auf „Automatisch“ stellen und gleich starten
• vorausgesetzte Exchange Dienste auf „Automatisch“ stellen und gleich starten
• restliche Exchange Dienste gem. Microsoft Standard konfigurieren
• Alle Dienste, welche auf „Automatisch“ stehen kontrollieren und starten, falls diese gestoppt sind (Ausnahme: Software Protection)

Ich bin mich wieder frisch am Einarbeiten in das Thema Exchange.

Das Grundsetup mit Exchange 2016 habe ich recht schnell hingekriegt und auch den externen Zugang via NetScaler war dank eines Skriptes von meinem Kollegen einfach hergestellt. Nun wollte ich jedoch noch für div. Dienste einen einfachen internen SMTP Relay Server erstellen.

Eine erste Anleitung dazu fand ich dann relativ schnell bei Paul Cunningham (Link).

Leider funktionierte dies nicht ganz so im Web GUI. Der Grund lag einfach gesagt an einem Bug von Microsoft und die Lösung war Powershell. Die Anleitung dazu fand ich dann bei Jeff Guillet (Link).

Nun funktionierte mein SMTP Relay zwar wenn ich den Exchange Server direkt ansteuerte, jedoch nicht via NetScaler. Und dies wollte ich dann auch noch lösen:

Die Ursache warum ich via die bereits eingerichtete NetScaler Konfiguration den SMTP Relay nicht ansteuern konnte war mir recht schnell klar. Der Exchange Server unterscheidet die Empfangskonnektoren jeweils anhand der Quell-IP und via NetScaler ist dies immer die SNIP.

Was musste nun getan werden?

Dem Exchange Server müssen verschiedene Quellen vorgegaukelt werden. Im NetScaler kann dies mittels einer weiteren SNIP eingerichtet werden. Wichtig hierbei ist jedoch, dass die jeweiligen SNIP Adressen den richtigen vServern mittels Net Profiles zugewiesen werden, da ansonsten die Appliance mittels Round Robin die SNIP wechselt.

Schritt 1 – Erstellen einer weiteren SNIP und Konfiguration der Net Profiles:

add ns ip 192.168.100.12 255.255.255.0 -vServer DISABLED -gui DISABLED
add netProfile NP-192.168.100.11 -srcIP 192.168.100.11
add netProfile NP-192.168.100.12 -srcIP 192.168.100.12

Schritt 2 – Erstellen eines weiteren LB vServers für den SMTP Relay:

add lb vserver lb-vsrv-mailrelay.domain.pit-SMTP TCP 192.168.100.90 25 -persistenceType NONE
bind lb vserver lb-vsrv-mailrelay.domain.pit-SMTP svc-smtp-pitex01

Schritt 3 – Net Profiles den LB vServern korrekt zuweisen:

set lb vserver lb-vsrv-mail.domain.pit-SMTP -netprofile NP-192.168.100.11
set lb vserver lb-vsrv-mailrelay.domain.pit-SMTP -netprofile NP-192.168.100.12

Schritt 4 – Empfangskonnektor für SMTP mit neuer SNIP konfigurieren:

Und nun viel Spass beim Nachbauen :-)

Quellen: The EXPTA {blog} & exchangeserverpro.com

Skript: NS-ExSMTPRelay