Blijft Git hangen zonder de VPN? OpenSSH markeert pakketten met IPQoS

Een kloon vanaf kantoor werkt, dezelfde kloon via een telefoonhotspot werkt, en dezelfde kloon vanaf een hotelnetwerk blijft hangen tot een VPN wordt aangezet. De SSH-handshake eindigt en de sessie wordt stil bij de eerste echte overdracht. Eén regel in de clientconfiguratie geneest git en ssh samen. Wanneer één clientinstelling meerdere hulpmiddelen tegelijk repareert, zit de fout in wat de client verstuurt, niet in de verbinding waarlangs hij het verstuurt.

Lees het symptoom als een routingverschil

Een tunnel die een probleem geneest, is zelden een reparatie. Hij wisselt de route, de provider en de tussenliggende apparaten om, terwijl de laptop precies dezelfde pakketten blijft maken. Als de ene route een header verkeerd behandelt en een andere hem ongewijzigd doorlaat, zit het verschil in het beleid van het tussenapparaat, niet in de client. De tunnel is hier een getuige, geen oplossing.

Het punt waar de sessie sterft, vernauwt het verder. Niets dat misgaat bij naamopzoeking of bij sleuteluitwisseling ziet er zo uit. Een sessie die authenticeert, een banner afdrukt en dan bevriest bij de eerste grote schrijfactie, heeft al bewezen dat routing, namen en inloggegevens allemaal werken.

De client stempelt een QoS-byte op elke SSH-socket

Elke OpenSSH-verbinding vanaf 7.8 draagt in de IP-header een waarde die routers mogen gebruiken om verkeer prioriteit te geven. Terminalsessies krijgen de ene waarde en bulkkopieën een andere, op de theorie dat een mens die typt een betere behandeling verdient dan een bestandsoverdracht. De meeste netwerken negeren de hint volledig, waardoor hij jarenlang onopgemerkt blijft. Een minderheid van wifi-stuurprogramma's, mobiele providers en VPN-concentrators handelt ernaar, en sommigen doen dat slecht.

Wanneer die waarde midden in de stroom wordt herschreven of weggegooid, faalt de verbinding niet, maar komt hij niet verder. Herverzendingen stijgen, het venster stort in, en de toepassing meldt niets omdat niets een fout gaf. Die stilte is de reden dat mensen het symptoom als een hang beschrijven en niet als een storing.

Controleer eerst de clientversie met ssh -V. Alles op 7.8 of hoger draagt dit gedrag standaard.

Drie commando's die dit van MTU en DNS scheiden

Twee vergelijkbare oorzaken moeten worden uitgesloten voordat u een configuratiebestand aanpast. Een MTU-fout laat kleine uitwisselingen door en bevriest bij het eerste grote pakket, terwijl een naamfout nooit een sessie oplevert.

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

Het eerste commando herhaalt de mislukkende bewerking met de markering uitgeschakeld, en een geslaagde uitvoering is het sterkste afzonderlijke bewijs dat er is. Het tweede drukt de configuratie af die de client werkelijk op die bestemming gaat toepassen, wat een verouderde regel in een vergeten bestand vangt. Het derde toont de TOS-byte in beide richtingen terwijl de overdracht vastzit, en het interessante patroon is een waarde op de kapotte route en geen op de werkende.

Maak de opname op de laptop en niet op de server, omdat de afzender de waarde zet en beide richtingen die kunnen veranderen. Vergelijk een werkende en een mislukkende route met dezelfde opname, en het verschil verschijnt zonder giswerk.

Zet de uitzondering in één bestand, één host per keer

Een uitzondering hoort naast de host waarop zij van toepassing is, met een opmerking die zegt waarom zij bestaat.

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

De reikwijdte is belangrijker dan de waarde zelf. Een jokertekenregel schakelt het gedrag overal uit, gooit een hint weg die helpt op goed presterende netwerken, en laat niemand kunnen zeggen wanneer zij verscheen. Een regel per host is leesbaar, omkeerbaar en triviaal te verwijderen zodra het netwerk is hersteld. Gebruik het gebruikersbestand voor een persoonlijke omweg en een beheerd bestand wanneer een hele vloot dezelfde uitzondering nodig heeft.

Wees expliciet over wat de uitzondering niet dekt. Zij geldt voor SSH, dus een HTTPS-remote, een pakketspiegel en een browser vallen er allemaal buiten, en een fout in een daarvan vereist zijn eigen bewijs. Op een keten via een bastion gebruikt elke sprong de clientconfiguratie, en de sprong die blijft hangen is degene die het waard is af te bakenen.

Sluit de cirkel met de netwerkeigenaar

Draag de vondst over als vier feiten: clientversie, geteste route, gebruikte VPN-client en welke richting de markering droeg. Die vier zijn genoeg voor een netwerkeigenaar om de behandeling te reproduceren en te beslissen of zij opzettelijk is.

Als de uitzondering de hang niet geneest, verwijder haar. Een omweg die een mislukt experiment overleeft, wordt folklore, en de volgende persoon besteedt een uur aan het bewijzen dat zij niets doet. Als zij de hang wel geneest, is het pad nog steeds verkeerd voor elk ander hulpmiddel dat het kruist, en de reparatie hoort bij wie het tussenapparaat beheert.

De wijziging op de client is een noodoplossing met een houdbaarheidsdatum. Schrijf die datum in de opmerking.