AW: Verbindungsprobleme mit Exchange Online geloest
Zürcher David Roa
david.zuercher at bfh.ch
Wed Sep 1 08:04:23 CEST 2021
Hallo Daniel
Besten Dank für die Aufklärung 😊.
Lieber Gruss
Dave
-----Ursprüngliche Nachricht-----
Von: bfh-linux-announce <bfh-linux-announce-bounces at lists.bfh.science> Im Auftrag von Daniel Baumann
Gesendet: Mittwoch, 1. September 2021 07:06
An: bfh-linux-announce at lists.bfh.science
Betreff: Verbindungsprobleme mit Exchange Online geloest
Hallo zusammen
In den letzten Tagen gab es zunehmend Verbindungsprobleme aus dem BFH Netzwerk zu den Exchange Mailservern in der Microsoft Cloud. Dies hat sich von einzelnen Verbindungsproblemen bis hin zur vollstaendigen Unbenutzbarkeit der E-Mail Dienste entwickelt.
Ursache war dass die Universitaet Bern, ueber welche wir ans schweizer Hochschulnetz (SWITCH) und ans Internet angebunden sind, die Microsoft Mailserver auf unserer Netzwerk-Anbindung gesperrt hat.
Seit gestern Dienstag, 11:45 Uhr ist diese Sperre wieder entfernt und E-Mail ist uneingeschraenkt verfuegbar.
Im Folgenden die Hintergrund-Informationen und weiteren Massnahmen.
1. DNS Round Robin
==================
Wenn ein Mailclient (egal ob Thunderbird, Outlook oder was anderes; betrifft alle die auf Exchange Online migriert worden sind) sich mit den Microsoft Mailservern verbindet, so tut er das mit outlook.office356.com und/oder outlook.office.com.
Diese DNS Eintraege sind sogenannte Round-Robin, d.h. es gibt mehre IP Adressen die fuer diesen Eintrag zwecks Load Balancing zu Performance und Redundanz hinterlegt sind:
---schnip---
$ kdig outlook.office365.com
outlook.ha.office365.com. 10 IN A 52.97.201.194
outlook.ha.office365.com. 10 IN A 52.97.201.242
outlook.ha.office365.com. 10 IN A 52.97.186.146
outlook.ha.office365.com. 10 IN A 52.97.201.210
outlook.ha.office365.com. 10 IN A 52.98.168.178
outlook.ha.office365.com. 10 IN A 52.98.163.18
outlook.ha.office365.com. 10 IN A 52.97.232.194
outlook.ha.office365.com. 10 IN A 52.97.201.226
---schnap---
Ein Client kann sich dann frei auswaehlen, welche der Adressen er verwenden moechte, in der Regel wird einfach die erste Antwort genommen (die in aller Regel von den antwortenden DNS Servern immer rotiert wird, damit nicht immer die gleiche Adresse zuoberst steht).
2. Internet Anbindung via Universitaet Bern ===========================================
Die BFH verfuegt ueber keinen direkten Anschluss ans Internet, sondern ueber eine redundante Anbindung (2x 10gbit) ans schweizer Hochschulnetz
(SWITCH) und damit ans Internet via die Universitaet Bern.
D.h. in unserem Rechenzentrum in Bern gehen zwei Glasfaserkabel zur unibe, und von da weiter nach Zuerich. Der gesamte Traffic passiert dabei den unibe Border-Router. Das ist fuer uns oekonomischer weil dadurch die Anschlussgebuehren fuer SWITCH signifikant tiefer sind.
Als zusaetzlicher Service verhindert die Universitaet Bern so indirekt einen Teil der Attacken (DoS, DDoS) aus dem Internet gegen unsere Systeme weil wir denselben Uplink benutzen. Solche legitimen Sperrungen von Adressen oder Adressbereichen sind nur jeweils kurzfristig fuer ein paar Stunden notwendig und kommen insgesamt sehr selten vor (ein, zwei mal pro Jahr). Das macht die unibe seit vielen Jahren unaufgefordert so und dafuer sind wir sehr dankbar, das hat in den letzten 10 Jahren ein paar mal groesseren Schaden/Ausfaelle auf unserer Seite verhindert.
3. Aktuelle Sperrung der Microsoft Server =========================================
Die Netzwerkverantwortlichen der unibe haben in den letzten Tagen ein erhoehtes Traffic-Aufkommen zu den Microsoft Mailservern bemerkt.
Das ist einerseits erklaerbar durch die weitere Migration unserer User auf Exchange Online, andererseits durch Ende der Ferienzeit und vermehrter Vorort-Praesenz der Mitarbeitenden.
Leider hat unibe selbststaendig entschieden, immer mehr Mailserver von Microsoft zu blockieren. Schlussendlich waren gestern so 8 von den 10 verfuegbaren Mailservern geblockt.
Der Effekt war dass ein Client fuer jede Verbindung jeweils sich "durchprobieren" musste, bis er einen der 2 noch funktionierenden Server erwischt hat. Das aeusserte sich in extrem langsamem Zugriff oder keinem Zugriff auf Mails, und ebenso eingeschraenkten Mailversand.
Allerdings war das Verhalten jederzeit diskret, d.h. wenn eine Mail versendet werden konnte, wurde sie auch versendet. Ansonsten gab es auf dem Client eine entsprechende Fehlermeldung dass der Mailserver nicht erreicht werden kann und man konnte es nochmal probieren.
Verstaerkt wird der Effekt dadurch dass die DNS Records eine Time-to-Life (TTL) von nur 5 Sekunden haben, d.h. ein Client fragt bei praktisch jeder Verbindung nochmal neu nach Adressen an. Somit konnte ein Client nicht davon profitieren, einmal einen funktionierenden Mailserver erwischt zu haben, sondern das "2 aus 10"-Durchprobieren faengt (spaetestens) alle 5 Sekunden wieder von vorne an.
Die Sperrung dieser Server wurde durch die unibe manuell (also nicht aufgrund oder Teil eines automatischen Systems) und ohne Kommunikation zur BFH vorgenommen. Wir haben darauf ensprechend reagiert, siehe unten.
4. Debugging (Drop vs. Reject, resp. Inbound vs. Outbound) ==========================================================
Grundsaetzlich kann man Traffic auf zwei Arten sperren - man kann entweder still die Netzwerkpakete verwerfen (drop) oder aktiv zurueckweisen (reject).
In konventionellen Netzen wird haeufig noch gedropt, was dazufuehrt dass Netzwerk-Clients in (lange) Timeouts laufen. Dafuer werden die Netzwerkgeraete minimal weniger belastet weil ein Verwerfen weniger Prozessierungs-Aufwand generiert als ein aktives Zurueckweisen.
In der heutigen Zeit ist ein drop, ausser in Nischenfaellen von sehr grossen Distributed-Denial-of-Service (DDoS) Attacken, nicht mehr empfehlenswert und auch nicht mehr noetig. Aktuelle Systeme koennen Rejects problemlos abarbeiten. Ein aktives Reject ist daher immer zu bevorzugen, weil dadurch unmittelbar die Netzwerkteilnehmer die Verbindung abbrechen und Fehler sich sofort bemerkbar machen. Dies insbesondere dann wenn mehrere Systeme hintereinander arbeiten, so dass sich keine langen Timeout-Ketten bilden koennen.
Wuerden alle "reject statt drop" machen, waere das Internet (oder das jeweilige Teilnetz) fuer alle besser/schneller. Im neuen BFH Netzwerk machen wir grundsaetzlich ueberall reject, im alten Netzwerk haben wirs seit der Uebernahme im Mai 2020 ueberall dort wo sinnvoll moeglich und an den neuralgischen Punkten ebenfalls auf reject umgestellt.
Analog zu "reject statt drop" wird konventionell leider haeufig auch nur eingehender Traffic (inbound) gesperrt, statt beide Richtungen zu sperren. Weil dadurch ausgehender Traffic (outbound) zu den gesperrten Adressen immer noch moeglich ist, verhaelt es sich fuer alle Netzwerkteilnehmer wie bei einem Drop: sie laufen in ein Timeout rein weil sie auf die (nicht eintreffende) Antwort warten muessen.
Wuerden Sperrungen auf Router-Ebene auf inbound und outbound Traffic gemacht (auch hier sind heutigen Systeme mehr als nur performant genug, Traffic in beide Richtungen sperren zu koennen), waere der Effekt der Sperrung der Mailserver gewesen, dass gar kein Mail mehr funktioniert haette.
Das waere zum Debuggen wesentlich einfacher gewesen. Zusammen mit der Erwartungshaltung dass wir komplett ungefiltertes Internet von der unibe erhalten, haben wir zuerst doppelt-und-dreifach unsere eigenen Systeme ausgeschlossen (Firewall, Border, etc.), ein "Rueckwaertskanal"-Problem im Peering zwischen Microsoft und SWITCH vermutet (das ist auch das was man per traceroute sieht: traffic hin zu MS funktioniert, aber zwischen MS und SWITCH kommt nichts mehr zurueck weil MS via SWITCH nicht zustellen kann weil unibe nicht annimmt).
Dashalb haben wir erst als Letztes mit der unibe im Verlauf des Dienstag Vormittags Kontakt aufgenommen. Diese haben dann schlussendlich schnell reagiert und die Sperrung ensprechend wieder entfernt.
5. Massnahmen
=============
* Wir haben der unibe unsere Erwartungshaltung zu ungefiltertem
Internet kommuniziert, ebenso die Anforderung nach zeitnaher
Kommunikation bei Eingriffen und dem Wunsch nach mehr Feingefuehl
bei (vermeintlich legitimen) Sperrungen - die gesperrten Adressen
waren klar ersichtlich aus dem Microsoft SaaS Bereich.
Wir haben gleichzeitig der unibe auch unseren Dank ausgesprochen
fuer die legitimen, temporaeren Sperrung in Notfall-Situationen in
den letzten Jahren (DoS, DDoS) und den ansonsten bisher immer sehr
guten Service und Zusammenarbeit.
unibe wird nun die internen Prozesse ueberarbeiten und uns
informieren.
* Wir haben die vollstaendige Liste aller gesperrten Adressen und
Ports verlangt und erhalten. Wir werden diese in den naechsten Tagen
bereinigen (d.h. alles entsperren lassen was nicht gesperrt sein
muss; wir haben bereits einige weitere illegitime Sperrungen von
Systemen gefunden).
* Langfristig: in Hinblick auf den Campus Biel ist eine
Diversifizierung der Internet-Anbindung durch einen eigenen,
separaten Internet-Aufgang im dort neu aufzubauenden Rechenzentrum
in Biel vorgesehen.
Dadurch kann nicht nur eine Performance-Verbesserung fuer die
Standorte in Biel erreicht werden, sondern auch eine Verbesserung
fuer die Gesamt-BFH durch Provider-Unabhaengigkeit und oertliche
Redundanz geschaffen werden.
6. Fun Fact
===========
Die Sperrung der Microsoft Mailserver hat nich nur die BFH betroffen, sondern neben der unibe (definitiv) selbst auch (vermutlich) alle der unibe Internet-anbindungstechnisch angehaengten Institutionen wie PH Bern und das Insel Spital.
Die Einschraenkung war fuer alle Teilnehmenden gleichermassen verheerend. Trotzdem waren wir offenbar die ersten die den Effekt der Sperrung bemerkt haben. Ob wir die Ersten sind die grossflaechig auf Exchange Online setzen, oder ob alle in den Ferien oder im Homeoffice sind, oder einfach keine E-Mails lesen/verschicken.. wissen wir natuerlich nicht :)
Wir danken fuer euer Verstaendnis.
Gruesse,
Daniel
--
Berner Fachhochschule / Bern University of Applied Sciences Services / IT-Services Daniel Baumann Teamleiter Linux & Infrastructure Services ___________________________________________________________
Dammweg 3, CH-3013 Bern
Telefon direkt +41 31 848 48 22
Telefon Servicedesk +41 31 848 48 48
daniel.baumann at bfh.ch
https://bfh.ch
https://bfh.science
--
bfh-linux-announce mailing list
bfh-linux-announce at lists.bfh.science
https://lists.bfh.science/listinfo/bfh-linux-announce
More information about the bfh-linux-users
mailing list