Exchange-Troubleshooting – Fall 1: Netzwerke
In seiner langjährigen Erfahrung mit Exchange Server musste Markus Hengstler schon manche Knacknuss lösen. In einer kleinen Blogserie stellt er einige knifflige Fälle vor.
In einer kleinen Blog-Serie möchte ich Exchange-Troubleshooting-Fälle aus der Praxis vorstellen. Dabei handelt es sich nicht um die alltäglichsten Probleme, aber vielleicht begegnen Sie einmal einer vergleichbaren Situation und erinnern sich an das Gelesene. Es wird vorausgesetzt, dass Sie die Architektur und Komponenten von Exchange und einiger wichtiger Umsysteme kennen und verstehen. Ich beginne die Serie mit dem Thema «Netzwerk».
Fall 1: Kein Client-Zugriff aus dem Remote Office
Beim betroffenen Kunden wurde eine zentrale Exchange-Infrastruktur in Form eines 4-Node DAG Clusters implementiert. Die Nodes sind über zwei grössere Standorte verteilt und befinden sich hinter einer GEO-Loadbalancing-Lösung und je Lokation einem HA-Paar Kemp Loadbalancer.
Der Zugriff auf Exchange funktionierte mit allen Clients aus diesen beiden Standorten, aber nicht aus den kleineren Büros, die über ein IPSec VPN angeschlossen sind. Wir testeten die allgemeine Kommunikation der Clients mittels PING- und DNS-Abfragen und konnten kein Problem feststellen. Verbindungen mit Outlook oder auch mit dem Browser hingegen führten nur zu einem Timeout.
Interessant war, dass nach Umgehung der Loadbalancer durch einen Eintrag im Host File der Clients alles ordnungsgemäss funktionierte. Die Loadbalancer selbst konnten aber auch nicht das alleinige Problem sein, da die Verbindungen innerhalb der grossen Standorte und sogar zwischen diesen keine Fehler zeigten.
Der Vergleich je eines Netzwerk-Traces von Client, Loadbalancer und Exchange Server zeigte, dass die TCP-Verbindung vom Endgerät zu Exchange korrekt weitergeleitet wurden, aber die Antwort auf den SSL-Handshake ab dem Loadbalancer keine brauchbare Payload mehr aufwies.
 |
Microsoft Exchange TrainingsFür mehr Informationen zu Exchange 2013 und 2016 besuchen Sie einen der folgenden Kurse. |
Für mehr Informationen zu Exchange 2013 und 2016 besuchen Sie einen der folgenden Kurse.
Zuerst verdächtigten wir die FW/VPN-Infrastruktur, aber eine Verbindung direkt auf Exchange funktionierte ja. Schliesslich brachte ein Ping mit verschiedenen Paketgrössen die Erkenntnis, dass die maximale MTU-Grösse auf dem Loadbalancer und die Einschränkung der Payload-Grösse durch den VPN-Tunnel für das Fehlverhalten verantwortlich waren. Die Reduktion der MTU Size von 1500 auf 1438 ermöglichte sofortige Kommunikation.
Fall 2: Kein Client-Zugriff aus dem Remote Office
Das Problem im zweiten Fall stellte sich ähnlich dar wie bei Fall 1. Benutzer im gleichen Standort wie die Exchange Server und der Loadbalancer konnten auf ihr Postfach zugreifen, diejenigen in einem kleineren, angehängten Standort hingegen nicht. Auch hier war ein Loadbalancer im Spiel – wurde dieser umgangen, konnten die Benutzer mit Exchange arbeiten.
Die eingesetzten Kemp Loadbalancer können Dienste auf zwei Arten über ihre virtuelle IP an den Backend Server weiterleiten: mit der ursprünglichen Quell-IP oder durch ihre eigene IP ersetzt (NAT). Dies wird auch Transparency genannt. Ist diese konfiguriert (default), müssen die Antworten insbesondere dann wieder über den Loadbalancer zurückgeleitet werden, wenn ein Netzwerkgerät mit Sicherheitsfunktionen involviert ist. Aus dessen Sicht wäre sonst durch die verschiedenen Wege keine gültige TCP-Verbindung zustandegekommen. Die Backendserver müssen somit die Loadbalancer als Gateway verwenden oder die Transparency muss ausgeschaltet werden.
Fall 3: Kein Mailfluss zwischen den Exchange Servern zweier Standorte
In diesem Fall geht es um einen Exchange 2010 Server im Standort des Kunden und einen Exchange 2016 Server in unserem Datacenter. Der Rahmen ist eine Migration, d.h. der Legacy Server wird nach dem Verschieben aller Mailboxen deinstalliert. Die Migration einer Testmailbox funktionierte auch soweit, Zugriff und Mailfluss von und nach Internet waren ebenfalls in Ordnung.
Allerdings konnten Benutzer mit Postfächern auf Exchange 2010 keine Mails an Benutzer auf Exchange 2016 senden und umgekehrt. Ein Test mit Telnet zeigte, dass zwar die Netzwerkverbindung auf TCP25 aufgebaut, aber schon das Banner der Verbindung nicht korrekt angezeigt wurde.
Normalerweise sieht das in etwa so aus:
220 smtp.umb.ch ESMTP
Beim Kunden hingegen so:
220 ******************************************
Glücklicherweise kannte ich dieses Verhalten von einem anderen Fall und konnte relativ schnell die Cisco ASA Firewall als Verursacher identifizieren. Diese hat einen standardmässigen, globalen ESMTP Check aktiviert, der die Verbindungen ziemlich zuverlässig verhindert.
Fazit
Netzwerkgeräte sind wichtige Komponenten jeder Exchange-Umgebung. Troubleshooting kann aber ziemlich aufwändig sein und erfordert einiges an Grundwissen und Erfahrung.
In diesem Zusammenhang empfehle ich eine Ausbildung zum Cisco Certified Network Associate. Das vertiefte Wissen in den Bereichen Switching und Routing erlaubt eine einfachere Kommunikation mit Netzwerkspezialisten bei der Fehlersuche.