Git hängt ohne VPN? OpenSSH markiert Pakete per IPQoS

Ein Klon aus dem Büro funktioniert, derselbe Klon über einen Handy-Hotspot funktioniert, und derselbe Klon aus einem Hotelnetz hängt, bis ein VPN eingeschaltet wird. Der SSH-Handshake endet, und die Sitzung verstummt beim ersten echten Transfer. Eine Zeile in der Client-Konfiguration heilt git und ssh gemeinsam. Wenn eine einzige Clienteinstellung mehrere Werkzeuge auf einmal repariert, liegt der Fehler in dem, was der Client sendet, nicht in der Strecke, über die er es sendet.

Lesen Sie das Symptom als Routing-Unterschied

Ein Tunnel, der ein Problem heilt, ist selten eine Reparatur. Er tauscht Route, Träger und Middleboxen aus, während der Laptop exakt dieselben Pakete weiter erzeugt. Wenn eine Route einen Header falsch behandelt und eine andere ihn unverändert durchlässt, liegt der Unterschied in der Politik der Middlebox und nicht im Client. Der Tunnel ist hier Zeuge, nicht Lösung.

Die Stelle, an der die Sitzung stirbt, grenzt es weiter ein. Nichts, was bei der Namensauflösung oder beim Schlüsselaustausch scheitert, sieht so aus. Eine Sitzung, die sich authentifiziert, ein Banner ausgibt und dann beim ersten großen Schreibvorgang einfriert, hat bereits bewiesen, dass Routing, Namensauflösung und Zugangsdaten alle funktionieren.

Der Client stempelt ein QoS-Byte auf jeden SSH-Socket

Jede OpenSSH-Verbindung ab 7.8 trägt im IP-Header einen Wert, den Router zur Priorisierung von Verkehr nutzen dürfen. Terminalsitzungen bekommen einen Wert und Massenkopien einen anderen, nach der Theorie, dass ein tippender Mensch eine bessere Behandlung verdient als eine Dateiübertragung. Die meisten Netze ignorieren den Hinweis vollständig, weshalb er jahrelang unbemerkt bleibt. Eine Minderheit von WLAN-Treibern, Mobilfunknetzen und VPN-Konzentratoren reagiert darauf, und einige davon reagieren schlecht.

Wenn dieser Wert mitten im Strom umgeschrieben oder verworfen wird, scheitert die Verbindung nicht, sie kommt zum Stillstand. Neuübertragungen steigen, das Fenster bricht zusammen, und die Anwendung meldet nichts, weil nichts einen Fehler erzeugt hat. Diese Stille ist der Grund, warum Menschen das Symptom als Hänger statt als Fehler beschreiben.

Bestätigen Sie zuerst den Client-Build mit ssh -V. Alles ab 7.8 trägt dieses Verhalten standardmäßig.

Drei Befehle, die das von MTU und DNS trennen

Zwei ähnliche Ursachen sollten ausgeschlossen werden, bevor Sie irgendeine Konfigurationsdatei bearbeiten. Ein MTU-Fehler lässt kleine Austausche durch und friert beim ersten großen Paket ein, während ein Namensfehler nie eine Sitzung zustande bringt.

ssh -o IPQoS=none -v [email protected]
ssh -G [email protected] | grep -i ipqos
sudo tcpdump -ni any -vv "tcp port 22"

Der erste Befehl wiederholt den fehlschlagenden Vorgang mit abgeschalteter Markierung, und ein erfolgreicher Lauf ist der stärkste einzelne Beweis, den es gibt. Der zweite gibt die Konfiguration aus, die der Client tatsächlich auf dieses Ziel anwenden wird, und fängt damit einen veralteten Eintrag in einer vergessenen Datei. Der dritte zeigt das TOS-Byte in beide Richtungen, während der Transfer hängt, und das interessante Muster ist ein Wert auf der kaputten Route und keiner auf der funktionierenden.

Führen Sie die Aufzeichnung auf dem Laptop und nicht auf dem Server durch, weil der Absender den Wert setzt und beide Richtungen ihn ändern können. Vergleichen Sie eine funktionierende und eine fehlschlagende Route mit derselben Aufzeichnung, und der Unterschied zeigt sich ohne Raten.

Stecken Sie die Ausnahme in eine Datei, einen Host nach dem anderen

Eine Ausnahme gehört neben den Host, für den sie gilt, mit einem Kommentar, der sagt, warum es sie gibt.

Host gitlab.example.internal
    IPQoS none
    # direct route rewrites the marking; the tunnel route passes it

Der Geltungsbereich zählt mehr als der Wert selbst. Ein Platzhaltereintrag schaltet das Verhalten überall ab, wirft einen Hinweis weg, der in wohlerzogenen Netzen hilft, und lässt niemanden sagen, wann er aufgetaucht ist. Ein Eintrag pro Host ist lesbar, umkehrbar und nach der Reparatur des Netzes trivial zu löschen. Nutzen Sie die Benutzerdatei für einen persönlichen Workaround und eine verwaltete Datei, wenn eine ganze Flotte dieselbe Ausnahme braucht.

Seien Sie ausdrücklich, was die Ausnahme nicht abdeckt. Sie gilt für SSH, also liegen ein HTTPS-Remote, ein Paketspiegel und ein Browser außerhalb, und ein Fehler in einem davon braucht seinen eigenen Beleg. Auf einer Kette über einen Bastion nutzt jeder Sprung die Client-Konfiguration, und der Sprung, der hängt, ist der, den es einzugrenzen lohnt.

Schließen Sie den Kreis mit dem Netzbetreiber

Übergeben Sie den Befund als vier Fakten: Client-Version, getestete Route, genutzter VPN-Client und welche Richtung die Markierung trug. Diese vier genügen einem Netzbetreiber, um die Behandlung nachzuvollziehen und zu entscheiden, ob sie absichtlich ist.

Heilt die Ausnahme den Hänger nicht, entfernen Sie sie. Ein Workaround, der ein gescheitertes Experiment überlebt, wird zum Volksmund, und die nächste Person verbringt eine Stunde damit zu beweisen, dass er nichts tut. Heilt sie den Hänger, ist der Pfad für jedes andere Werkzeug, das ihn kreuzt, weiterhin falsch, und die Reparatur gehört zu dem, der die Middlebox betreibt.

Die Client-Änderung ist eine Notlösung mit Ablaufdatum. Schreiben Sie dieses Datum in den Kommentar.