Netz - Rettung - Recht

Bildquelle und Lizenz: XoCoO via Wikimedia Commons [CC BY-SA 3.0]

Bei meiner gestrigen mehrstündigen Bahnreise dann dasselbe Problem: kaum hatte der Zug gewendet und mein Sitz zeigte für die nächsten vier Stunden in Fahrtrichtung, packte ich meinen Laptop aus, verband mich mit dem WLAN und wollte loslegen. Doch wieder war die Konnektivität sehr unbefriedigend: ein paar einzelne Mails wurde ich los, der Newsaustausch wollte nicht recht funktionieren, auch der Zugriff auf das Webmailinterface wollte nicht, und eine SSH-Verbindung kam zwar zustande, hängte sich aber reproduzierbar beim Attachen der laufenden screen-Session auf. Andere Webseiten waren aber (mit kurzen Aussetzern) ohne Schwierigkeiten verfügbar, und auch die VPN-Verbindung ins heimische Netz stand: die Hosts dort ließen sich pingen (und ja auch via SSH nachweislich erreichen).

Ich muss eingestehen, dass ich mehrere Stunden darüber gegrübelt habe, wo das Problem wohl liegen könnte, obschon das Fehlerbild eigentlich eindeutig ist: die Netzverbindung ist stabil und recht flott, wenn man pingt, kleine Datenmengen lassen sich auch übertragen, aber sind mehr Daten zu übermitteln (wie eine Webseite oder eine screen-Session), dann läuft alles in Timeouts - das kann eigentlich nur ein MTU-Problem sein, um so mehr, wenn ein VPN beteiligt ist! Und, um das Ergebnis vorwegzunehmen: nachdem ich flüchtig gegoogelt und die MTU auf der VPN-Verbindung von 1380 auf 1300 herabgesetzt hatte, flutschte alles durch die VPN-“Leitung”, als sei nie etwas gewesen.

Aber was hat es mit dieser MTU auf sich? - Eine recht schöne Erläuterung habe ich bei der Packet University gefunden: Recognizing IP MTU Issues

Um das laienhaft zusammenzufassen: Die MTU ist die maximum transmittable unit und gibt (bei IP-Verbindungen) an, bis zu welcher Größe IP-Pakete über die Verbindung übertragen werden können. Über Ethernet-Verbindungen lassen sich Pakete mit höchsten 1.500 Bytes übertragen, die MTU ist also 1.500, und das ist auch der in der Praxis übliche Wert, denn logischerweise gibt die kleinste MTU auf einer Teilstrecke die Paketgröße für die gesamte Verbindung vor. Werden IP-Verbindungen bspw. über ein VPN getunnelt, müssen die IP-Pakete entsprechend “gekapselt” werden, “wachsen” also durch die VPN-Übertragung, sollten aber immer noch nicht die MTU überschreiten; die zu übertragenden Pakete müssen also am Anfang kleiner sein. Nachdem man Übertragungsprotokolle mehrfach ineinander verschachteln kann, kann die MTU am Ende deutlich unter 1.500 liegen.

Eigentlich sollte das kein Problem sein: ist ein Paket zu groß, um weiter übertragen zu werden, kann es entweder in mehrere Teile zerlegt (“fragmentiert”) und beim Empfänger wieder zusammengesetzt werden, oder, wenn das nicht gewünscht - und das Paket entsprechend gekennzeichnet - ist, als “unzustellbar” zurückgegeben werden. Dabei wird zugleich die MTU der Teilstrecke übermittelt, durch die das Paket nicht durchpasste. Der Absender schickt es jetzt erneut - und setzt vorher die MTU passend herab. Diese automatische Aushandlung nennt sich PMTUD oder Path MTU Discovery - und scheitert leider manchmal (oft?), bspw. weil Firewalls entsprechende ICMP-Pakete ausfiltern, aber auch aus anderen Gründen. Dann hilft es nur, beim Auftreten charakteristischer Probleme die MTU herabzusetzen - in meinem Fall von den schon niedrigen 1.380 auf 1.300. Und dann flutscht auch alles wieder.