Cloud Portlimit - Firewall und Proxy

Office 365 und anderen Cloud-Anbieter sie so einfach zu nutzen; eine Verbindung zum Internet mit HTTPS oder zumindest 443/tls ist in den meisten Fällen ausreichend. Outlook nutzt MAPI/https oder RPC/http und die Exchange Web Services (EWS), Browser greifen auf Sharepoint eh per HTTPS zu und selbst die Kommunikation per Lync über den Edge-Server nutzt Port 443 mit TLS, so dass die meisten Firewalls dies passieren lassen. Aber ganz so einfach ist es nicht, wie ich auf dieser Seite beschreibe

IP-Adressen und Ports

Interessant wird die Fragestellen nämlich, wenn mehr und mehr Clients auf die Cloud zugreifen. Dabei ist diesmal aber nicht das Ziel interessant, sondern die Quelle. Sicher bietet ein "Webserver" z.B.: auf einem Port (80 bzw.443) seine Dienste an aber es können hundertausende Connections gleichzeitig zu so einem Server bestehen, wenn alle Clients mit einer unterschiedlichen IP-Adresse auf den Server zugreifen. Kein Problem für den Server die Verbindungen auseinander zu halten.

Auch wenn eine Software mehrere Connections zum gleichen Ziel öffnet, ist das erst mal kein Problem. Outlook und Browser bauen aber gerne mehrere Verbindungen auf, um parallel Daten effektiver zu übertragen und auch dem Server die Gelegenheit zu geben, parallel Anfragen zu verarbeiten. Gerade wenn z.B. größere Bilder oder Skripte übertragen werden, ist es von Vorteil wenn parallel auch noch andere Daten, z.B. Texte, Stylesheets etc. zum Client gesendet werden können.

Aber schon laufen auf den Server natürlich viel mehr Verbindungen auf, die dieser natürlich bedienen muss. Ein PC hat ja idealerweise 65535 "Ports", die er ausgehend verwenden kann. Zugegeben, einige sind schon belegt und die Clients nutzen eher "Hohe Ports" und die Windows Firewall beschränkt als Schutz gegen Missbrauch auch die Anzahl der gleichzeitigen ausgehenden Verbindungen, so dass ein PC auch mit ,mehreren Ports kein Problem darstellen sollte.

Parallele Verbindungen und Ports

Nehmen wir mal an, dass ein durchschnittlicher Anwender hier mit Outlook (ca. 10 Connections), einem Browser auf verschiedene Sharepoint-Sites (z.B. 8 Connections) und einem Lync Client arbeitet, der auch z.B. vier Connections benutzt. Dann hat so ein Client in "Richtung Office 365" schon 22 Connections auf. Das ist für ein Home-Office oder eine kleine Niederlassung noch kein Problem.

Wenn aber Firmen auf Office 365 umstellen, dann kann sich daraus schon ein Problem erwachsen. Schauen Sie sich das folgende Schaubild einmal an. Mehrere Clients am internen Netzwerk nutzen natürlich den gleichen zentralen Übergang, d.h. Proxy Server oder NAT-Router, hinter deren IP-Adressen sich dann alle Clients verstecken. Der Proxy-Server muss also für jede Client-Verbindung von innen eine Verbindung nach Außen aufbauen. Wenn das mal 1000 Clients an einem Standort sind, dann sind schon 22.000-Connections dieses Proxy-Servers "belegt".

Wenn er nur eine IP-Adresse hat, dann merken Sie schon, dass mit 3000 Clients im internen Netzwerk der Proxy schon komplett "belegt" ist. Hinzu kommt, dass eine freigegebene TCP-Session bis zu 2 Minuten noch gehalten wird.

Das Problem auf Seite des Clients betrifft also hier erst mal Firmen, die sehr viele Clients an einem Standort haben, oder nur sehr wenige Internet-Übergänge betreiben, d.h. den Internetzugriff von Niederlassungen über ihre eigenen MLPS/VPN-Verbindungen erst mal an einen Hauptstelle leiten und von dort ins Internet gehen. Dies ist gar nicht mal zu untypisch für Firmen, da man damit nur wenige Firewalls mit all den Schutzfunktionen bereitstellen muss und nicht eine Vielzahl von Internetausgängen überwachen und natürlich ebenfalls bezahlen und betreiben muss.

