VPN-Tunnel aus dem Homeoffice – mit MTU-Tuning?

aus dem Netzwerk Insider Juni 2020

Die Homeoffice-Welle zum Social Distancing wegen Corona führt es vor:

Bei scheinbar erfolgreich etablierten Lösungen können Probleme zutage treten, wenn der Nutzungsumfang rapide ansteigt. Ein Grund kann eine erhöhte und stärker schwankende Netzbelastung sein.

Woran liegt es aber, und was kann man tun? Sind per Suchmaschine gefundene oder aus der eigenen Erinnerung bekannte Kniffe zum Tuning an Konfigurationen noch up to date?

Am Beispiel der Aspekte IP-Fragmentierung und MTU-Size-Deckelung am mobilen Endgerät zeigen wir, wie man überlegt mit dem aktuellen Stand von Technik und Produkten umgeht. Das Abweichen von Standardeinstellungen verlangt Wissen und Fingerspitzengefühl. Es müssen oft Kompromisse gefunden werden, die in verschiedenen Einsatzszenarien für dasselbe Gerät funktionieren.

Homeoffice-Anbindung kann in Stoßzeiten bislang nicht erlebte Probleme machen

Aus der Praxis eines IT-Betriebsbereichs: Homeoffice als Option bzw. feste Heimarbeitsplätze sind schon etabliert und werden auch von einer überschaubaren Zahl von Personen problemlos genutzt. Mit zunehmender Nutzung werden aber Fälle gemeldet, in denen es Probleme gibt. Zu bestimmten Zeiten, etwa morgens zu Arbeitsbeginn, ist der Aufbau der zur Absicherung vorgeschriebenen VPN-Verbindung problematisch. Phasenweise lassen sich tagsüber bestimmte Vorgänge nur zäh durchführen. Zum Beispiel sind manche Internet-Seiten über die VPN-Verbindung aufzurufen, wohingegen andere nicht immer geladen werden.

Wo bei einzelnen Homeoffice-Neulingen und VPN-Erstnutzern solche Effekte auftreten, mag man noch von Ausnahmen ausgehen. Nun aber klagen plötzlich viele oder auch Betroffene, die bislang von zuhause die etablierte Lösung ohne spürbare Probleme nutzten. Der erste Verdacht in Richtung einer überlasteten VPN-Gateway-Lösung lässt sich als eindeutige Ursache nicht erhärten: Die zentrale Lösung ist zwar gemäß Monitoring zeitweise stärker beschäftigt als gewohnt, fährt aber keine auffällige Überlast.

Interessant: Betroffene Personen erläutern, dass sie z.B. Seiten im Internet, die via VPN-Tunnel problematisch sind, an ihrem privaten Rechner testweise parallel erfolgreich abrufen konnten, etwas langsam vielleicht, aber es hat funktioniert.

Ein zeitweise auftretendes Problem, das in Verbindung mit getunnelter Übertragung eher auftritt als ohne – das klingt nach einem Antwortzeit- oder Laufzeitproblem. Wo kann man erfolgreich den Zeitverlust reduzieren, den man als Grund vermutet?

Ansatzpunkte aus vergangenen Zeiten der schwachen Vernetzung bei privaten Haushalten oder bei mobilem Geräteeinsatz kommen wieder auf die Kandidatenliste. Einer davon ist die Vermeidung von Fragmentierung über manuelle MTU-Beschränkung. Allerdings: Man muss verstehen, was manuelle Änderungen auslösen können. „Viel hilft viel“ als Ansatz richtet bei Eingriffen in bewährte Standard-Voreinstellungen durch Seiteneffekte eher Schaden an. Außerdem sind mittlerweile neue optimierende Automatismen hinzugekommen. Hat ein manuelles Eingreifen noch Sinn, oder liegt der Lösungsweg in einer Feineinstellung zu solchen Mechanismen? Hier ist Wissen in Kombination mit strukturiertem Vorgehen und Abwägen gefragt.

Fragmentierung und MTU – Was war das noch und wieso ist das wichtig?

Die Maximum Transmission Unit (MTU) steht für die maximale Anzahl an Oktetten (Blöcken von 8 Bits), die als Inhalt, und damit Nutzlast eines Pakets, über ein Medium und das zugehörige Netzwerkprotokoll des Layer 2 übertragen werden können. Hinzu kommen noch als „Header“ dieser Nutzinformation vorangestellte Informationen. Diese steuern den Transport über das genutzte Medium und geben an, was als Inhalt (Payload) transportiert wird, z.B. ein IP-Datagram. Die von einem gewählten Medium und Protokoll, z.B. LAN-Kabel und Ethernet oder Drahtlosübertragung und WLAN-Protokoll unterstützte MTU-Größe findet man als Parameter auch unter der Bezeichnung MTU-Size.

Ein solcher über ein Medium zu transportierender Inhalt setzt sich wieder aus einem Header und zu transportierendem Inhalt zusammen, usw. – eine auch als Encapsulation bezeichnete Schachtelung. Die Header der Schichten 2 und 3, z.B. Ethernet- und IP-Header, werden durch Netzkomponenten gelesen, damit die Sendung den Weg zum Empfänger findet. Mindestens der IP-Header, meist auch gleich der TCP- oder UDP-Header der in einem IP-Datagramm eingebetteten Nachricht werden von einfachsten Paketfilter-Firewalls gelesen und gegen Firewall-Regeln geprüft, die über erlaubte Weiterleitung oder Blockieren entscheiden.

Mehrfache Schachtelung und damit verbundene Header sind dabei wichtige Faktoren für die Bedeutung von MTU-Size und Übertragungsgeschwindigkeit unter nicht idealen Bedingungen:

Wer z.B. „schnelles Internet“ haben möchte, bestellt zwar zunächst eine Zusage, dass er eine große Menge von Bits pro Sekunde an der Schnittstelle zum Netz senden und empfangen kann (Bitrate als Leistungsparameter).
Für das rechtzeitige Ankommen von Nutzdaten bei einem Empfänger, dessen Anwendungen diese verarbeiten und ein Ergebnis anzeigen sollen, ist aber auch die Übertragungsdauer vom ersten bis zum letzten Bit der Sendung entscheidend.

Für jedes zu übertragende Paket ist eine gewisse Anzahl Header nötig, und diese werden auf dem Weg vom Sender zum Empfänger und auch beim Empfänger selbst gelesen und interpretiert. Interpretieren heißt „rechnen“ im Sinne eines vom Protokoll vorgegebenen Algorithmus, das kostet Rechenzeit (CPU-Belastung). Diese Rechenzeit kommt zur reinen, durch die Länge des zurückgelegten Wegs entstehenden Übertragungsdauer hinzu und verlängert die Transportdauer.

Hier kann die MTU-Size entscheidend ins Spiel kommen:

Hohe MTU-Size als Performance-Faktor
Nimmt man eine bestimmte Datenmenge, etwa eine einzelne Datei oder die Daten, die eine Webseite beschreiben, müssen diese Anwendungsdaten auf eine Folge von Paketen aufgeteilt versendet werden. Die Größe und Anzahl der Header pro Paket ist „gesetzt“, also: Eine kleine MTU-Size bedeutet eine Aufteilung der Anwendungsdaten auf viel mehr kleine Pakete. Jedes Paket verursacht eigene Verarbeitungszeitanteile und erhöht so die Gesamtzeit, bis das letzte Bit der zu übertragenen Anwendungsdaten beim Empfänger angekommen und dort von der Anwendungssoftware verarbeitet ist.

Will man also eine angebotene Bitrate optimal nutzen, muss man eine möglichst große MTU-Size zur Verfügung haben und damit den Overhead durch Header-Verarbeitungszeiten so gering wie möglich halten.

Aktuelle Netzkomponenten und aktuelle Kommunikationspartner sind auf einen hohen Bit-Durchsatz ausgelegt. Sie haben genug Speicher, um große Pakete zu puffern, bis ihre Inhalte weitergesendet bzw. an die Empfängeranwendung und deren Speicherbereich übergeben wurden.
Aber Vorsicht: Diese Aussage zur Pufferkapazität gilt, insbesondere auf Endgeräten, nur unter der Bedingung eines gleichmäßigen Durchlaufs von eintreffenden Paketen mit zügiger Übergabe ihrer Inhalte an die Anwendungsebene.

In Verbindung mit besonders hohen Bitraten wird zuweilen mit sehr großen MTU-Size-Optionen operiert (siehe z.B. Ethernet mit Jumbo Frames), um die beschriebenen Effekte großer Pakete weiter auszuschöpfen.
Fragmentierung als Behelfslösung bei wechselnder unterstützter MTU-Size
Wechselt entlang des Übertragungswegs das Medium bzw. das bei Encapsulation verwendete Protokoll, so kann es sein, dass auch die MTU-Size sich ändert. Jetzt wird es problematisch: Ist der für Payload verbleibende Platz auf einem Teil des Weges kleiner als beim Sender, so passt eine große Nachricht nicht mehr in einem Stück „auf das Medium“.

Hier kommt die schon im uralten Standard der IP-Version 4 (IPv4, beginnend mit RFC 791 von 1981) vorgesehene Fragmentierung ins Spiel. Ein „IP-Router“ erhält ein Paket aus Richtung eines Senders, der mit größerer MTU-Size arbeiten konnte, als dies beim Weitersenden durch den Router im nächsten Schritt möglich ist. Der IPv4-Router kann nun rettend eingreifen:

Er zerlegt den Nutzdatenteil des IP-Datagrams in mehrere Teile („Fragmente“) und erzeugt neue IP-Header, mit deren Hilfe alle Teile den Weg zum Empfänger finden und dieser das ursprüngliche IP-Paket rekonstruieren kann. Die Erreichbarkeit des Empfängers wird trotz der Panne mit der zu großen Sende-MTU ermöglicht. Das funktioniert theoretisch auch, wenn sich in Netzen mit parallelen, lastverteilt genutzten Wegen Fragmente auf dem Weg zum Empfänger überholen, also in geänderter Reihenfolge am Ziel eintreffen.

Fragmentierung: Nachteile

Was ist aber dann das Problem, wieso muss man Fragmentierung negativ als „Behelfslösung“ einordnen? Die für den optimalen Fall, nämlich einer einheitlichen MTU-Unterstützung Ende-zu-Ende, aufgestellte Rechnung zur optimierten Übertragung geht nicht mehr auf!
Das kann man verstehen, ohne sich die Details anzuschauen. Der fragmentierende Router muss jedes betroffene Paket zerteilen und mit neuen Headern versehen. Das kostet Verarbeitungszeit und verlängert die Zeit der Puffer-Belastung durch das einzelne Paket im Router.

Jedes Fragment bekommt zudem einen eigenen Satz Header-Informationen und muss daher auf dem weiteren Weg einzeln verarbeitet werden, mit entsprechender Verschlechterung der Overhead-Bilanz für die Gesamtübertragungsdauer der Datei, der Webseite etc. Bei geringer bis durchschnittlicher Belastung wird man den Unterschied kaum merken, aber was ist in Phasen, wenn „im Netz“ viel los ist und der Fragmentierungsfall mit vielen anderen Datenströmen zusammentrifft?

An einer Firewall kann es noch ungünstiger werden: Je nachdem, was diese im Detail prüft, muss sie zunächst für sich die Fragmentierung „aufheben“ und den ursprünglichen Zustand des Original-Pakets mit ihrem Regelwerk vergleichen. Dann erst kann es für die Fragmente zum Empfänger weitergehen. Die ebenfalls nicht wünschenswerte Alternative: Eine einfache Firewall entdeckt einen Widerspruch zu ihren Regeln wegen der in Fragmente zerlegten IP-Nutzlast nicht und „winkt durch“.

