Checkliste Netzwerk

Seit vielen Jahren ist meine Netzwerk-Expertise bei Microsoft 365 Projekten und insbesondere mit Microsoft Teams gefragt. Dazu führe ich ganztägige Workshops zur Wissensvermittlung und Assessment des Netzwerks durch. Auf dieser Seite stelle ich einige Prüfungen vor, die sie auch selbst durchführen können um einige mögliche Fehler zu erkennen.

Diese Checkliste ersetzt keine intensivere Beschäftigung mit dem Thema. Cloud-Dienste erfordern eine enge Abstimmung zwischen "Netzwerk-Team" und "Service-Verantwortliche". Erschreckend viele Netzwerk-Spezialisten wissen gar nicht welche Anforderungen die verschiedenen Applikationen an das Netzwerk stellen und selbst die Mitarbeiter, die eine Applikation einführen gehen kaum in die Tiefe. An der Stelle komme ich als Moderator, Erklärer und Berater zum Einsatz.

Grundlagen – Verstehen sie Prinzipien

Im Workshop werden die Prinzipien zur Nutzung von Cloud-Diensten nicht nur aufgeführt, sondern auch die Auswirkungen und Effekte bei Nichtbeachtung technisch vorgestellt.

Beachten Sie dazu auch die Checkliste zur Prüfung der Grundlagen für Administratoren auf
Office 365 Netzwerk Empfehlungen

Daher ist es wichtig, sich diese Grundlagen immer wieder in Erinnerung zu bringen und in Gedanken "abhaken".

Prüfung

Status

Latenzzeit

Die Optimierung der Latenzzeit ist neben ausreichend Bandbreite wichtig. Die Cloud-Dienste sind immer „weiter weg“ als ein lokaler Server und die Laufzeit der Pakte hat einen direkten Einfluss auf die erreichbare Performance.

Lokale Breakouts statt interner WANs

Daher ist darauf zu achten, dass der Weg vom Client zum Service optimiert wird. Umwege über interne Routings oder VPN-Tunnel sind kontraproduktiv und sollten vermieden werden. In den meisten Fällen sollte ein Client vor Ort ins Internet, damit der Cloud-Anbieter die Daten sehr früh in seinem eigenen Netzwerk weiterleiten kann

Kurze Wege über das Internet

Optimaler weise hat der Zugangsprovider (ISP) selbst ein Peering zum Microsoft Global Network, so dass die Daten gar nicht mehr über ein öffentliches Peering laufen müssen

Namensauflösung folgt dem IP-Routings

Es ist wichtig, dass die Namen der Zielsystem nicht über „falsche“ DNS-Server erfolgt. Suboptimal sind Fremd-Server (8.8.8.8, 1.1.1.1, 9.9.9.9, 114.114.114.114) oder interne DNS-Server an einem anderen internen Standort

Optimierung Homeoffice/VPN

Der Umweg vom Homeoffice-Provider über ein öffentliches Peering zum Firmenprovider und doppelt durch den Firmenanschluss und den VPN-Server ist deutlich langsamer als ein lokaler VPN-Bypass für bekannte Ziele. Werden die Pakete dann noch durch TCP oder gar http getunnelt, ist die Audio/Video-Qualität nur selten zu erreichen.

UDP statt TCP

Die meisten Cloud-Dienste nutzen HTTPS als Transport. Sonderfälle wie Audio/Video nutzen zu Recht und geplant UDP als Protokoll, damit auf Jitter und Paketloss reagiert werden kann und nicht der TCP-Stack Verluste reparieren will, die nicht korrigiert werden müssen. Microsoft Teams und fast alle anderen Konferenzlösungen fordern eine UDP-Erreichbarkeit.

Proxy-Optimierung

Die Dienste der “eigenen Cloud“ sind wie interne Services mit zwingender Authentifizierung zu sehen, die in der Regel auch nicht über Proxy- oder Cloudproxy-Server mit Authentifizierung oder SSL-Inspection geroutet. Ein Proxy-Bypass entlastet zudem den Proxy von diesen unkritischen Verbindungen, damit er ungestört die eigentlichen Internetverbindungen kontrollieren kann. Speziell ein Aufbrechen der SSL-Verbindung ist kontraproduktiv, wenn Dienste wie ADSync mit MTLS arbeiten.

Dies ist aber nur eine Kurzfassung. Weitere Informationen finden Sie z.B. auf den Seiten Cloud Verbindung, Office 365 Netzwerk Empfehlungen u.a.

Checkliste