Hinweis: Überwachen Sie daher die Leistung ihres Proxy-Servers und insbesondere die belegten TCP-Sessions.

 

Mit Office 365 sind solche Firmen natürlich nicht die idealen Kandidaten für die Einführung. Oft haben solche Firmen historisch noch viele verteilte lokale Server. Die werden gespart aber die Netzwerkstruktur wird man in der Regel erweitern müssen. Wer dennoch keine lokalen Ausgänge zur Cloud zulässt, ist vielleicht besser mit einer "private Cloud" bedient, bei der die Server an wenigen zentralen Standorten platziert werden. Als Alternative könne ein lokaler Internetausgang ja auf die Ziel-Adressen von Office 365 beschränkt werden, um den Aufwand für Betrieb und Schutz zu reduzieren.

Ports pro Client?

Damit stellt sich natürlich auch die Frage, wie viele Ports denn so ein "durchschnittlicher" Client braucht. Sie können z.B. für Outlook und Exchange solche Informationen von ihren eigenen Clients ermitteln. Mit Netstat oder get-nettcpconnection erhalten Sie problemlos solche Daten. Auch ihre Firewall-Logs oder Proxy-Logs können Sie heranziehen. Ansonsten habe ich ein paar Eckwerte.

Client Beschreibung Anzahl

Outlook

Outlook nutzt separate TCP-Verbindungen um unterschiedliche Workloads abzudecken. So können Sie über eine Verbindung Mails senden, während eine andere Verbindung die Frei/Belegt-Zeiten abfragt und eine dritte Verbindung das Adressbuch durchsucht oder herunterlädt. Für die Replikation des Postfachs in eine OST-Datei gibt es eigene Verbindungen und den Zugriff auf weitere Postfächer und Stellvertreter kommen weitere Verbindungen hinzu. Es gibt hier also sicher einige "PowerUser" und einige Wenig-Nutzer.

15-25

Teams

Allein für die Betrieb von Teams ohne Audio/Video werden nach meinen Beobachtungen ca 5-10 Connections belegt. Da ist sicher der eigene Status, die Überwachung anderer Chats und Kanäle separiert. Audio/Video brauchen dann pro Verbindung einen weiteren Port. Idealerweise nutzen sie dazu UDP.

5-10

Browser

Immer mehr Webseiten sind nicht einfach nur "Ein HTTP-Abruf, Anzeigen und Ruhe". Aktive JavaScript im Hintergrund verraten, dass die Karteikarte immer noch offen ist oder tracken das Verhalten des Anwender mit. Das kostet TCP-Connections. Aber auch immer mehr "Browser Apps", nutzen JavaScript, um die Oberfläche zu steuern und kommunizieren zum Backend per RestAPI, JSON-Dateien etc. Ich habe schon Browser gesehen, die bei einem Zugriff per HTTP-Proxy auf das Internet pauschal 10-15 Connections "Warm hält", damit der Anwender gefühlt eine schnelle Reaktion hat.

15-25

SMB

Es gibt sie immer noch, die Dateiserver. Pro verwendeter Freigabe rechne ich im Ruhemodus mit einer TCP-Connection. Es können aber mehr werden und wenn ein Anwender einige Laufwerke nutzt, kommen auch hier ein paar Ports zusammen. Landen die Dateien auf SharePoint, kommt der OneDrive-Sync mit nicht weniger Port hinzu

5-10

Weitere

Das ist nur eine partielle Auflistung. Weitere Dienste wie Defender ATP, Intune etc. halten auch Verbindungen offen

??

 

Summe

??

Wenn Sie "sicher" gehen wollen, dann ermitteln Sie für ihre Umgebung die aktuellen Zahlen und nutzen ihre Pilot-Umgebung, um die zukünftige Verwendung besser abzuschätzen.

Denken Sie bei einem Proxy- oder NAT-Gateway auch hier an die Port-Limit. Gerne übersehen wird auch ein VPN-System mittels DirectAccess, wenn alle VPN-Client über NAT64 umgesetzt werden müssen.

IP-Adressen und Ports beim Cloud-Anbieter