Auch aus Sicht des Empfängers ist es ungünstig, wenn er Fragmente erhält. Für jedes ursprünglich gesendete IP-Paket muss er die Fragmente sammeln, nötigenfalls in die richtige Reihenfolge bringen und die Lückenlosigkeit feststellen. Dann erst kann er die Anwendungsdaten weitergeben und die Fragmente aus seinem Puffer löschen. Ist insbesondere ein Endgerät für so etwas ausgelegt, in Zeiten, wo alles auf schnelle Netze und schnelles Durchreichen des Dateneingangs ausgerichtet wird?

Fragmentierung hat entsprechend klare Nachteile:

Spürbare Verlängerung der Übertragungsdauer für Anwendungsdaten
Der Overhead durch kleinere Pakete, als sie beim Sender und oft auch im Empfängernetz möglich sind, wird vergrößert durch die zusätzliche Puffer- und Verarbeitungszeit beim fragmentierenden Router und beim Empfänger.
Bremsende Seiteneffekte auch für andere Datenströme
Ab dem fragmentierenden IP-Router werden die durchlaufenen Netzkomponenten unnötig länger mit dem jetzt fragmentierten Datenstrom beschäftigt. Während dieser zusätzlichen Verarbeitungszeiten bleiben Pakete anderer Datenströme liegen, werden also ebenfalls verzögert abgearbeitet.
Längere Pufferdauern können zu Überlauf und Packet Drops führen
Geradezu fatal kann sich das beim Empfänger des fragmentierten Datenstroms auswirken. Wird dieser mit seinen Zusatzaufgaben zur Defragmentierung so aufgehalten, dass ihm der Paketpuffer vollläuft, kann er neue Fragmente zeitweise nicht mehr annehmen.
Bei TCP-basierten Datenströmen führt dies „nur“ zum erneuten Versand schon einmal gesendeter Segmente (wieder mit Fragmentierungseffekt!). Das „nur“ stimmt bei genauem Hinsehen nicht, so harmlos sind derartige Wiederholungsfälle (Timeout & Retransmission) nicht. Schon bei kurzzeitiger Häufung können sie die gesamte TCP-Übertragung nachhaltig verlangsamen.
Bei UDP-basierten Datenströmen kann ein entscheidendes Paket verloren gehen.
Jetzt kommen Timer und Heilungsintelligenz bzw. Empfindlichkeit der Anwendungssoftware ins Spiel, und es erklären sich die zum Teil sehr unterschiedlichen Erfahrungen betroffener Anwender. Manche Anwendungen brechen einen Vorgang komplett ab, bei anderen wird nur nicht alles, was man gewohnt ist, als Ergebnis angezeigt. In wieder anderen Fällen muss man eingreifen, den laufenden Vorgang abbrechen und es erneut versuchen.
Da solche Effekte vom momentanen Zustand beim Empfänger abhängen, bekommt man kein eindeutiges Fehlerbild, sondern schwer zu deutende sporadische und wechselnde Problemmeldungen.
Fragmentierung kann beim Empfänger zu nachhaltigen Störeffekten führen
Immer wieder unvollständig bleibende Fragmente können sich im IP-Puffer sammeln. Phasenweise ist dieser mit solchen Bruchstücken von Übermittlungsversuchen randvoll. Datenströme paralleler, eigentlich unproblematischer Verbindungen können dadurch auch zum Erliegen kommen, nicht nur die fragmentierte Kommunikation.
Fragmentierung: Grenzen einer automatischen Vermeidung
In der Vergangenheit waren wechselnde MTU-Größen mit schrittweiser und deutlicher Verkleinerung auf dem Weg zu einem Ziel keine Seltenheit, zum Beispiel:
1. Ethernet mit MTU 1500, dann PPPoE für Nutzung eines DSL-Anschlusses, mit MTU <= 1492 , am Senderstandort, gefolgt von Extremfällen wie 2. auf einem zu durchlaufenden Teilstück der Strecke zum Empfängerstandort (etwa als fallweise aktivierte Backup-Strecke) gibt es eine ISDN-Verbindung mit MTU 576.

Aus solchen Zeiten stammen erste Versuche, etwas Intelligenteres zu tun, als bei Kommunikationsproblemen über unbekannte Kommunikationswege einfach die MTU von 576 zu benutzen, die mindestens jede IPv4-Implementierung unterstützen muss.

Für die heute bei Nutzanwendungen üblichen Datenmengen funktioniert eine solch kleine MTU praktisch gar nicht mehr, ohne dass Probleme auftreten. Für IPv6 setzt der RFC 8200 durchgängig eine minimale MTU von 1280 Bytes voraus. IPv6-Router greifen im Bedarfsfall gemäß Standard nicht fragmentierend ein. Es wird vielmehr erwartet, dass etwa der Sender (oder ein Applikationsgateway) die Notwendigkeit der Fragmentierung erkennt und größere Dateneinheiten auf Anwendungsebene in IPv6-Pakete mit optionalen Fragmentierungsheadern aufteilt.

Die zu realisierende „Tuning-Aufgabe“ heißt: Sofern auf dem aktuellen Weg zu einem Empfänger ein Übergang durchlaufen wird, bei dem fragmentiert werden muss, wird nicht fragmentiert, sondern durch den Sender reagiert. Dieser passt die Größe von Paketen an, die für größere Datenmengen bei dieser Kommunikationsverbindung gesendet werden. Ziel: Die verwendete MTU ist für optimale Performance so groß wie möglich, aber so reduziert, dass keine Fragmentierung mehr anfällt.

Die Aufgabenstellung besteht also darin, eine Lösungsmethode mit zwei aufeinander aufbauenden Elementen zu finden, die beide funktionieren müssen:

Fragmentierung wird grundsätzlich verhindert, zu fragmentierende Pakete werden nicht weitergeleitet
der Sender eines vom MTU-Problem betroffenen Datenstroms erkennt dies und reagiert.

