Hänger Git utan VPN? OpenSSH märker paketen med IPQoS

En klon från kontoret fungerar, samma klon via telefonens hotspot fungerar, och samma klon från ett hotellnätverk hänger tills ett VPN slås på. SSH-handskakningen avslutas och sessionen tystnar vid den första riktiga överföringen. En rad tillagd i klientkonfigurationen botar git och ssh tillsammans. När en enda klientinställning reparerar flera verktyg på en gång ligger felet i det klienten skickar, inte i den förbindelse den skickar över.

Läs symptomet som en skillnad i routning

En tunnel som botar ett problem är sällan en reparation. Den byter väg, operatör och mellanliggande utrustning, medan laptopen fortsätter att producera exakt samma paket. Om en väg hanterar en rubrik fel och en annan släpper igenom den oförändrad ligger skillnaden i mellanutrustningens policy, inte i klienten. Tunneln är här ett vittne, inte en lösning.

Punkten där sessionen dör snävar in det ytterligare. Inget som misslyckas vid namnsökning eller vid nyckelutbyte ser ut så här. En session som autentiserar, skriver ut en banner och sedan fryser vid den första stora skrivningen har redan bevisat att routning, namn och inloggningsuppgifter alla fungerar.

Klienten stämplar en QoS-byte på varje SSH-socket

Varje OpenSSH-anslutning från 7.8 och framåt bär i IP-huvudet ett värde som routrar får använda för att prioritera trafik. Terminalsessioner får ett värde och masskopior ett annat, enligt teorin att en människa som skriver förtjänar bättre behandling än en filöverföring. De flesta nätverk ignorerar tipset helt, vilket är varför det går obemärkt förbi i åratal. En minoritet av Wi-Fi-drivrutiner, mobiloperatörer och VPN-koncentratorer agerar på det, och några av dem agerar illa.

När det värdet skrivs om eller kastas bort mitt i strömmen misslyckas inte anslutningen, den slutar att komma framåt. Omsändningarna ökar, fönstret kollapsar och programmet rapporterar ingenting eftersom ingenting gav ett fel. Den tystnaden är anledningen till att människor beskriver symptomet som en hängning och inte som ett fel.

Bekräfta först klientversionen med ssh -V. Allt från 7.8 och uppåt bär detta beteende som standard.

Tre kommandon som skiljer detta från MTU och DNS

Två liknande orsaker förtjänar att uteslutas innan du redigerar någon konfigurationsfil. Ett MTU-fel släpper igenom små utbyten och fryser vid det första stora paketet, medan ett namnfels aldrig ger en session.

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

Det första kommandot upprepar den misslyckade åtgärden med märkningen avstängd, och en lyckad körning är det starkaste enskilda beviset som finns. Det andra skriver ut den konfiguration som klienten faktiskt kommer att tillämpa på destinationen, vilket fångar en inaktuell post i en fil du hade glömt. Det tredje visar TOS-byten i båda riktningarna medan överföringen hänger, och det intressanta mönstret är ett värde på den trasiga vägen och inget på den som fungerar.

Gör avlyssningen på laptopen och inte på servern, eftersom avsändaren sätter värdet och båda riktningarna kan ändra det. Jämför en väg som fungerar och en som misslyckas med samma avlyssning, och skillnaden syns utan gissningar.

Lägg undantaget i en enda fil, en värd i taget

Ett undantag hör hemma bredvid den värd det gäller, med en kommentar som säger varför det finns.

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

Omfattningen betyder mer än själva värdet. En jokerteckenpost slår av beteendet överallt, kastar bort ett tips som hjälper på väluppfostrade nätverk och lämnar ingen som kan säga när den dök upp. En post per värd är läsbar, återställbar och trivial att ta bort när nätverket är reparerat. Använd användarfilen för en personlig omväg och en hanterad fil när en hel flotta behöver samma undantag.

Var tydlig med vad undantaget inte täcker. Det gäller SSH, så en HTTPS-fjärr, en paketspegel och en webbläsare står alla utanför, och ett fel i någon av dem kräver sitt eget bevis. På en kedja genom en bastion använder varje hopp klientkonfigurationen, och det hopp som hänger är det som är värt att avgränsa.

Slut cirkeln med nätverksägaren

Lämna över fyndet som fyra fakta: klientversion, testad väg, VPN-klient i bruk och vilken riktning som bar märkningen. De fyra räcker för en nätverksägare att återskapa behandlingen och avgöra om den är avsiktlig.

Om undantaget inte botar hängningen, ta bort det. En omväg som överlever ett misslyckat experiment blir folklore, och nästa person lägger en timme på att bevisa att den inte gör något. Om den botar hängningen är vägen fortfarande fel för varje annat verktyg som korsar den, och reparationen hör till den som driver mellanutrustningen.

Ändringen på klienten är en nödlösning med ett utgångsdatum. Skriv in det datumet i kommentaren.