Aber auch die Cloud-Anbieter kommen bei solchen Konstruktionen mit vielen Clients hinter wenigen IP-Adressen in Probleme. Bei erwartete Millionen von Kunden und der entsprechenden Anzahl von Verbindungen muss der Anbieter eine skalierbare Plattform bereitstellen. Er wird also natürlich versuchen, die Dienste über mehrere Server zu verteilen. Bei anonymen Verbindungen ist es natürlich von Vorteil, dass mehrere Server die gleichen Daten bereit stellen können und man daher mehrere IP-Adressen per DNS-Round-Robin auf mehrere Loadbalancer verteilen kann, die ihrerseits mehrere Server im Hintergrund ansprechen. So kann die Last verteilt also auch die Verfügbarkeit hoch gehalten werden.

Bei Verbindungen mit Anmeldung hingegen ist es nicht in allen Fällen möglich, dass ein Client mehrere Server ansprechen kann. Kommt hier z.B. NTLM oder Basic Authentication zum Einsatz, dann meldet sich der Anwender gegen einen Server an und auf dem sollte er und seine "Folgeverbindungen" auch bleiben. Ansonsten könnte es sein, dass der Anwender sich mehrfach anmelden muss und zudem die Authentifizierungsdienste des Anbieters den Anwender mehrfach auf mehreren Servern verifizieren müssten. Verschiedene Produkte versuchen das Problem zu umgehen, in dem nach der ersten Anmeldung die Informationen über die Anmeldung z.B. als Session-ID, Cookie o.ä. im Browser hinterlegt werden. Dennoch muss der Server im Backend die für diese Session erforderlichen Daten seinerseits irgendwo ja herholen. Jede Session kostet auf dem Backend also Speicher und Ressourcen und daher ist es auch hier der Regelfall, dass ein Anwender nach einer einmalig erfolgen Anmeldung auf immer dem gleichen Server bleibt.

Das bedeutet aber, dass die Plattform den Client erkennen muss. Der einfachste Weg ist hierbei die Client-IP. Dies ist protokollunabhängig und eine Lastverteilung muss nicht über die Tiefen der Protokolle gehen. eine Layer-7 Verteilung eines HTTP-Streams bedeutet nämlich, dass der Loadbalancer den SSL-Tunnel aufbrechen und z.B. Anhand von Cookies, Anmeldedaten oder anderen Informationen im Header die Verbindungen weiter reichen muss. Das ist ziemlich Ressourcenintensiv und sollte nur in Verbindung mit SSL-Offloading in größerem Stiel genutzt werden. Nicht umsonst hat Microsoft mit Exchange 2013 die CAS-Rolle quasi zum intelligenten "Reverse Proxy" umgestaltet und fordert für die Loadbalancer davor nur noch "Layer-4 Unterstützung". Dennoch geben Anbieter hier durchaus Grenzen vor:

..maximum of approximately 2,000 Exchange clients per IP address  …
.. If you want to support more than 2,000 devices behind a single public IP address, follow the steps outlined to assess the maximum number of devices that can be supported: ..
http://technet.microsoft.com/en-us/library/hh852542.aspx

Aber das sind dann eher die Ausgaben, die ein Anbieter von Cloud-Diensten irgendwie unter Zuhilfenahme von DNS-RR, Loadbalancern und den passenden Protokollen zu lösen hat.

IP-Adressen und Ports beim Kunden

Wenn Sie nun davon ausgehen, dass die Cloud-Anbieter einen Client anhand der Source-IP identifizieren, dann bedeutet das im umkehrschluss aber auch, dass Sie als Kunde einen Client nun immer mit der gleichen IP-Adressen "raus" lassen müssen. Wenn Sie ihrerseits aber nun einen Proxy haben und mit dem 65535-Port-Problem hantieren, dann könnten Sie versucht sein einfach mehrere IP-Adresse für ausgehenden Verkehr zu verwenden. Das kann dann wieder zu Problemen führen, wenn nun der gleiche Client so viele Verbindungen aufbaut, dass der Proxy diese über unterschiedliche Adressen nach extern weiter reicht.

Für der Cloud-Anbieter sind dies nun aber zwei unterschiedliche Clients die vermutlich nun nicht mehr auf den gleichen Backend-Server landen. Mehrmalige Anmeldungen oder sonstige Anwendungsprobleme könnten dann die Folge sein. für ihren eigenen Betrieb ist es also wichtig, dass Sie ausgehend einem Client weiterhin die gleiche IP-Adresse zuordnen.

Weitere Links