Cloud NAT/Proxy

Auf dem Weg zwischen Client und Office 365/Cloud-Anbieter lauten NAT-Router, HTTP-Proxies, Firewalls und Loadbalancer auf ihren Datenverkehr und können ganz schön stören.

NAT, 65535 Ports, Proxy und Loadbalancing

Die Wahl des Weges hat Einfluss auf die Netzwerke, was nicht immer sofort jedem in den Kopf kommt. So ein Outlook macht doch einige Verbindungen zu den Exchange Servern auf.

Wenn Sie nun mehrere Clients haben, die alle den gleichen Weg gehen, dann gibt es neben der Bandbreitenfrage noch einige andere Komponenten, die zu beachten sind.

  • TCP-Firewall Sessions
    Wenn der Traffic aus ihrem internen LAN zum Internet geht, dann kommen nun sehr viel mehr permanente Verbindungen ihrer internen Clients auf Systeme im Internet zu. Das betrifft die Anzahl der bestehenden TCP-Sessions ebenso sie die Datenmenge, auf die ihre Firewall eingerichtet sein muss.
  • Proxysessions und Authentifizierung
    Wenn HTTPS als Protokoll zum Einsatz kommt und die internen Clients über einen HTTP-Proxy gehen, ist auch hier eine deutliche Zunahme der Last zu erwarten. Das kann das Logging, Caching aber auch die Authentifizierung sein. Oder sie geben die IP-Adressen des Cloud-Providers "anonym" frei. Das spart die Authentifizierung für diese Ziele, erfordert aber eventuell eine "Nachpflege", wenn der Cloud-Anbieter weitere Adressen nutzt.
  • NAT-Ports
    Auf der Seite 65535 Port-Limit habe ich schon beschrieben, dass ein System ausgehend normalerweise maximal 65535 Ports pro Source-IP nutzen kann. Wenn nun jeder Anwender 10 TCP-Sessions für Outlook nutzt (siehe Bild), dann ist ab ca. 6500 Benutzern der Pool erschöpft. Und es gibt ja sonst noch Traffic, der über den Proxy oder den NAT-Router läuft. Eventuell sollte ihre Firewall dann mehrere Source-IP-Adressen nutzen oder mehrere Systeme parallel arbeiten
  • Loadbalancer
    Aber auch für den Cloud-Anbieter ist es wünschenswert die Clients unterscheiden zu können. Setzt der Anbieter z.B. einen Loadbalancer zur Lastverteilung ein, dann muss dieses System den gleichen Client immer zum gleichen Backend-Server leiten. Affinity/Stickness/Persistence sind die Zauberworte und meist wird die Source-IP dazu genutzt. Wenn nun alle Clients über eine IP-Adresse kommen, kann der Loadbalancer diese tausende Clients nicht auf mehrere Backendserver verteilen. Anfangs forderte Microsoft z.B., dass nicht mehr als 2000 Clients sich hinter eine IP-Adresse verbergen sollten. Das wurde mittlerweile relativiert.:

Maximum supported devices behind a single public IP address = (64,000 – restricted ports)/(Peak port consumption + peak factor)
For instance, if 4,000 ports were restricted für use by Windows and 6 ports were needed per device with a peak factor of 4:
Maximum supported devices behind a single public IP address = (64,000 – 4,000)/(6 + 4)= 6,000
Quelle: Network Address Translation (NAT) support with Office 365
http://msdn.microsoft.com/en-us/library/dn850366.aspx

Note that with the release of Office 365 hosting pack, included in the Updates from September 2011 für Microsoft Office Outlook 2007, or November 2011 für Microsoft Outlook 2010, or a later Update, the number of connections from Outlook (both Office Outlook 2007 with Service Pack 2 and Outlook 2010) to Exchange can be as few as 2.
Quelle: Plan für Internet bandwidth usage für Office 365 http://technet.microsoft.com/en-us/library/hh852542.aspx

Hinweis: Auch Router können nur so viele NAT-Assoziationen sich merken, wie Speicher dafür vorgesehen ist. Meine AVM Fritz!Box 7390 scheint irgendwie zwischen 6000-7000 NAT-Verbindungen verwalten zu können. 

Jetzt wird auch klar, warum Exchange 2013 CAS-Server nicht mehr auf einen Loadbalancer mit Affinität aufbauen, sondern es egal ist, an welchen CAS der Clients geht, denn die Clientverbindung bedient eh der Exchange Server mit der aktiven Datenbank für die jeweilige Mailbox.

Auch hier sehen sie, dass die Anbindung eines unternehmens an die Cloud etwas aufwändiger sein kann und es nicht nur mit einem "Internetzugang reicht" getan ist.

TCP Keepalive

