Checkliste Office 365 Netzwerk

Diese Seite ist ein ganz schnelle Auflistung und kurze Beschreibung der Microsoft Empfehlungen zu einer Office 365 Anbindung. Auf den folgenden Seiten finden Sie natürlich die tiefer gehenden Erklärungen. Dies also nur als "Einleitung" die ein Ziel hat: Einen zuverlässige und schnelle Verbindung zu ihren eigenen Daten, die nun in Office 365 liegen.

Einige Punkte der Checkliste können Sie recht einfach per Kommandozeile oder Browser überprüfungen. Einige Aussagen erfordern aber z.B: ein Blick in einen Paketmitschnitt von WireShark. Wenn Sie einen HTTP-Proxy einsetzen, dann haben Sie einmal die Verbindung vom Client zum Proxy und eine zweite Verbindung vom Proxy zu Microsoft zu überprüfen.

Topic Erfüllt

Lokale Internetzugänge

(Local internet Breakout)

Je länger eine Leitung ist und je mehr Zwischenstationen es gibt, desto höher ist die Latenzzeit. Aus meiner Sicht ist Latenzzeit die wichtigste Komponente, da Sie direkt auf die Performance und Reaktionsfreude einer Applikation Einfluss hat. Eine hohe Bandbreite hat automatisch auch eine niedrigere Laufzeit und ist schon daher schneller. Microsoft betreibt ein weltweites globales WAN und sie sollten immer den nächsten Zugangspunkt nutzen. Microsoft nennt dies "Hot Potato"-Prinzip, denn während Internet Provider Pakete möglichst schnell aus ihrem Netzwerk zu anderen Providern leiten um eigene Bandbreiten zu sparen, möchte Microsoft ihre Pakete gerne ganz schnell haben und baut daher Peerings mit den Providern um die Daten anzuziehen. Da hilft es aber nichts, wenn Sie ineffektiv über den falschen Weg gehen.

  • Local Breakout statt eigenes WAN
    Daher ist es fast immer besser jedem Standort einen Ausgang zum Internet oder zumindest zu Office 365 zu geben statt den Verkehr über eigene WAN-Strecken zu einem anderen Standort zu leiten
  • VPN und Split-Tunneling
    Auch mobile Anwender fahren besser, wenn die Verbindung zu Cloud nicht erst durch das VPN und damit zweimal über ihre Firmenanbindung muss

Microsoft steckt viel Geld in Verbindungen zu Providern, damit ihre Clients nicht nicht erst über eigene WAN-Leitungen oder VPNs zu einer Hub-Site müssen, um dann über das Internet zu Office 365 zu routen. Nutzen Sie das Backenend des MGN - Microsoft Global Network und entlasten sie ihr eigenes WAN. Ja, das bedeutet die Installation von Übergängen ins Internet in Filialen, die Abkehr von "Tunnel-VPNs" für Clients. Es bedeutet aber nicht, dass Sie überall nun Proxy-Server und Deep Inspection Firewalls installieren müssen. Sie können den Breakout ja "nur" für Office 365 Adressen zulassen. Das kann per Access-Liste, IP-Routing und Proxy-PAC-Datei sehr gut gesteuert werden.

Lokale DNS-Auflösung

(Local DNS-Resolution)

Mit Ausnahme von Audio/Video in Teams/Skype nutzen alle anderen Dienste voll qualifizierte Hostnamen. Über die Namensauflösung ihres PCs oder eines eventuell dazwischen geschalteten Proxy-Server findet ihr Client zum Cloud-Service. Der Cloud-Service sieht aber, woher die Anfrage kommt und kann daher den "besten Übergangpunkt" ermitteln. Prüfen Sie, ob die Auflösung nicht torpediert wird z.B. durch:

  • Falsche DNS-Server
    Es gibt Umgebungen, in denen wird nicht der DNS-Server des Zugangsproviders oder ein Root-Server gefragt. Wenn Sie stattdessen PublicDNS Provider wie Google (8.8.8.8 oder 8.8.4.4), 4nine (9.9.9.9), Cloudflare (1.1.1.1) oder andere nutzen, dann sieht Office 365 die Anfrage eventuell von einem anderen Subnetz und die Rückantwort ist nicht optimal
  • Zentral DNS mit Local Breakout
    Clients in einer Filiale mit einem eigenen Internet-Ausgang sollten auch über diesen Weg per DNS die externen Adressen auflösen und nicht die Zentrale fragen. Wenn ihr Niederlassung in Sao Paulo den Firmen-DNS in Deutschland als "Upstream"-Server fragt, dann bekommt er die IP-Adresse von Office 365 in Amsterdam. Der Client geht als aus Südamerika über das "allgemeine Internet" bis nach Amsterdam statt über das MGN
  • VPN-Software und Split Tunneling
    Mobile Anwender mit lokalem Internetzugang sollen vielleicht nicht per VPN über die Zentrale mit der Cloud arbeiten. Dann sollten Sie auch sicherstellen, dass der VPN-Client eben nicht jede Namensauflösung über das VPN sendet sondern mittels Direct Access Namensauflösung - NRPT nur die internen Domänen auch nach intern abgefragt werden.