Für die weiteren Prüfungen und Checks gehe ich davon aus, dass der Administrator die Grundprinzipien (Office 365 Netzwerk Empfehlungen) verstanden und umgesetzt hat.

„Wer sein Auto zum TÜV bringt, sollte schon selbst vorher Beleuchtung, Profiltiefe, Verbandkasten, Wischwasser etc. prüfen.“

Basierend auf den Prinzipien lassen sich auf dem Client einige Prüfungen durchführen. Die Befehle nutzen die PowerShell 7. Frühere Versionen unterstützen ggfls. nicht alle Parameter. Wenn Sie heute schon wissen, dass Sie die anfangs aufgeführten Grundprinzipien nicht einhalten können, dann werden die folgenden Prüfungen dies nur bestätigen. Die Prüfungen haben das Ziel, mögliche Konfigurationsfehler aufzudecken.

All diese Tests können auf dem Client durch den Anwender oder 1st Level durchgeführt werden.

Prüfung

Status

Traceroute zum Cloud-Service

Zuerst sollten Sie sich den Weg von ihrem Client zum gewünschten Cloud Service anschauen. Viele Server sind erreichbar und wenn Sie nicht sicher sind, dann können Sie die Exchange Service nutzen.

tracert outlook.office.com
Test-Connection -TargetName outlook.office.com -Traceroute

Schauen Sie sich die verschiedenen Zwischenstationen genau an.

Hier sind mehrere Dinge interessant:

  • Lokaler ISP
    Verlassen die Pakete ihr Netzwerk über den erwarteten Provider und Übergabepunkt und wie weit ist dieser in Hops und Millisekunden entfernt. Verlieren Sie schon viel Zeit im WLAN oder im internen WAN zur Zentrale oder nutzen Sie den lokalen Ausgang?
  • Weg zu "*.msn.net
    Server im Microsoft Global Netzwerk enden per DNS auf msn.net. Welche Provider gibt es dazwischen und wie lange dauert die Übertragung? Ein guter Provider hat vielleicht ein direktes Peering zu Microsoft und ist wenige Millisekunden entfernt.
  • MSN Eingangstor
    An welchen Übergabepunkt von Microsoft kommen Sie an? Anhand des DNS-Namens können Sie meist die geografische Region ermitteln
  • IPv6
    Prüfen Sie auch , ob vielleicht eine IPv6-Auflösung gelingt und der Weg darüber schneller ist. Bei meinem Zugang erspart IPv6 einen Hop und damit den Umweg über das Carrier Grade NAT

Wenn wie hier keine Reverse-Auflösung erfolgt, können Sie dennoch anhand des IPv6-Netzwerks die Provider-Grenzen erkennen.

Public IP-Adresse prüfen

Über Dienste wie „WhatIsMyIP“ u.a. kann die öffentliche IP-Adresse des Breakouts ermittelt werden. Sie können aber auch einen eigenen Webservice bereitstellen, der ihnen die IP-Adresse liefert. Das kann sogar einfach eine PHP-Seite auf ihrer öffentlichen Webseite oder einem Hoster sein, den Sie dann per URL abfragen können. Eine minimale Version ist folgendes PHP-Skript:

<?php
header('Content-Type: text/html; charset=utf-8'); 
echo "IP=",getenv('REMOTE_ADDR') , ":", getenv('REMOTE_PORT');
?>

Wenn Sie diesen Code als PHP-Datei auf eine geeignete Webseite kopiert haben, können Sie diese aufrufen und das Ergebnis sehen.

