WSL-MTU-Hänger

Ein WSL2-Host ist die eine Konstellation, in der eine Sitzung normal verbindet und dann einfach stehen bleibt, ohne Fehler auf einer der beiden Seiten. Es liegt fast nie an SSH oder Tessera — es ist die MTU des virtuellen Adapters, hinter dem WSL2 sitzt. Beobachtet Tessera beim Verbinden den typischen Hänger, zeigt es eine bernsteinfarbene Karte mögliches MTU-Problem mit WSL2 / Tailscale, die hierher verlinkt.

Symptome

• Die Sitzung verbindet sich, die Eingabeaufforderung erscheint, und kurze Befehle laufen einwandfrei.
• Alles, was einen großen Schub sendet, friert ein: cat auf einer langen Datei, ein breites ls, ein vollständiges Neuzeichnen von tmux, eine Übertragung im Dateien-Panel.
• Nichts meldet einen Fehler. Die Sitzung bewegt sich einfach nicht mehr. Neu verbinden funktioniert, dann bleibt sie bei derselben Art von Ausgabe wieder hängen.
• Derselbe Host verhält sich über mosh besser als über SSH.

Erreicht die Verbindung überhaupt nie eine Eingabeaufforderung, kann derselbe Fehler den SSH-Schlüsselaustausch verschlucken, der selbst groß ist. Der Test unten gilt trotzdem.

Warum das passiert

WSL2 läuft hinter einem virtuellen Hyper-V-Switch, und sein eth0 startet mit einer MTU von 1500. Erreicht der Windows-Host das Netz tatsächlich über etwas Kleineres — ein VPN, PPPoE oder irgendeinen Tunnel —, werden Pakete oberhalb dieser echten Pfad-MTU irgendwo dazwischen verworfen.

Path MTU Discovery soll genau das abfangen: Der Hop, der das Paket nicht weiterleiten kann, schickt ein ICMP fragmentation needed zurück, und der Sender geht herunter. Viele VPNs und Firewalls verwerfen dieses ICMP, sodass nie eine Antwort ankommt. Kleine Pakete fließen weiter, große verschwinden lautlos — ein PMTU-Blackhole. Für SSH sieht das aus wie eine Verbindung, die ohne Grund stehen geblieben ist.

So bestätigen Sie es

Prüfen Sie in WSL, was die Schnittstelle angibt:

ip link show eth0

Finden Sie dann die Größe, die den Pfad tatsächlich übersteht. Diese Pings setzen das Don't-Fragment-Bit, und die Nutzlast plus 28 Byte Header ergibt die Gesamtgröße; -s 1472 prüft also ein 1500-Byte-Paket. Zielen Sie auf etwas am anderen Ende desselben Pfads — den Server, zu dem Sie sich verbinden, oder eine beliebige öffentliche Adresse:

ping -M do -s 1472 -c 1 example.com   # 1500 — usually times out
ping -M do -s 1372 -c 1 example.com   # 1400 — usually gets through

Eine Zeitüberschreitung ist das Blackhole. (Ein sofortiger lokaler Fehler bedeutet stattdessen, dass die Größe die MTU Ihrer eigenen Schnittstelle übersteigt — senken Sie -s und versuchen Sie es erneut.) Grenzen Sie den Bereich ein, bis Sie die größte Nutzlast finden, die antwortet; plus 28 ergibt das Ihre echte Pfad-MTU.

Die Entsprechungen auf der Windows-Seite, aus PowerShell:

ping -f -l 1472 example.com
netsh interface ipv4 show subinterfaces

Der zweite Befehl listet die MTU jedes Adapters auf. Ein VPN-Adapter mit 1400 neben vEthernet (WSL) mit 1500 ist genau die Abweichung, die Sie suchen.

In WSL beheben

Setzen Sie die Schnittstelle auf die gemessene Größe. Das wirkt sofort und geht beim nächsten Herunterfahren verloren:

sudo ip link set dev eth0 mtu 1400

Verbinden Sie sich neu und wiederholen Sie, was vorher hängen blieb. Läuft die Ausgabe sauber durch, ist die Diagnose bestätigt.

Damit es dauerhaft bleibt, lassen Sie WSL es beim Start anwenden. In /etc/wsl.conf innerhalb der Distribution:

[boot]
command = ip link set dev eth0 mtu 1400

Führen Sie dann unter Windows wsl --shutdown aus und starten Sie die Distribution erneut. Der [boot]-Befehl setzt ein einigermaßen aktuelles WSL voraus — prüfen Sie das mit wsl --version.

Verwenden Sie den Wert aus Ihrem Ping-Test, statt 1400 zu übernehmen. 1400 ist ein sicherer Rückfallwert, der fast jedes VPN übersteht, aber ein auf Ihren Pfad abgestimmter Wert verschenkt weniger von jedem Paket.

Oder WSL den Host spiegeln lassen

Ab Windows 11 22H2 mit WSL 2.0+ übergibt das gespiegelte Netzwerk der Distribution die Schnittstellen des Hosts samt MTUs, sodass die Abweichung gar nicht erst entsteht. In %UserProfile%\.wslconfig:

[wsl2]
networkingMode=mirrored

Übernehmen Sie es mit wsl --shutdown. Das ändert erheblich mehr als die MTU — localhost und die Erreichbarkeit im lokalen Netz verhalten sich beide anders —, halten Sie sich also an den Boot-Befehl, wenn eine hängende Sitzung Ihr einziges Problem ist.

Wenn der Hop mit der kleinen MTU auf der Serverseite liegt

WSL ist nicht immer die eingeschränkte Seite; derselbe Ping-Test vom Server aus zeigt, welche Seite begrenzt ist. Wo Sie den Router dazwischen kontrollieren, behebt das Begrenzen der TCP-MSS auf die ermittelte Pfad-MTU alle Verbindungen darüber auf einen Schlag:

iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

Solange Sie noch feststecken

Den Transport des Hosts auf mosh umzustellen ist eher ein Behelf als eine Lösung. Die Datagramme von mosh sind klein genug, um unter einer kaputten MTU durchzuschlüpfen, und mosh zeichnet den Bildschirm neu, statt einen Byte-Strom nachzuspielen; eine interaktive Sitzung überlebt daher. Das Dateien-Panel und der tmux-Seitenkanal laufen weiterhin über SSH, große Übertragungen können also weiter hängen bleiben.

Passt nichts davon zu dem, was Sie sehen, erfassen Sie ein Log (Einstellungen → Diagnose → Log exportieren, siehe Diagnose) und melden Sie ein Problem unter GitHub Issues.