Der erste Lösungsansatz in dieser Richtung, Path MTU Discovery, benutzt hierzu einen „Trick“: Es wird im IP-Header ein Flag gesetzt, das den IPv4-Routern Fragmentierung verbietet (don’t fragment). (siehe Abbildung 1)

Abbildung 1: IP-Header-Ausschnitt mit gesetztem „don’t fragment“-Flag

Punkt 1 ist damit sofort umgesetzt. Für Punkt 2 wird bei Path MTU Discovery darauf gesetzt, dass ein Router entsprechende Pakete nicht stillschweigend verwirft, sondern eine ICMP-Meldung an den Sender zurückschickt.

Eine solche „fragmentation needed, but don’t fragement set“-Meldung enthält dann optimal gleich die Angabe einer glatt durchgehenden „effective MTU for sending“, und diese kann ab jetzt für den betroffenen Datenstrom angenommen werden. Für IPv4 ist mit RFC 1191 diese Zusatzinformation der effective MTU eigens eingeführt worden.

Das Pendant der Path MTU Discovery für IPv6 (RFC 8201, ursprünglich: RFC 1981) kann hier direkt auf der in RFC 4443 erfolgten Definition einer „Packet Too Big“-Meldung aufsetzen. Diese Definition sieht eine MTU-Information zum „next-hop link“ ebenfalls vor.

Leider ist damit das Problem in der Praxis nicht gelöst. Was die Erfinder des Ansatzes bei der Spezifikation nicht geahnt haben, ist die mittlerweile hohe Brisanz der Sicherheitsproblematik (RFC 1191 stammt aus 1991!). Etliche Sicherheitsangriffe setzen präparierte ICMP-Meldungen als Teil der Angriffsmethode ein, um Informationen für den weiteren Angriff zu erhalten oder einfach nur, um Schaden anzurichten. Schickt man etwa einem Sender auf jeden seiner Sendeversuche gefälschte „Packet Too Big“-Nachrichten, so wird er schließlich den Sendevorgang einstellen. Unter eine definierte minimale Paketgröße darf er ja nicht gehen.

Die Konsequenz in der aktuellen Praxis ist bekannt: An Sicherheitsübergängen wie Firewalls werden ICMP-Nachrichten oft rigoros blockiert. Für den Path-MTU-Discovery-Versuch bedeutet dies: Die wichtige Korrekturinformation kommt nicht beim Sender der zu großen Pakete an, eine heilende Fragmentierung hat er wiederum verboten – nichts kommt bis zum Empfänger durch!

Nachdem dies erkannt war, sind verschiedene Ansätze entstanden, diese Problematik zu umgehen. Wichtige, in der Praxis vorkommende Beispiele sind:

Test ohne Don’t-Fragment-Bit
Eine Zusatzintelligenz des Senders reagiert auf offenbar misslungene Sendeversuche mit einer „Fragmentierung nötig“-Annahme und versucht es ohne das Fragmentierungsverbot mit reduzierter Paketgröße. Bei Quittung durch den Empfänger richtet der Sender die Größe der nachfolgenden Pakete dieser Verbindung nach diesem erfolgreichen Versuch aus.
Ansätze gemäß dieser Idee gibt es verschiedene, z.B. die von Microsoft entwickelte „Black Hole Detection“ oder die allgemeinere Spezifikation einer Erweiterung von Path MTU Discovery zu einer „Packetization Layer Path MTU Discovery“ (RFC 4821).
Eine wirklich optimale Path MTU kann hier allerdings nur gefunden werden, wenn der Fragmentierungsverdacht als Ursache für Paketverluste zutrifft und die einzige Ursache für solche Verluste darstellt. Trifft etwa der Sondierungsversuch ohne Don’t-Fragment-Bits mit einem vorübergehenden Engpass auf der Strecke oder beim Empfänger zusammen, wird womöglich eine unnötig kleine MTU als geeignet ermittelt. Das gleiche kann bei Übertragungswegen passieren, die zeitweilig eine erhöhte Bitfehlerrate und deswegen verworfene Pakete aufweisen. Ist alles wieder im Normalzustand, wird mit unnötig kleiner Paketgröße gesendet, was die Übertragung größerer Datenmengen deutlich ausbremst.
Außerdem ist zu beachten: Ein solcher Ansatz mit ausprobierender Wiederholung des Sendens eines Pakets benötigt einen Mechanismus, der Paketverluste zwischen Sender und Empfänger erkennt und auf diese mit erneuter Sendung reagiert. Bei TCP ist dies gegeben, eine solche MTU-Optimierungsidee kann also für alle TCP-basierenden Übertragungen einheitlich über die TCP/IP-Software realisiert werden. Bei UDP ist dies nicht der Fall, hier müssen Erkennung und Korrektur in die einzelne Software auf Anwendungsebene eingebaut werden, die UDP-basiert übertragen lässt.
Übertragung einer Optimierungsinformation alternativ zu Path MTU Discovery/ICMP
Ein Beispiel ist das z.B. in RFC 4459 erwähnte „MSS Clamping“.
Die Maximum Segment Size (MSS) ist auf TCP-Ebene die Entsprechung zur MTU. Sie legt fest, wieviel TCP-Payload maximal hinter einem TCP-Header (als Daten-Segment der TCP-Nachricht) folgen soll.
Wird irgendwo ein Übertragungstunnel realisiert, also Encapsulation mit neuen Tunnel-Headern vorgenommen, so kann ein Tunnelendpunkt optional MSS-Clamping unterstützen. Soll er Pakete einer neuen TCP-Verbindung weitergeben (TCP-SYN-ACK-Handshake), so ergänzt er eine MSS-Information. Diese berücksichtigt den Header-Bedarf für den Tunnel. Interpretiert ein Endpunkt dieser TCP-Verbindung die optionale MSS-Information im TCP-Header korrekt und sendet nur Pakete, die diese MSS-Angabe als Obergrenze nehmen, wird durch den Tunnel kein Fragmentierungsgrund entstehen.
Dies ist streng genommen eine Art „Hack“, da sich der Tunnelendpunkt in den Handshake der eigentlichen TCP-Kommunikationspartner einmischt. Dieser z.B. bei DSL-Routern wegen eines ausgehenden PPPoE-Tunnels oft unterstützte Trick setzt allerdings voraus, dass TCP-Verbindungen genutzt werden, sowie dass alle Beteiligten den optionalen Header-Teil für MSS nutzen und korrekt interpretieren. (siehe Abbilung 2)
bei Tunnelende auf dem Sender: optimierende, einprogrammierte Annahme
Wird auf einem System eine Software eingesetzt, die einen Kommunikationstunnel aufbaut, durch den Anwendungsdaten übertragen werden, so kann die Tunnelsoftware gezielt einen „MTU-Abschlag“ einbringen. Aufgrund der Größe des Tunnelheaders sowie Erfahrungswerten für typische Einsatzszenarien wird die Größe der in getunnelten Paketen übertragenen Payload so reduziert, dass diese Encapsulation kein Grund für Fragmentierungsbedarf sein sollte.
Ein in der Praxis auftretender und für diesen Artikel relevanter Fall ist das Verhalten mancher VPN-Client-Software: Es gibt Beispiele, in denen der Hersteller als Default von der MTU der physischen Schnittstelle großzügig, etwa 100 Oktetts, abzieht und die TCP/IP-Software entsprechend „steuert“. An eine Ethernet-Schnittstelle mit MTU 1500 würden dann zu versendende IP-Datagramme übergeben, die nicht größer als 1400 Oktetts sind.