Ein weiterer Punkt, der direkt mit NAT und Proxies zusammen hängt ist die Behandlung der TCP-Sessions. Normalerweise öffnen Programme eine TCP-Verbindung zu einem Server um ganz schnell die Daten zu übertragen. Wenn Sie nicht mehr benötigt wird, wird die Verbindung abgebaut. Damit kann auch ein NAT-Router oder ein HTTP-Proxy seine Tabellen aufräumen und die Ports anderweitig nutzen.

Das Problem der Keep-Alive ist erstmalig bei Mobilgeräten offensichtlich geworden, die per ActiveSync Daten übertragen haben und dazu eine Verbindung zum Ziel aufgebaut und gehalten haben. Damit konnte der Service auch ein Rückpaket an den Client senden, zumindest solange der Client noch verbunden war. Wenn das Smartphone einen Zellenwechsel "erlebt" baut es natürlich die Verbindung erneut auf aber kann natürlich nicht mehr die alte Verbindung "abbauen". Der Server hält also die ruhende Verbindung noch offen bis ein Timeout auftritt. Dieses Verhalten ist definiert:

4.2.3.6 TCP Keep-Alives
TCP Keep-Alives Keep-alive packets MUST only be sent when no data or acknowledgement packets have been received für the connection within an interval.  This interval MUST be configurable and MUST default to no less than two hours.

Quelle: RFC1122 - Requirements für Internet Hosts https://tools.ietf.org/html/rfc1122 

Nun sind 2 Stunden relativ lange für ein System, welche sehr viele Verbindungen bedienen muss. Ein Webserver hat damit erst mal kein Problem, da dieser dabei ja das Ziel ist und über den einen Port 80/TCP oder 443/HTTPS natürlich auch mehr als 65535 Verbindungen laufen können. Anders sieht es aber aus, wenn ein Proxy, NAT-Router oder Loadbalancer dazwischen geschaltet ist und quasi als "Client" die Verbindung initiiert. Wenn hier der versteckte Client die Verbindung nicht mehr abbaut, dann kann der NAT-Router diese nur dadurch lösen, dass er die logische Verbindung, die einen ausgehenden Port belegt, irgendwann einfach löscht. In der Regel "sagt" der NAT-Router dabei aber weder dem Ziel noch dem Absender bescheid. Die könnten ja schon lange "offline" sein, da sie keine Keep-Alive-Pakete mehr senden. Zumindest wenn sich alle an die 2h halten.

Nun kann aber gerade ein beschäftigter NAT-Router, HTTP-Proxy oder Loadbalancer nicht bei jeder Verbindung bis zu 2 Stunden abwarten. Daher haben die meisten Systeme einen deutlich geringeren Timeout, d.h. sie löschen die Assoziation aus ihrer Sessiontable einfach früher raus. Die Zeiten sind hier schon teilweise extrem kurz. Ich versuche mal hier eine Tabelle zu pflegen.

System  Timeouts Maximal Sessions

AVM Fritz!Box
http://avm.de/nc/service/Fritz!Box/Fritz!Box-7270/wissensdatenbank/publication/show/
907_Anwendung-z-B-SSH-verliert-gelegentlich-die-Verbindung-zu-Gegenstellen-im-Internet/

UDP: 300 Sek
TCP: 900 Sek

ca. 7000 

Squid:
http://www.squid-cache.org/Doc/config/client_idle_pconn_timeout/
HTTP-Proxies: teilweise 100-600 Sekunden  

HTTP: 120 Sek

 

NetScaler 

HTTPS: 300 Sek

 

Kemp Loadbalancer 

Session: 660 Sek

 

Ich würde mich freuen, wenn Sie mir bei der Erweiterung der Tabelle helfen.

Das ist für den normalen "Surf-Traffic", Downloads und Streaming unkritisch. Und auch ein IMAP4/POP3-Client, der eh alle 5 Minuten die Verbindung aufbaut und wieder abbaut, stört dies nicht. Anders sieht es aber für "Long running Connections" aus, wie diese ActiveSync, Outlook, IMAP4-Idle-Clients, SSH-Clients und andere Dienste nutzen. Wenn diese eine vom NAT-Router schon gelöschte Verbindung wieder weiter verwenden wollen, dann gelingt das nicht.

Hoffentlich sagt hier nun der Router dem Client mit einem TCP-RESET, dass die Verbindung zurück gesetzt wurde. Oftmals unterbleibt das aber und der einfache NAT-Router sagt einfach gar nichts. Damit muss der Client gemäß den TCP-Spielregeln das Paket erneut senden bis der TCP-Retry-Counter abgelaufen ist. Und genau das kann man dann beim Client durch eine "Stockende Funktion" merken, d.h. Outlook hängt, neue Mails kommen nicht mehr an, Mails werden nicht gesendet etc.

Weitere Links