WAN Optimierer Cloud
Bandbreiten waren lange kostbar und viele Protokolle wie z.B. SMB sind nicht wirklich auf hohe Latenzzeiten optimiert. Produkte wie Riverbed und andre WAN-Scaler haben schon lange ihren Platz im Markt gefunden, um WAN-Zugriffe zu optimieren, indem Daten gecached und komprimiert werden oder früher Quittungen simuliert werden. Auch Office 365-Dienste sind ja über eine WAN-Leitung zu erreichen und da stellt sich die Frage, ob hier eine Optimierung sinnvoll ist.
Überlegungen
Microsoft beschreibt sehr ausführlich, wie Sie ihre Clients über das Haus-LAN, ihren Carrier zum Microsoft Netzwerk verbinden und idealweise das "Internet" fast komplett aus der Verbindung eliminieren. In einer Kurzfassung:
- Der schlechte Ansatz
Ich hoffe, dass ihre Firma nicht mehr an der klassischen "Hub and Spoke"-Topologie festhält, bei der alle Clients über das eigene WAN noch bis zum zentralen Internet-Breakout laufen müssen und dann der Weg über einen schlecht angebundenen Carrier über das Internet geht.
Dieses Bild stimm für Webseite im allgemeinen Internet aber nicht mit Office 365 - Das Microsoft Global Netzwerk
Die Office 365 Dienste sind nicht das "klassische Internet", wie es viele Webseiten sind. Microsoft hat sehr viele Peerings zu Providern und Carriern, so dass der Weg über das nicht qualitativ gesicherte Internet möglichst kurz ist.
Wenn Sie hier aber weiterhin ihre zentralistische Zugangsstruktur haben, dann verschenken Sie Bandbreite und Latenzzeit - Optimierung durch Local Breakout
Wenn es nach Microsoft geht, dann hat jeder Standort eine eigene Internet-Verbindung und kann hier zumindest Richtung Office 365 direkt das eigene LAN verlassen und nur kurz über den Provider laufen.
Local Breakout und Security
Dennoch gibt es natürlich weitere Überlegungen. den Weg zum Internet noch weiter zu verbessern. Gerade die letzte, von Microsoft favorisierte, Anbindung ist für viele IP-Security-Abteilungen ein Horrorszenario. Über den Weg wäre ja nicht nur Office 365 und Azure gut zu erreichen, sondern auch jeder andere Service wie Dropbox, Google, Amazon etc. Das kann gewollt sein aber keine Firma möchte hier eine offene Tür für Malware bereitstellen. Wenn eine Firma aber sehr viele Standorte mit lokalen Internet-Ausgängen hat, dann geht der Aufbau und Betrieb einer verteilten Schutzfunktion ins Geld.
Da kommen dann Angebote wie Zscaler und Co gerade recht, die einen Proxy in der Cloud anbieten und dort für den Kunden als Managed Service den Zugangsschutz bereitstellen. Teilweise muss dazu einfach nur der passende Proxy auf allen Clients eingetragen und der direkte Weg in die Cloud verhindert werden. Andere Konfigurationen bauen auf einen VPN-Tunnel zum Cloud-Anbieter und setzten gleich das Default Routing über den Cloud Service.
Dabei gibt es aber zwei Konfigurationen zu unterscheiden. Technisch reicht es ja, wenn der Security-Anbieter ihnen einen Zugang über einen Proxy-Server in der Cloud bereit stellt und die Clients diesen Service erreichen müssen. Allerdings ist das nicht nur Hop mehr in der Kette, sondern es ist auch zu klären, an welcher Stelle der Proxy in Realität steht
- Proxy im Internet
Dann haben Sie im schlimmsten Fall einen langen Weg von ihrem Provider zum Proxy und der Proxy selbst muss dann über seine eigene Verbindung zu Microsoft. - Proxy bei Microsoft
Es scheint sich mittlerweile einzupendeln, dass die Anbieter ihre Proxy-Server schon möglichst nahe bei Microsoft, idealerweise direkt in Azure, aufstellen, und so schon von der ansich guten Anbindung von Microsoft an Kunden profitieren und der Weg von Azure zu den Microsoft diensten minimal ist.
Allerdings muss der Anbieter dann die Preise für seine Azure-Umgebung entsprechend weiter geben.
Nicht alle Anbieter spielen hier mit offenen Karten und die Topologie verändert sich ja auch immer wieder. Hinsichtlich Office 365 ist natürlich zu sagen, dass ein direkter Weg zu Office 365 immer vorzuziehen und und Sie mittels Proxy.PAC-Steuerung auch sehr elegant bestimmte IP-Adressen und Namen direkt zu Office 365 und nur "Internet-Traffic" durch den Schutzfilter routen.
Ansonsten sollten Sie nicht nur hinterfragen, wo die Proxy-Server ihres Dienstleisters stehen sondern vor allem auch deren Anbindung zu beiden Seiten bewerten. Die Firma Zscaler habe ich in unterschiedlichsten Kundenumgebungen gesehen. Sie veröffentlichen auch ihre Standorte und IP-Adressen und haben einige KB-Artikel, die öffentlich sind.
- Firewall Configuration Requirements
https://ips.zscloud.net/ -
https://ip.Zscaler.com
Prüft, ob der Traffic über Zscaler läuft oder nicht -
https://trust.Zscaler.com/
Echtzeitstatus der Topologie -
Deploy Office 365 quicker and deliver a fast
user experience
https://www.Zscaler.com/solutions/office-365-deployment - About Microsoft One Click Options
https://help.Zscaler.com/zia/about-microsoft-one-click-options - About Office 365
https://help.Zscaler.com/zia/about-office-365 - About Bandwidth Classes
https://help.Zscaler.com/zia/about-bandwidth-classes - About DNS Control
https://help.Zscaler.com/zia/about-dns-control
Insbesondere einen Artikel des Zscaler Community möchte ich hier zitieren:
Even if an explicit proxy (PAC file/ZApp)
is set on a client the Teams / Skype for Business (S4B) will
first attempt to connect via the more optimal UDP ports, and
if those are unreachable it will look for less optimal
methods such as explicit proxy via TCP.
Fortunately with Zscaler Internet Access you are able to
combine explicit and transparent traffic forwarding methods.
Therefore the recommendation for Zscaler customers using
Teams / S4B is be to ensure that a) clients can DNS resolve
internet addresses for Teams / S4B and b) there is a
suitable path for Teams UDP ports to get out to MS.
Quelle:
https://community.Zscaler.com/t/microsoft-teams-with-Zscaler/6320
Natürlich kommt dann noch die Werbung, dass man den Verkehr auch über den GRE-Tunnel zu Zscaler und deren "Internet Access"-Lizenz und "Adv. Firewall", wenn Sie auch die UDP-Verbindungen durch den GRE/IPSEC-Tunnel zu Zscaler routen.
Wenn Sie auch DNS-Abfragen über die Zscaler-Topologie routen, dann sollten Sie die gleichen Dinge beachten wie beim Einsatz von DNS-Servern (Siehe OpenDNS - besser nicht). Zscaler und andere Anbieter erlauben aber sogar den Aufbau einer VPN-Verbindung und routen den kompletten Verkehr ins Internet über die Filterlösung. Wenn der Schutz auch die Inhalte einer SSL-Verbindung überwachen soll, dann muss die SSL-Verbindung aufgebrochen werden. Das geht nur, wenn ihre Clients der RootCA des Schutzsystems vertrauen. Wenn dies nicht der Fall ist, dann sehen Sie entsprechende Warnungen
Anders als bei einem lokalen Proxy-System, wo sie ihre eigene PKI für diese Inspektion bei sich betreiben, wir hier der Verkehr außerhalb ihres Netzwerks aufgebrochen. Theoretisch könnte also hier Zscaler die Daten auch ausleiten. Das müssen Sie dann mir ihrer Datenschutzvereinbarung abstimmen. Speziell wenn hier auch B2B-Verbindunge mit besonders schützenswerten Daten übertragen werden. Die meisten Lösungen erlauben hier aber eine Allowlist für Domains, die nicht aufgebrochen werden. Das sollte zumindest für Finanzseiten der Fall sein. Der Anwender kann dies aber in der Regel weder sehen noch unterscheiden.
Angebot "WAN-Optimierung"
Wenn ich aber schon entsprechende "Netzwerk-Optimierer" in meinem Standorten haben, dann liegt die Idee doch gar nicht so fern eine "Optimierungsbox" bei der Cloud aufzustellen.
Der Weg von dem lokalen Endpunkt über das Internet und ein Stück im MGN kann dann von der Optimierungsleistung profitieren, so dass Durchsatz und Geschwindigkeit steigen. Das hängt natürlich stark von dem übertragenen Datenverkehr ab. Microsoft kann ja nicht davon ausgehen, dass es solche Optimierer bei jedem Kunden gibt und als "Besitzer" der Clients (Windows, Office) und des Backend (Exchange, Teams, SharePoint, OneDrive) kann Microsoft auf beiden Seiten ebenfalls die verwendeten Protokolle auf die neuen Anforderungen einer WAN-Verbindung optimieren.
Exchange und Outlook nutzen dazu OST-Dateien, OneDrive repliziert ebenfalls Dateien und auch Teams nutzt einen lokalen Cache. Dennoch gibt es sicher noch die ein oder andere Optimierungsmöglichkeit. Ob sich dies aber rechnet, kann ich noch nicht beantworten. Die Lösung kann natürlich im Rahmen eines "Managed Node" interessant sein, bei dem der Anbieter die Gegenstelle als Service betreibt und die lokalen Systeme einen Tunnel zur passenden Gegenstelle aufbauen.
- Riverbed: Lösungen für Azure
https://www.riverbed.com/de/solutions/microsoft-azure.html - Riverbed SteelHead 8.6 optimizes WANs
for Azure and hybrid clouds
https://www.zdnet.com/article/riverbed-steelhead-8-6-optimizes-wans-for-azure-and-hybrid-clouds/
Express Route oder optimierte Provider
Sie können natürlich auch einfach ExpressRoute einsetzen, um zumindest in Richtung Azure Public und Azure Private eine dedizierte Verbindung bereit zu stellen. Aber das ist eher was für den Hauptstandorte und weniger für viele Niederlassungen. Mittlerweile gibt es aber auch einige Carrier, die besondere Dienste für Azure anbieten. Das ist im Vergleich zu Express Router vielleicht eine interessante Option zur Anbindung von Firmen und Niederlassungen.
- Peering Service Preview partners
https://docs.microsoft.com/en-us/azure/peering-service/location-partners - DeCIX Azure Peering Services
https://www.de-cix.net/en/de-cix-service-world/closed-user-groups/microsoft-azure-peering-service - Colt
https://www.colt.net/why-colt/strategic-alliances/microsoft-partnership/ - InterCloud
https://intercloud.com/partners/microsoft-saas-applications/ - interxion
https://www.interxion.com/why-interxion/colocate-with-the-clouds/Microsoft-Azure/ - Equnix
https://blog.equinix.com/blog/tag/office-365/
https://www.equinix.com/services/interconnection-connectivity/cloud-exchange/ - QSC Multi Cloud Services
https://www.qsc.de/de/produkte-loesungen/cloud-services-und-it-outsourcing/multi-cloud/multi-cloud-services/ - Megaport
https://www.megaport.com/services/microsoft-expressroute/ - EUNetworks CloudConnect
http://www.eunetworks.com/cloudconnect/
Einschätzung
Ich bin noch etwas hin und her gerissen, welcher Weg für die Anwender optimal ist. Die viele Jahre vorherrschende Hub/Spoke-Topologie, bei der die Daten zu wenigen strategisch bereitgestellten Proxy-Servern und Firewall geleitet und dann über einen Filter ins Internet weitergegeben wurden, sind auf jeden Fall nicht für den Einsatz von Cloud-Diensten optimiert. Wer dann an jedem Standort eine Internet-Anbindung betreibt, muss sich natürlich Gedanken machen. Ein "Cloud-Proxy" kann hier eine gute Option sein, wenn der lokale Internetzugang dann jeglichen Verkehr daran vorbei unterbindet und damit günstig zu betreiben ist.
Wenn vor Ort aber schon ein SDWAN-Router steht, der auch applikationsabhängig den Verkehr zu den richtigen Zielen leiten kann, dann könnte ein lokaler Breakout auch hier einen gesicherten Weg zur Cloud öffnen und alle anderen "unsicheren" Daten weiter über vorhandene Proxy-Server und das eigene WAN leiten.
Gerade letzte Kombination geht aus meiner Sicht aber auch mit fast jeder einfachen Firewall, die sowieso am lokalen Breakout steht. Wenn diese nur die Office 365 Adressen routet und alles andere wieder zum zentralen Proxy geht oder eine proxy.pac diese Entscheidung schon auf dem Client regelt, dann kommen Sie auch ohne weiter Cloud-Dienste oder Optimierer in Azure aus.
Eine allgemeingültige Empfehlung kann es hier aber nicht geben.
Weitere Links
- OpenDNS - besser nicht
- Office 365 Network Performance Tool
- Ende zu Ende Monitoring
- End2End-UDP3478
- End2End-HTTP
- Implementieren eines geteilten VPN-Tunnels für Office 365
https://docs.microsoft.com/de-de/microsoft-365/enterprise/microsoft-365-vpn-implement-split-tunnel?view=o365-worldwide - Optimieren der Office 365-Konnektivität
für Remotebenutzer mithilfe eines geteilten
VPN-Tunnels
https://docs.microsoft.com/de-de/microsoft-365/enterprise/microsoft-365-vpn-split-tunnel?view=o365-worldwide - www.zscaler.com
- https://www.netskope.com/de/products/next-gen-swg