Abbildung 2: TCP-Header mit optionalem MSS-Header-Anteil

Man sieht: Das Fragmentierungsthema ist Teil einer Performance-Gesamtproblematik.

Es gibt bereits verschiedene Versuche, das Problem automatisiert in den Griff zu bekommen. Viele davon setzen TCP-Verbindungen als Übertragungsbasis voraus, oder es muss für jede Anwendung einzeln ein solcher Kniff zur Verfügung stehen. Alle derartigen Ansätze gehen von Annahmen über die Verbindungsstrecke bzw. den Grund für eventuelle Übertragungsprobleme aus. Auf Basis solcher Annahmen wird versuchsweise sowohl auf Übertragungsprobleme reagiert als auch eine verkleinerte MTU präventiv verwendet.

Dabei kann allerdings einiges schiefgehen:

Treffen für einen genutzten Ansatz getroffene Annahmen nicht zu, führt dies leicht zu einer unnötigen Drosselung der betroffenen Kommunikationsverbindung.
Addieren sich die MTU-Optimierungsversuche verschiedener, beteiligter Software unglücklich durch immer weitergehende Reduzierung der verwendeten MTU, so wird die Wirkung moderner Ansätze zur Performance-Steigerung massiv entwertet.
Versuche, über sender- und empfängerseitige TCP-Optimierung des Verhaltens mit möglichst großen Paketen und möglichst viel Datenversand „am Stück“ moderne Netzwerkbandbreiten und intelligente Netzanschlüsse gut zu nutzen, treffen dann auf „Mini-Pakete“.
Damit wird der mögliche Erfolg einer ganzen Palette von Performance-Optimierungsversuchen infrage gestellt. TCP Window Scaling, TCP Segmentation Offload in Kombination mit Receive Side Scaling, und ähnliche Ansätze werden auch von aktuellen Client-Betriebssystemen unterstützt, nicht nur bei zentralen Systemen. Zusammen mit einer Verteilung von Datenmengen auf viele kleine, einzeln zu behandelnde Pakete verpufft die Wirkung aber schnell, oder der TCP-Beschleuniger wird gar zum Puffer-Verstopfer.
Unterstützt ein Teil der an einer Übertragungsstrecke beteiligten Geräte bestimmte Anti-Fragmentierungstricks nicht, nützt die Intelligenz beim Sender nur bedingt.
Ein einfaches, für Client-to-Site-VPN aber wichtiges Problembeispiel: Unterstützt jeder in zu berücksichtigenden Homeoffices genutzte DSL-Router MSS-Clamping? Was passiert aber andererseits, wenn man in die MTU-Optimierung von Hand eingreift, um nicht-Clamping-fähigen Routern auf die Sprünge zu helfen und dies trifft als Standardkonfiguration auf ein MSS-Clamping-fähiges Gerät?

Prüf- und Entscheidungsfragen, bewusstes Abwägen

Es hat sich gezeigt, dass die Entscheidung, von Hand in MTU-Einstellungen einzugreifen, sehr knifflig sein kann. Dies ist auch der Grund für die ausführlichen Erläuterungen zur Problematik im vorliegenden Artikel:

Ein kompliziertes Problem als kompliziert zu bewerten, geht auch mit weniger Details. Will man ein solches Problem aber erfolgreich angehen, braucht man Wissen. Man muss die richtigen Fragen stellen und die Antworten einordnen können. Mögliche Fragen sind hier z.B.:

Reduziert die eingesetzte Client-Software selbständig die verwendete MTU-Size?
Einen Eindruck kann man auf vielen Clients mithilfe von ping gewinnen: Man schickt einen Ping zu einem externen Ziel und gibt dabei das Setzen des Don’t-Fragment-Bits zusammen mit einem großen IP-Payload vor. (siehe Abbildung 3)

Abbildung 3: Ping-Test zur Sondierung der (angenommenen) optimalen MTU-Size

Bei ping-Versuchen mit Paketen, die größer sind als eine vom VPN-Client als zulässig angenommene MTU-Size, erhält die TCP/IP-Software des Clients vom VPN-Client oft eine Information und gibt die „fragmentation needed“/„Packet too Big“-Meldung zurück. Dabei wird (Kontrolle im Testlabor z.B. mit Wireshark) gar kein ping-Paket vom Client verschickt, wenn der Grund „lokales Wissen“ auf dem Gerät ist, z.B. vom VPN-Client kommend.