Microsoft versucht die meisten DNS-Fehler dadurch zu lösen, dass eben nicht mehr mit GeoDNS / Pinpoint DNS gearbeitet wird sondern Anycast-Routing zum Einsatz kommt. Darauf verlassen sollten Sie sich aber nicht. Beachten Sie dazu auch Office 365: DNS-Routing

Bypass Proxy

Die meisten Office 365 Dienste nutzen HTTPS und natürlich können die meisten Zugriffe auch über einen bestehenden HTTP-Proxy geführt werden. Aber auch das ist nicht ratsam, denn es gibt nichts, was ein HTTP-Proxy besser machen könnte.

  • Content Inspection
    Die Daten im Office 365 Tenant sind ihre eigenen Daten. Es ist keine "unbekannte Webseite mit Malware, vor der die Anwender geschützt werden müssen
  • Authentifizierung
    Es mag noch Umgebungen geben, in denen ein "Internetzugriff" erst nach einer Authentifizierung zugelassen wird. Denken Sie in dem Zuge auch an Mitarbeiter, die eigentlich kein Internet nutzen dürfen aber Office 365 nutzen sollen. Sicher können Sie einen Bypass ohne Authentifizierung einrichten aber welchen Mehrwert hat generell eine Zuordnung zu Benutzern?
  • Caching
    Ein Proxy kann natürlich einmal erhaltene Daten im Cache für andere Clients vorhalten. Das gilt natürlich für öffentliche Start-Seiten, wobei selbst hier viele Anbieter Caching verbieten um eben die Anrufzahlen zu erhalten. Bandbreite ist wohl billiger und ausreichend vorhanden. Daten in Office 365 werden aber wohl eher selten im Cache landen, da es doch überwiegend individuelle Dateien sind und Uploads sind eh individuell.
  • SSL-Offloading
    Um Cachen und URL zu prüfen, muss ein Proxy die SSL-Verbindung aufbrechen. Das kostet CPU-Zyklen, eine eigene interne vertrauenswürdige PKI zum Ausstellen der Zertifikate und immer mehr Clients nutzen z.B. Zertifikat-Pinning oder andre Weg um genau diese Inspektion zu verhindern. Bei Office 365 ist das aktuell noch nicht der Fall aber darauf verlassen würde ich mich auf Dauer nicht.
  • Proxy und RTP
    Wenn Sie Audio/Video über die UDP-Ports 3478-3481 blocken, wird Skype for Business und Teams diese Daten eben über HTTPS/443 tunneln. Das wird gehen aber natürlich ist ein TCP und insbesondere ein SSL-Tunnel denkbar ineffektiv für RTP-Pakete. Daher ist für diese Payload auf jeden Fall ein Bypass zu planen.

Insofern würde ich Zugriff auf die Office 365 Ziele immer am Proxy vorbei führen und Microsoft liefert dazu ja auch vorbereitete PAC-Dateien. Heute ist es viel wichtiger, dass die Firewall auf IP-Port/Adresse-Paarungen und optional noch dem TLS-Handshake versteht, welche Payload zu erwarten ist und die Zugriffe entsprechend reglementiert.

Bypass Deep Inspection

Wobei Sie bei einer Firewall auch wieder beim "Deep Inspection" aufpassen müssen. Einige Firewalls verzögern speziell am Anfang einer Verbindung gerne einige Pakete um sich diese erst mal "anzuschauen" ehe diese dann durch gehen. DAs stört insbesondere den Start von Meeting und Telefonie. Aber auch andere Dienste sind schnell mal gestört, wenn eine Firewall "unklare" Pakete oder Verbindungen einfach stört.

Hier sollten Sie genau hinschauen, mit Whitelists arbeiten oder zumindest eine Eskalationsmöglichkeit haben.

CRL Erreichbarkeit

Die Kommunikation zu Office 365 ist prinzipiell verschlüsselt. Dazu nutzt Microsoft entsprechende Zertifikate. Ihr Client wird und sollte natürölich die Gültigkeit der Zertifikate prüfen. Dazu muss der Client die CRL - Certificate Revocation List erreichen können.

