Solche VPN-Verbindungen funktionieren aber nicht immer. Es gibt sozusagen einen Klassiker, ein Problem, das immer wieder einmal auftritt. Und vielleicht derzeit wieder etwas öfter. Meinen Seminarteilnehmern des Praxisseminars „Fehlersuche“ lege ich regelmäßig ein Beispiel dafür vor. Und das lautet so:
Ein Verkehrsbetrieb vertreibt Fahrkarten über stadtweit verteilte Kioske. Der Kiosk-Betreiber erhält zu diesem Zweck einen Client-PC, der über Internet-VPN mit dem Rechenzentrum des Verkehrsbetriebs in Verbindung steht. Immer wieder kommt es vor, dass der Datenabgleich fehlschlägt. Der PC im Kiosk bleibt hängen und muss neu gestartet werden.
Im Wireshark Trace, den ich den Teilnehmern vorlege, erkennt man den Ablauf wie folgt:
- Der Client baut erfolgreich eine TCP-Verbindung zum Server im Rechenzentrum auf.
- Es werden allerlei Daten ausgetauscht.
- Plötzlich sendet der Server ein Paket mit der Maximalgröße 1514 Bytes. Dieses Paket geht offensichtlich verloren, d.h. es wird vom Client nicht quittiert.
- Stattdessen erhält der Server eine ICMP-Meldung, jedoch von einer bis dahin unbekannten IP-Adresse.
- Der Server sendet das verlorene Paket erneut, jedoch mit verringerter Paketgröße.
Im Fehlerfall wird das verlorene Paket allerdings nicht sofort wiederholt. Stattdessen scheint es ein Timeout von einigen Sekunden zu geben. Erst dann sendet der Server das verlorene Paket ein weiteres Mal, jedoch mit der ursprünglichen Größe. Es gibt wieder eine ICMP-Meldung, ein erneutes Timeout mit Wiederholung etc. Die Kommunikation kommt zum Erliegen.
Was ist das für eine ICMP-Meldung? Der Protokollanalysator übersetzt es als „Destination Unreachable, Fragmentation Needed“. Dahinter verbirgt sich ein uraltes Verfahren, das bereits 1990 im RFC1191 vorgestellt wurde: Path MTU Discovery. Die „Path MTU“ ist die Maximum Transmission Unit, also die Maximallänge eines IP-Pakets, die vom gesamten Übertragungsweg Ende-zu-Ende unterstützt wird.
Wie funktioniert das? Eigentlich sind IPv4-Router in der Lage, Pakete zu zerteilen, wenn sie zu groß sind. Das nennt man Fragmentierung. Fragmentierung kostet jedoch Performance, weshalb man sie zu vermeiden sucht. IPv4-Pakete werden also mit gesetztem Don’t-Fragment-Bit verschickt. Router verwerfen derart markierte Pakete, wenn sie zu groß für das ausgehende Interface sind. Stattdessen antworten sie dem Absender mit besagter ICMP-Meldung und teilen darin die maximale Paketgröße mit, die sie ohne Fragmentierung weiterleiten können. Der Absender kann daraufhin das Paket mit entsprechend verminderter Größe erneut versenden.
Wo tritt das auf? Prominentes Beispiel ist das VPN. VPN-Router „tunneln“ Pakete durch ein anderes Netz, hier das Internet. Dazu müssen sie die Pakete in einen zusätzlichen Rahmen packen. Dieser Rahmen (z.B. Encapsulation Security Payload, ESP) benötigt einige Bytes. Da jedoch das Internet, wie auch das LAN in Homeoffice und RZ, auf Ethernet basiert, können die Pakete nicht einfach größer werden. Stattdessen zwackt man die benötigten Bytes von der Nutzlast ab.
Und worin besteht das Problem? Nun, ICMP-Meldungen haben keinen guten Ruf, man denke z.B. an den „Ping of Death“. Deshalb kann es sein, dass Firewalls sie aufhalten oder der Adressat (hier der Absender eines großen Pakets) sie bewusst ignoriert. Dann funktioniert Path MTU Discovery nicht. Aus Sicht des Absenders wird das Netz zu einem Schwarzen Loch; irgendwo gibt es einen Black Hole Router.
Moderne Windows-Varianten heilen das Problem, indem sie nach einem Timeout die MTU auf 576 Byte zurücksetzen und fortan alle Pakete ohne das Don’t-Fragment-Bit aussenden. Dann läuft die Verbindung zwar, aber leider mit schlechter Performance. Mit IPv6 – dort gibt es das Verfahren ebenfalls – ist es übrigens deutlich besser: Die MTU wird auf immerhin 1220 Byte zurückgesetzt.
Sollten Sie also derzeit im Homeoffice schlechte Performance oder gar Verbindungsabbrüche erleben, braucht es nicht am überlasteten Internet zu liegen. Es könnte auch ein Effekt in Zusammenhang mit Path MTU Discovery sein. Es handelt sich – wie gesagt – um einen Klassiker!