Im gezeigten Testbeispiel liegt die mit einem VPN-Tunnel wegen Fragmentierungsannahme abgefangene Paketlänge deutlich unter dem, was nach einem anzunehmenden MSS-Clamping übrig bliebe. Der testweise Versuch ohne VPN-Tunnel, mit optimistisch vorgegebener Paketlänge, ist ja auch erfolgreich. Ein MSS-Clamping für einen am DSL-Router typischen PPoE-Header erklärt diese Differenz nicht vollständig.

Wenn die VPN-Software sich, wie im Beispiel, offenbar in die verwendete MTU-Size einmischt, kann es sich lohnen, wenn man Antworten auf die folgenden Detailfragen erhält, z.B. beim Hersteller oder Distributor:

Erfolgt dies auf Basis eines fest eingestellten Wertes, und kann man diesen ändern? Wird dieser Wert pauschal angesetzt (z.B. die von IPv6 erwarteten minimalen 1280) oder ausgehend von einem Wert, der von der genutzten Schnittstelle kommt?

Welche Router-Modelle werden in Homeoffice-Fällen eingesetzt, wo Probleme gemeldet werden?
Ist bekannt, dass vorkommende Geräte kein MSS-Clamping unterstützen, kann ein manueller Eingriff in die MTU-Size sinnvoll sein, um diesen Umstand zu kompensieren. Entsprechend kann man erwägen, mit zwei verschiedenen Grundeinstellungen zu arbeiten und diese differenziert auf die Homeoffice-Kandidaten zu verteilen.
Nutzt der eingesetzte VPN-Client UDP oder TCP für den schützenden Tunnel?
Will man sich bewusst auf TCP-basierte Optimierungsansätze abstützen, muss man evtl. an dieser Stelle eingreifen und Konfigurationsoptionen nutzen.
Ist damit ein Wechsel der Methode zur Absicherung der VPN-Übertragung verbunden, muss das natürlich unter Sicherheitsgesichtspunkten diskutiert und freigegeben werden. Es ist wichtig, sich darüber im Klaren zu sein, dass die TCP-Flusskontrolle dann geschachtelt zweimal ins Spiel kommt, einmal für den Tunnel und zum zweiten für jede eingepackt im Tunnel transportierte TCP-Verbindung. Auch dies ist in bestimmten Situationen nicht ohne Tücken. Gibt es Probleme mit TCP-basiertem Tunneling, gehört dies auf die Kandidatenliste für mögliche Ursachen.
Wird UDP als Basis der VPN-Übertragung genutzt und soll das auch so bleiben, kann dies ein wesentlicher Grund dafür sein, dass ein moderater manueller Eingriff in die verwendete MTU-Size sinnvoll ist und spürbare Wirkung hat.
Dieser Eingriff ersetzt dann TCP-basierte Automatismen zur Umgehung eines Fragmentierungsproblems. Dafür heilt die VPN-Verbindung keine Paketverluste selbständig durch erneutes Senden wie bei TCP. Eine solche Vollständigkeitssicherung zur Übertragung bleibt hier allein den über diese Verbindung transportierten Datenströmen überlassen. Hier muss man seine wichtigen Datenübertragungen kennen und vorsorglich testen oder die Anwendungen bzgl. gehäuft gemeldeter Probleme via VPN kritisch im Auge behalten.
Wird IPv6 transportiert oder (vorläufig) noch nicht?
Es ist wenig sinnvoll, ein auf Fragmentierung zurückgeführtes Performance-Problem für einen auf IPv4 basierenden VPN-Tunnel so umgehen zu wollen, dass man für getunnelte IPv6-Pakete die von IPv6 erwartete Mindest-MTU unterschreitet.
Voraussichtlich handelt man sich damit mindestens eine neue Performance-Bremse ein. Diese kommt womöglich erst zu einem späteren Zeitpunkt zum Tragen, wenn vermehrt größere Datenflüsse über IPv6 durch den VPN-Tunnel anfallen. Ob man sich dann noch an den rigorosen Eingriff in die MTU-Size erinnert und die richtigen Schlüsse zieht?
Wer IPv6 grundsätzlich als Payload an der VPN-Tunnelschnittstelle zulässt, sollte daher nicht nur die Minimal-MTU von 1280 dafür übriglassen, sondern eine moderate Reserve obendrauf für mögliche bis zum VPN-Gateway evtl. hinzukommende Transport-Header. Nötigenfalls muss man Möglichkeiten herausfinden und nutzen, wie man beim konkreten Produkt unterschiedliche MTU-Vorgaben für IPv4 bzw. IPv6 einstellt, wenn bestimmte IPv4-Datenströme sich mit einer IPv6-freundlichen MTU nicht stabilisieren lassen.

Ein Eingriff in das Verhalten von Client-to-Site-VPN-Fällen mit Blick auf die verwendete MTU-Size kann also bedingt Probleme lösen, ist aber nicht zwingend der Schlüssel zum Erfolg.

Auch kann man je nach Produktkonstellation verschiedene Optimierungsmöglichkeiten abwägen, das Zu- bzw. Abschalten von TCP-basierten MTU-Optimierungsansätzen, einen manuellen Eingriff oder auch eine Kombination aus beidem. Wenn man sich daran wagt, ist jedenfalls Wissen zu Optionen und ihrer konkreten Wirkung nötig, und der Einsatz sollte dosiert erfolgen. Andernfalls hat man am Ende ein Übel durch ein anderes ersetzt:

Ein extrem auf Fragmentierungsvermeidung optimiertes Endgerät kann schon im Homeoffice-Einsatz bei bislang ohne Probleme flott laufenden Vorgängen spürbar langsamer wirken. Im Büro-LAN oder –WLAN präsentiert sich ein so gedrosselter Client auch mit neuester Hardware schnell als lahme Ente, wenn erfolgte MTU-Eingriffe auch an der LAN- bzw. WLAN-Schnittstelle greifen.
In manchen Umgebungen wird der VPN-Tunnel auch am Firmensitz verwendet, um WLAN-basierte Kommunikation besonders abzusichern. In diesem Fall wird das schnelle WLAN mit performantem Sicherheitsübergang ins LAN über einen drastisch MTU-beschränkten VPN-Tunnel womöglich so ausgebremst, dass der Laufzeit-Vorteil gegenüber der Homeoffice-Situation kaum noch wahrnehmbar ist.
Probleme mit vorübergehenden Engpässen, bei denen sich Paketverluste häufen, löst der Einsatz von wegen MTU-Beschränkung künstlich kleinen Paketen nicht.

Von einem mit einem solchen sporadischen Engpass verbundenen mehrfachen Slow Start betroffener TCP-Verbindungen würden sich Datenströme womöglich noch halbwegs erholen. Das damit mögliche, leidliche Wiedererstarken der Übertragungsgeschwindigkeit kann allerdings durch kleine Segmentgrößen so ausgebremst werden, dass bei Anwendungen feste Timer ablaufen. Das Netzwerk ist noch rechtzeitig wieder in einen brauchbaren Zustand zurückgekehrt, die Fehlermeldungen und Vorgangsabbrüche auf Anwendungsebene kommen trotzdem zustande.

Ohne ausreichendes Wissen um die Produkte und Einstellmöglichkeiten bei Homeoffice-Sorgenkindern und deren Einsatzumgebung (Internet-Anschluss und Zugangsgerät) kann ein manuelles Variieren der MTU-Size also mühselig und frustrierend sein. Boomerang-Effekte sind im schlimmsten Fall auch möglich. Eventuell ist ein „Finger davon“ die Entscheidung, zu der man letztlich kommt.

Dennoch ist es sinnvoll, sich Grundlagen und mittlerweile verfügbare Optimierungsoptionen einmal genauer anzuschauen. Zum einen hilft ein solches Überblickswissen dabei, sich bei der Lösung von Homeoffice-Problemen nicht zu euphorisch auf eine Einstellmöglichkeit zu stürzen und ratlos in eine Seiteneffekt-Falle zu tappen.

Außerdem ist eine durch plötzlich erhöhtes Homeoffice-Aufkommen veränderte Netzsituation nicht der einzige aktuelle Praxisfall, bei dem Laufzeit- und Performance-Fragen durch Veränderungen auf dem Laufweg „Ende-zu-Ende“ eine knifflige Thematik werden können.

In modernen LANs mit rapide steigenden Bitraten sollten im Data Center als Mindestmaßnahme Optionen sinnvoll eingesetzt werden, um möglichst viel aus der Leistungsfähigkeit des Netzes herauszuholen. Ein Ansatz ist dabei das Senden möglichst großer Pakete. Was aber, wenn davon beim Empfänger keine spürbare Verbesserung ankommt oder gar alles langsamer zu werden scheint als vor der technischen Modernisierung?

Herumprobieren kann natürlich zu Glückstreffern führen. Aber mit Wissen wie dem am Homeoffice-Fall Vorgeführten kann man systematisch vorgehen und Einstelloptionen besser verstehen und nutzen.

MTU-Tuning ist nicht der Schlüssel zum (vollen Erfolg) – was nun?

Zum Homeoffice-Problem, das sich durch einen plötzlichen Trend wie im Corona-Fall aufschaukeln kann, sollen ein paar ergänzende Hinweise aus der Praxis abschließend nicht fehlen.

Diese haben ihren Ursprung in Zeiten, in denen lokale Netze noch deutlich leistungsschwächer und störanfälliger waren und auch die Endgeräte mit ihren Betriebssystemen und TCP/IP-Softwarelösungen längst nicht so multitaskingfähig und selbstheilend.

Übertragen auf aktuelle Endgeräteausstattung wie moderne Windows-Versionen und darauf laufende typische Anwendungen, können sie aber auch heute noch unter nicht idealen Arbeitsbedingungen helfen. Die netzwerknahen Client-Einstellungen werden dabei nicht berührt und können in der optimalen Netzumgebung am Arbeitsplatz „im Büro“ aus der dort gegebenen IT-Infrastruktur das Maximale herausholen.

