# 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](https://bambouville.com/docs/de/files/).
- 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](https://bambouville.com/docs/de/connections/#transport-ssh-oder-mosh) 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](https://bambouville.com/docs/de/security/#diagnose)) und melden Sie ein Problem unter
[GitHub Issues](https://github.com/bambouville/tessera/issues).