Git in WSL2 hängt über VPN: Interface-MTU oder Pfad?

Der Klon authentifiziert sich, die Objektanzahl erscheint, und dann bewegt sich minutenlang nichts. Windows meldet das VPN als verbunden, der Hostname wird aufgelöst, und ein Browser auf derselben Maschine lädt dieselbe Repository-Seite ohne Schwierigkeiten. Diese Kombination deutet auf Paketgröße statt auf Anmeldedaten hin, und die Größenfrage muss an zwei Stellen gestellt werden, weil WSL2 ein eigenes Linux-Interface mit eigenem MTU hat. Die eine Zahl gehört zur Windows-Seite des Pfads, die andere zur Distribution, und wer nur den VPN-Adapter liest, lässt die Hälfte des Pfads ungeprüft.

Drei Signale trennen ein Größenproblem von anderem

Das erste Signal ist die Form: Verbindungsaufbau und ein kleiner Austausch gelingen, dann kommt der Massentransfer nicht mehr voran. Das zweite ist die Symmetrie: dasselbe Repository und derselbe Transport scheitern, während ein anderer Host auf demselben Pfad funktioniert, oder der Fehler ändert sich mit der Nutzlastgröße statt mit der Tageszeit. Das dritte ist Stille: kein Authentifizierungsfehler, keine Proxy-Ablehnung, kein Namensauflösungsfehler, nur ein Transfer, der nie abgeschlossen wird.

Diese drei zusammen rechtfertigen die Hypothese einer Paketgröße. Ein DNS-Fehler, ein abgelaufenes Token, ein abgelehnter SSH-Schlüssel und ein Proxy, der CONNECT verweigert, erzeugen jeweils ihren eigenen Fehler, und keiner davon sieht wie ein Stillstand nach Erfolg aus. Dasselbe Repository, denselben Transport und dasselbe Zeitfenster beim Testen beizubehalten, macht den Vergleich ehrlich.

Vergleichen Sie beide Interfaces, bevor Sie entscheiden

Sammeln Sie die Windows-Ansicht und die Linux-Ansicht in derselben Sitzung und halten Sie sich an die Adresse des Repositories statt an eine Vermutung, welches Interface sie trägt. Der folgende Befehl löst zuerst das Ziel auf, damit die Routensuche den tatsächlichen Server beschreibt, den der Klon kontaktiert, der sich vom Namen unterscheiden kann, den ein Browser zeigte. Führen Sie beide Hälften kurz nacheinander aus, weil das VPN zwischen Versuchen die Interface-Metriken ändern kann.

netsh interface ipv4 show subinterfaces
wsl -d Ubuntu -- bash -lc 'dest=$(getent ahostsv4 github.com | awk \'NR==1{print $1}\'); ip -br link show; ip route get "$dest"'

Führen Sie die Linux-Hälfte innerhalb der Distribution aus, statt die Ausgabe in eine Windows-Shell einzufügen, da Interface-Namen und Routenwahl nur dort Sinn ergeben. Ein Einfügen aus einer Windows-Shell meldet die falschen Zahlen mit großer Zuversicht. Notieren Sie Gerät, gewählte Route und MTU von jeder Seite, bevor Sie etwas ändern.

Entscheiden Sie, ob die Zahl kleiner sein sollte

Ein größerer Interface-MTU als der Pfad tragen kann, ist nicht automatisch ein Fehler, denn die Pfad-MTU-Erkennung existiert genau dafür. Der Fehlermodus tritt auf, wenn die Erkennung unterdrückt wird: ICMP-Nachrichten werden irgendwo auf dem Weg gefiltert, der Absender erfährt das Limit nie, und große Pakete verschwinden, während kleine durchkommen. Das ist eine Eigenschaft des Pfads, nicht von Git. Es ist auch der Grund, warum eine kleine Datei auf einer Verbindung gelingen kann, auf der eine große nie fertig wird.

Wenn die Belege dafür sprechen, ist eine vorübergehende Änderung am Linux-Interface der billigste Test. Wählen Sie einen Wert unterhalb der nutzbaren Pfadgröße, notieren Sie den vorherigen und halten Sie alles andere konstant, damit der Vergleich etwas bedeutet. Wenn der Transfer mit dem kleineren Wert abgeschlossen wird, haben Sie eine Diagnose und keinen Zufall.

ip -br link show dev eth0
sudo ip link set dev eth0 mtu 1380
ip -br link show dev eth0

Entscheiden Sie, wo die Einstellung leben soll

Aus dem Test folgen drei Optionen, und meist ist nur eine davon angemessen. Wenn der kleinere Wert den Transfer behebt und der Wert für dieses Netzwerk wirklich erforderlich ist, braucht die Einstellung einen Eigentümer für ihren Lebenszyklus: einen Start-Hook in der Distribution, eine von der Plattform verwaltete Netzwerkkonfiguration oder ein dokumentiertes Verfahren. Wenn der Wert nichts behebt, nehmen Sie ihn zurück und kehren Sie zu den Fragen von Transport, Proxy und Authentifizierung zurück.

Ob es einen Start-Hook gibt, hängt von den verwendeten Windows- und WSL-Versionen und vom konfigurierten Netzwerkmodus ab. Das Spiegeln des Windows-Netzwerks kann verändern, wie ein VPN mit der Distribution interagiert, und zwar auf Arten, die mehr zählen als eine MTU-Anpassung; identifizieren Sie daher den Modus, bevor Sie eine Übergangslösung dafür entwerfen. Ein Wert, der zu einem Anbieter oder einem VPN-Profil passt, ist kein Standard für den nächsten.

Zu vermeiden ist die verlockende Platzierung: ein privilegierter Netzwerkbefehl in der Startdatei jeder interaktiven Shell oder passwortloses sudo für die gesamte ip-Binärdatei, damit ein Skript eine Zeile ausführen kann. Beides macht eine Diagnose zu dauerhafter Exposition und lässt das ursprüngliche Problem später schwerer erkennen.

Nach einem frischen Start verifizieren, dann zurücknehmen

Eine Änderung, die nur bis zum Neustart der Distribution hält, ist keine Behebung. Starten Sie die Distribution neu, verbinden Sie das VPN erneut und wiederholen Sie den ursprünglichen Git-Vorgang statt eines Ersatzes wie ping oder einer kleinen HTTP-Anfrage. Bestätigen Sie dann, dass das Interface in der neuen Sitzung den beabsichtigten Wert trägt.

ip -br link show dev eth0
ip route get "$(getent ahostsv4 github.com | awk 'NR==1{print $1}')"

Halten Sie den notierten Ausgangswert neben der Änderung, damit das Experiment sauber rückgängig gemacht werden kann, und notieren Sie, welche Adressfamilie getestet wurde, denn ein IPv4-Ergebnis sagt nichts über eine IPv6-Verbindung auf demselben Host. Die WSL-Netzwerkdokumentation beschreibt die Modi, die bestimmen, wie eine Behebung aussehen sollte; die MTU-Zahl selbst ist eine lokale Messung, keine Empfehlung.