Tipp 1: Startvorgänge entzerren
Es ist schön bequem, wenn zu Arbeitsbeginn alles, was man so typisch über den Tag braucht, gestartet wird. Man wartet einmal die Startvorgänge ab und kann danach munter zwischen den Anwendungen wechseln, wie man es braucht. Manche Anwendungen sollen möglichst durchgängig online sein, damit man erreichbar ist, alles Wichtige mitbekommt und sofort reagieren kann. Heißt das aber, dass alle diese Arbeitsmittel und Helferlein praktisch gleichzeitig gestartet werden müssen?
Gerade Startvorgänge sind oft geschwätzig und empfindlich zugleich sowie eine starke Belastung für den Rechner. Ist diese Anfangshürde erst erfolgreich genommen, läuft die Software oft deutlich genügsamer und kommt auch stabiler mit kleineren Performance- und Stabilitätsproblemen bei der Netzübertragung zurecht.
Warum also nicht mal versuchen, die Startvorgänge nacheinander zu durchlaufen, zumindest aber die problematischen Anwendungen einzeln zu starten und jeweils den erfolgreichen Start abzuwarten, ehe man den nächsten Doppelklick macht? So stürzen sich nicht alle Problemfälle ressourcenhungrig beim Start zugleich auf dieselben Ressourcen und kommen sich dabei in empfindlichen Momenten gegenseitig in die Quere.
Tipp 2: Den Arbeitsbeginn bedingt verlegen
Der gewohnte Arbeitsbeginn im Büro erfolgt bei vielen zu typischen Uhrzeiten. Was bei Tipp 1 für den Konkurrenzkampf vieler Anwendungsstarts um Rechner- und Netzkapazitäten galt, trifft bei vielen gleichzeitig mit dem netzbasierten Arbeiten beginnenden Personen auch für die gemeinsam genutzte Netzinfrastruktur „Internet“ zu. Die Infrastruktur am Arbeitsplatz ist auf den entsprechenden parallelen Ansturm vermutlich geeignet ausgelegt. Gilt das aber auch für die Wege von den Homeoffices in die verschiedenen, z.B. wegen Corona plötzlich stärker remote genutzten Umgebungen?
Wer im konkreten Fall aus dem Homeoffice um die gewohnte Uhrzeit des Arbeitsbeginns zu kämpfen hat, bis endlich die VPN-Verbindung steht und alle Anwendungen erfolgreich Verbindung aufgenommen haben, könnte es mal mit einer anderen Uhrzeit versuchen. Ob man sich nun 10 Minuten mit einem quälenden Start und mehreren Fehlversuchen herumärgert, oder die kritische Startphase vor- oder nach hinten verlegt, was ist besser?
Tipp 3: „Reboot tut gut“
Dieser Spruch ist weder originell noch neu. Diejenigen, denen er bekannt vorkommt, erinnern sich vielleicht an entsprechende Erfahrungen mit älteren Windows-Versionen und dem Ruhezustand. Mehrmals aus dem Ruhezustand aufgeweckt (etwa, um das lästige Neustarten von Anwendungen zu Arbeitsbeginn zu vermeiden, siehe Tipp 1), schleppt sich die Windows-Sitzung so vor sich hin. Einmal „Neu starten“, oder statt abendlichem Ruhezustand „Herunterfahren“ gewählt, und alles lief deutlich flotter.
Ohne auf Details einzugehen: Bei Windows 10 ist „Herunterfahren“ ein wenig der neue „Ruhezustand“. Dem kann man dadurch beikommen, dass man gelegentlich bewusst „Neu starten“ durchlaufen lässt – und nicht erst, wenn einen ein größeres Update oder Rollup dazu zwingt. Vielleicht war gar nicht die VPN-Netzanbindung der Bremser.
Tipp 4: Plötzlich Probleme machende Anwendungen neu starten
Moderne Versionen von Anwendungen sind deutlich robuster geworden, was gelegentliche Probleme, etwa den kurzzeitigen Verlust der Verbindung zum zentralen Applikationsserver, angeht. Ein gutes, einfaches Beispiel ist Microsoft Outlook: Bei älteren Versionen reichte das Ausdocken aus einer Docking Station und der damit verbundene kurze Verlust der Netzverbinndung, und die Fehlermeldungen hörten erst nach einem Neustart auf. Das ist mit aktuellen Versionen deutlich anders. Viele Wechsel zwischen LAN und WLAN oder Verbindungsabbrüche im mobilen Einsatz durch Funklöcher bewältigt Outlook problemlos und stellt die Verbindung zum Server selbst wieder her.
Viele solcher Fälle können also automatisch aufgefangen werden – aber eben nicht alle, schon gar nicht bei Häufung. Im Homeoffice können zumindest in Stoßzeiten der Internetnutzung solche Verbindungsverluste kurzzeitig gehäuft auftreten. Danach kann die Netzsituation wieder stabil sein, aber die Fehlermeldungen bleiben. Ein Anwendungsneustart mit neuem Aufbau der Verbindung zum Anwendungsserver, frei von der Störungshistorie, kann helfen.
Das am Beispiel von Outlook Erläuterte gilt für eine ganze Reihe von Anwendungen. Ein entsprechender Tipp an die Nutzerkreise – und mancher Hilferuf wird gar nicht erst an der IT-Hotline eingehen. Für das im Augenblick „besonders volle Internet“ kann zudem der eigene IT-Bereich nichts, für eine vermeintlich plötzlich gestörte Anwendung suchen viele aber genau dort den Schuldigen, oder werden gar per wiederholter Fehlermeldung dorthin verwiesen.
Tipp 5: Empfindlichen Anwendungen Rechner und Netz evtl. möglichst exklusiv gönnen
Alles scheint gut zu laufen, nur bestimmte Features einer wichtigen Konferenz- oder Kollaborationsanwendung streiken wiederholt genau dann, wenn man an einem „virtuellen Besprechungstermin“ teilnehmen will? Eine bestimmte, nur wenige Male am Tag genutzte Anwendung macht immer wieder Probleme, und die Fehlermeldungen sagen irgendetwas wie „Server nicht verfügbar“, „Verbindung verloren“ oder Ähnliches? Im Büro ist das nie ein Problem gewesen?
Ganz so leistungsfähig und für quasi-parallele Übertragung der Datenströme von problematischer Anwendung und sonstigem Hintergrundgeplapper geeignet ist der Homeoffice-Anschluss eben doch nicht. Auch wenn es lästig ist: Einen Versuch, vorübergehend andere Anwendungen zu beenden und hinterher neu zu starten, ist so ein Fall wert. Wenn es hilft, hat man ein Problem weniger. Vielleicht laufen die kurzzeitig beendeten Anwendungen hinterher sogar besser, siehe Tipp 4, dann spart man noch einmal Zeit.
Zugegeben, mit Tuning des Endgeräts haben diese Tipps nur wenig zu tun. Was spricht aber gegen den Versuch eines entsprechenden Merkblatts, das dem Homeoffice-Nutzerkreis als Hilfestellung zur Verfügung gestellt wird? Wer dank einer solchen Anleitung von zuhause mithelfen kann, die Krise durchzustehen, ist womöglich sogar eher stolz auf sein Wissen als kritisch gegenüber der trotz allem möglich gemachten Homeoffice-Anbindung.

VPN-Tunnel aus dem Homeoffice – mit MTU-Tuning?

Kontakt

Services

Rechtliches

VPN-Tunnel aus dem Homeoffice – mit MTU-Tuning?

Teile diesen Eintrag

Kontakt

Services

Rechtliches