(Invoke-WebRequest https://<your webpage>/getip.php).content

Über die IP-Adresse kann dann der Provider bzw. Geo-Region geprüft werden. Um unterschiedliche Routings und Proxy-Konfigurationen zu prüfen, können Sie solche Dienste auf unterschiedlichen Plattformen nutzen.

NAT/Port-Limits (IPv4)

Eine aktive Prüfung der NAT-Portlimits kann nicht vom Client erfolgen. Kontrollieren Sie auf Firewall/Proxy die genutzten NAT-Ports über die Zeit und ermitteln Sie die Obergrenze.

DNS over TCP

Die meisten DNS-Abfragen erfolgen über UDP und den Port 53. Wenn die Antwort aber länger als 512 Zeichen ist, dann schaltet die DNS-Abfrage auf TCP um. Es gibt Firewalls, die 53/TCP nicht per Default erlauben. Siehe dazu auch DNS, TCP und 512 Bytes oder rufen Sie folgenden Befehl in der PowerShell auf

Resolve-DNSName -Type TXT dns512.msxfq.net

Sie sollten einige TXT-Einträge sehen. Bei einem Fehler wie "esolve-DnsName: dns512.msxfq.net : Der DNS-Name ist nicht vorhanden." funktionierte DNS over TCP nicht.

Outlook Namensauflösung

Über DNS kann der Exchange Frontend Server bestimmt werden.

(Resolve-DnsName -Type A outlook.office.com -NoHostsFile) `
| Where-Object {$_.Type -eq "A"}

Die ersten drei Buchstaben des Namens stehen für den IATA-Flughafencode des Datacenter und sollten geografisch in der „Nähe“ liegen, z.B. AMS= Amsterdam, HHN = Frankfurt Hahn. Eine Auflösung zu einem komplett anderen Kontinent ist ein Zeichen für die Nutzung eines falschen DNS-Servers.

Der TTL ist meist 10 oder geringer. Ein höherer TTL kann einen DNS-Server anzeigen, der eigene Cache-Vorgaben nutzt.

Outlook Proxy

Ein Grundprinzip ist ein Bypass eines Proxy und einer Deep Inspection. Über das FAVICON von Exchange Online kann relativ einfach die Erreichbarkeit ohne Proxy geprüft werden.

Invoke-Webrequest https://outlook.office.com/owa/favicon.ico -proxy $null
Invoke-Webrequest https://outlook.office.com/owa/favicon.ico

Der Zugriff auf Outlook und andere Dienste sollte ohne Proxy (= Proxy Bypass) möglich sein. Ohne Proxy-Verbot sollte kein Kennwortdialog kommen. Mittels Browser auf die URL kann z.B. das präsentierte TLS-Zertifikate geprüft werden.

Teams Transport Relay Auflösung

Für die Übertragung von Audio/Video nutzt der Teams Client ein Transport Relay in Microsoft 365. Die Auflösung des geografisch „nächsten“ Relays erfolgt per Geo-DNS

(Resolve-DnsName -Type A worldaz.tr.teams.microsoft.com -NoHostsFile) `
| Where-Object {$_.Type -eq "A"}

Teil der Antwort ist die Region des Datacenters, z.B. „northeurope“, „westeurope“, „francecentral“, „swedencentral“ o.ä. Wichtig ist auch hier ein Datacenter auf dem gleichen Kontinent.

Teams UDP statt TCP

Audio und Video werden am besten über UDP übertragen. Sie müssen aber besonders formatierte UDP-Pakete senden, damit Microsoft Teams auch reagiert. Ohne entsprechende Tools wie Rimscout, End2End-UDP3478 oder das Skype for Business Network Assessment Tool können Sie nur in den Teams Report Datenbanken sehen, welche Anwender TCP statt UDP genutzt haben.

Ggfls. sollten Sie in Teams die Media-Ports (50.000-50059) vrgeben und optional DSCP konfigurieren.

Prüfen Sie in der Firewall, ob ausgehende Verbindungen zu den Microsoft Transport Relays über Port 3478-3481 erlaubt sind:

Netzwerke: 13.107.64.0/18, 52.112.0.0/14, 52.122.0.0/15, 2603:1063::/39
Ports: 3478-3481/UDP

Wenn Sie einen anderen Konferenzdienst (WebEx, Meet o.a.) nutzen, dann prüfen Sie auch die hierfür erforderlichen Ports.

SharePoint

Mit den Namen ihres Tenants können Sie per HTTPS ebenfalls die Erreichbarkeit von SharePoint und OneDrive prüfen.

Invoke-Webrequest https://<tenant>.sharepoint.com -proxy $null
Invoke-Webrequest https://<tenant>-my.sharepoint.com -proxy $null

Der Zugriff sollte zuverlässig, schnell und ohne Inspektion erfolgen.

Monitoring

Dienste in der Cloud müssen anders überwacht werden als lokale Server, bei denen eher die Erreichbarkeit und Performance im Vordergrund stehen. Bei Cloud-Diensten können Sie meist nur die Verbindung überwachen. Dazu reicht es aber nicht, die Pakete an ihrem Übergang ins Internet zu zählen und zu „wiegen“.

  • Latenz statt Bandbreite
    Bandbreite ist wichtig aber ist nur ein Maß für die ersten Strecke. Eine Überwachung der Latenzzeit erlaubt ihnen Probleme auf der gesamten Strecke zu erkennen
  • Percentil statt Average
    Mittelwerte taugen speziell bei VoIP nicht, wo nur wenige langsame Pakete die Qualität beeinflussen. Siehe auch End2End Werte
  • Engmaschig statt „alle Minute“
    Wenn ihre Clients viele Pakete pro Sekunde zu den Cloud-Diensten senden, dann sollten sie nicht nur einmal in der Minute prüfen, wie schnell dies möglich ist. Für Datenverbindungen ist eine sekündliche Überwachung sinnvoller und bei Audio/Video ist eine noch engere Kontrolle ratsam
  • Erreichbarkeitstest um interne Konfigurationsfehler auszuschließen
    Die oben genannten Prüfungen sollten Sie möglichst automatisiert und regelmäßig auf allen Clients durchführen, um Konfigurationsfehler nicht erst bei Supporttickets zu erkennen

Die Analyse von Microsoft über einen Ausfall am 23. Jan 2023 zeigt sehr gut den Unterschied der eigenen Überwachung am Netzwerkpunkt und die gefühlte Funktion beim Client.

Beachten Sie dazu auch die Seite End2End ClientCheck und Rimscout

Nächste Aktionen

Dies ist eine verkürzte und auf Office 365 beschränkte Checkliste. Heutige Firmen nutzen aber durchaus weitere Cloud-Dienste. Denken Sie z.B. an:

  • Webex, Zoom, TeamViewer, BBB, Jitsi
    Natürlich gibt es auch andere Konferenz-Systeme neben Teams, welche die gleichen Herausforderungen und ähnliche Konfigurationsempfehlungen haben. Es wäre schon interessant und wichtig, diese Voraussetzungen einzurichten und auch die Erreichbarkeit und Performance zu prüfen
  • SAP, Sales Force, CRM
    Es ist keineswegs unüblich heute kritische Lösungen zur Buchhaltung, Vertrieb, Unternehmenssteuerung in die Cloud auszulagern. Meist ist ein Browser der Client und vielleicht hat der Anbieter auch Telemetrie-Funktionen eingebaut. Aber meist haben Sie darauf keinen Zugriff oder es gibt sie schlicht nicht.
  • Success Factors, Worksite, Personio
    Selbst Personalverwaltung wird heute in der Cloud angeboten und genutzt und natürlich sollten Sie sie Regeln der Firewall entsprechend eintragen und die Verbindung von jedem Client prüfen.
  • DATEV
    Denken Sie einmal an all die Steuerberater, die auf ihrem PC eigentlich im Rechenzentrum in Nürnberg arbeiten?
  • Confluence, Jira u.a.
    Es muss ja nicht Wikipedia sein. Firmen nutzen neben SharePoint gerne andere Plattformen
  • Eigene Cloud Dienste
    Sie können als Firma natürlich auch eigene Dienste in Azure, AWS oder einem anderen Hoster bereitstellen. Auch hier könnten Sie die Erreichbarkeit von ihren Clients prüfen wollen.
  • Eigene On-Premises-Dienste
    Es muss nicht immer die Cloud sein. Für Anwender im Homeoffice oder auf Reisen ist selbst ihre On-Premises-Umgebung eine "Cloud". Das kann der VPN-Zugangspunkt der Firma, das Intranet, der lokale Exchange Server oder ein Terminal Services Gateway sein, um nur ein paar Beispiele aufzuführen.
  • WLAN-Stärke, WLANSSID, Default Gateway, Standort, CPU, RAM u.a.
    Um ein komplettes Bild für eine Fehleranalyse zu erhalten, sollten Sie aber noch mehr Daten des Clients erfassen.

All diese Dienste nutzen aber die vergleichbaren Verbindungen wie auch Microsoft 365 und mein Wunsch als Administrator oder Consultant ist es natürlich, dass ich von allen Clients die Information bekomme, dass alle genutzten Dienste nicht nur erreichbar sondern vor allem optimal erreichbar sind. Genaugenommen müssten Sie nun die Checkliste erweitern und dann auf jedem Client die Checkliste immer wieder abarbeiten. Das werden Sie hoffentlich nicht von Hand ausführen und sichtbare PowerShell-Skripte sind auf dem Anwender-PC auch nicht der richtige Weg.

Wenn Sie auf allen Endgeräten diese und weitergehende Prüfungen durchführen wollen, dann sollten Sie sich z.B. Rimscout anschauen. Ein kleiner Client bekommt zentral die Prüfungen vorgegeben, die er ausführt, an eine zentrale Stelle berichtet und als Bericht bereitstellt. https://www.rimscout.com

Weitere Links