Idealerweise ist die CRL für jeden Client aus jedem Netzwerk ohne besondere Authentifizierung o.ä. erreichbar, damit diese erforderlichen Prüfungen entsprechend schnell erfolgen.

Windows Scaling aktiv

Der Betrieb von Diensten in der Cloud unterscheidet sich von lokalen Servern dahingehend, dass die Laufzeit der Pakete ein vielfaches einer lokalen Verbindung ist. TCP kann damit recht gut umgehen, wenn es denn alle Funktionen nutzen kann. Beim Windows Scaling wird den Partnern erlaubt, bis zu 1GB Buffer für die Übertragung von Daten zu nutzen. Nur so kann auf langen Strecken der Durchsatz hoch gehalten werden, da der Sender nicht auf eine sofortige Quittung wartet. Ein Blick in WireShark sorgt für Klarheit

TCP Idle Timeout >120Sek

Wenn ein Client gerade keine Daten mit dem Server austauscht, müssen Proxy-Server oder NAT-Router dennoch einen Status pflegen, damit eine Rückantwort auf eine ausstehende Anfrage auch noch zugestellt werden kann. Laut RFC kann eine Verbindung ohne Übertragungen bis zu 2h offen sein. So lange wartet heute keine Firewall mehr. Timeouts sind deutlich geringer. Sie dürfen aber nicht zu klein sein, da ansonsten Anwendungen keine Updates bekommen oder häufiger fragen. ein Wert von 2 Minuten sollte nicht unterschritten werden.

Dies können Sie z.B. mit einem TELNET oder SSH auf ein entferntes System testen, welches nicht wegen Inaktivität sie trennt. Wenn Sie nach einige Minuten dann wieder eine Taste drücken sollte die Gegenseite auch antworten

TCP Max Segment Size 1460bytes

Bei der Übertragung von Paketen über das Kabel gibt es Obergrenzen pro Paket. Das klassische Ethernet-Paket ist maximal 1514 Bytes groß, wovon für die darunter liegenden Protokolle noch einige Bytes abgezogen werden müssen. Prüfen Sie mit WireShark, dass die Paketgröße nicht durch einen Konfigurationsfehler auf Proxy, Router oder Firewall kleiner als nötig ist.

Oft sind es Teilstecken eines WAN oder VPNs, die kleinere Pakete erzwingen. Größere Pakete werden vom Router entweder aufgeteilt und auf der anderen Seite wieder zusammen gesetzt oder das Paket wird abgelehnt. Dann liegt es am Sender die Pakete zu verkleinern, was natürlich den Durchsatz limitiert.

Hier sehen Sie die Paketgröße, die mein Client anbietet. Im nächsten Paket sehen Sie dann das Angebot der gegenüberliegenden Seite bzw. was ein Router oder Firewall auf dem Weg daraus gemacht hat.

SACK - Selective Ack

Diese Erweiterung erlaubt es bereits empfangene Pakete zu quittieren und gezielt dazwischen verlorengegangene Pakete oder Blöcke noch mal anzufordern. Damit ersparen Mehrfachübertragungen und beschleunigen den Datentransfer. Auch hier ist ein Blick auf das Paket hilfreich.

Round Trip Time (RTT)

Aus meiner Sicht ist die Zeit für die Übertragung eines Pakets samt der Quittung noch wichtiger als die Bandbreite. Wenn die Bandbreite auf der gesamten Strecker irgendwo zu knapp ist, dann erhöht sich Laufzeit. Über eine RTT-Messung können Sie daher viel besser ermitteln, wie es um die Verbindung steht.

Betrachten sie Office 365 nicht als "Internet" sondern als ihr persönlich ausgelagertes Datacenter. Allerdings müssen Sie schon abwägen, wie Sie z.B. Zugriffe auf die eigenen SharePoint Seiten und OneDrive-Bereiche von Zugriffen auf freigegebene Daten anderer Tenants unterschieden werden.

Weitere Links

Ignite 2018 BRK3000 – Strategies for building effective, optimal and future proof connectivity that will delight your users
https://myignite.techcommunity.microsoft.com/sessions/64275

Ignite 2018 BRK3081 – Implementing a modern network architecture to get the most out of Office 365
https://myignite.techcommunity.microsoft.com/sessions/64276

Ignite 2018 BRK4006 – Performance in the cloud: Portals, pages, networking and more
https://myignite.techcommunity.microsoft.com/sessions/65665