Jumittuuko Git ilman VPN:ää? OpenSSH merkitsee paketit IPQoS:llä

Klooni toimistosta toimii, sama klooni puhelimen hotspotin kautta toimii, ja sama klooni hotelliverkosta roikkuu, kunnes VPN kytketään päälle. SSH-kättely päättyy ja istunto hiljenee ensimmäisessä todellisessa siirrossa. Yksi asiakasohjelman asetustiedostoon lisätty rivi parantaa gitin ja ssh:n yhdessä. Kun yksi asiakasasetus korjaa useita työkaluja kerralla, vika on siinä, mitä asiakasohjelma lähettää, ei siinä linkissä, jonka kautta se lähettää.

Lue oire reittierona

Ongelman parantava tunneli on harvoin korjaus. Se vaihtaa reitin, operaattorin ja välissä olevat laitteet, kun taas kannettava tuottaa edelleen täsmälleen samoja paketteja. Jos yksi reitti käsittelee otsakkeen väärin ja toinen päästää sen koskemattomana läpi, ero on välilaiteen käytännössä, ei asiakasohjelmassa. Tunneli on tässä todistaja, ei ratkaisu.

Kohta, jossa istunto kuolee, rajaa sitä lisää. Mikään nimihaun tai avainten vaihdon yhteydessä epäonnistuva ei näytä tältä. Istunto, joka todentaa, tulostaa bannerin ja jähmettyy sitten ensimmäisessä suuressa kirjoituksessa, on jo osoittanut, että reititys, nimeäminen ja tunnistetiedot kaikki toimivat.

Asiakasohjelma leimaa jokaiseen SSH-pistokkeeseen QoS-tavun

Jokainen OpenSSH-yhteys versiosta 7.8 alkaen kantaa IP-otsakkeessa arvoa, jota reitittimet voivat käyttää liikenteen priorisointiin. Pääteistunnot saavat yhden arvon ja massakopiot toisen, sillä teorialla, että kirjoittava ihminen ansaitsee parempaa kohtelua kuin tiedostonsiirto. Useimmat verkot jättävät vihjeen täysin huomiotta, ja siksi se jää vuosiksi huomaamatta. Vähemmistö Wi-Fi-ajureista, matkapuhelinoperaattoreista ja VPN-keskuksista toimii sen mukaan, ja jotkut niistä toimivat huonosti.

Kun tämä arvo kirjoitetaan uudelleen tai heitetään pois kesken virran, yhteys ei epäonnistu, se lakkaa edistymästä. Uudelleenlähetykset kasvavat, ikkuna romahtaa, eikä sovellus raportoi mitään, koska mikään ei antanut virhettä. Juuri tämä hiljaisuus saa ihmiset kuvaamaan oireen jumittumisena eikä vikana.

Vahvista ensin asiakasohjelman versio komennolla ssh -V. Kaikki 7.8 tai uudempi kantaa tämän toiminnan oletuksena.

Kolme komentoa, jotka erottavat tämän MTU:sta ja DNS:stä

Kaksi samankaltaista syytä kannattaa sulkea pois ennen minkään asetustiedoston muokkaamista. MTU-vika päästää pienet vaihdot läpi ja jähmettyy ensimmäisessä suuressa paketissa, kun taas nimivika ei koskaan tuota istuntoa.

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

Ensimmäinen komento toistaa epäonnistuvan toiminnon merkintä pois kytkettynä, ja sen onnistunut ajo on vahvin yksittäinen todiste, joka on saatavilla. Toinen tulostaa asetukset, jotka asiakasohjelma todella soveltaa kyseiseen kohteeseen, mikä paljastaa vanhentuneen merkinnän tiedostossa, jonka olit unohtanut. Kolmas näyttää TOS-tavun molempiin suuntiin siirron jumittaessa, ja mielenkiintoinen kuvio on arvo rikkinäisellä reitillä ja ei mitään toimivalla.

Tee kaappaus kannettavalla äläkä palvelimella, koska lähettäjä asettaa arvon ja kumpikin suunta voi muuttaa sitä. Vertaa toimivaa ja epäonnistuvaa reittiä samalla kaappauksella, ja ero näkyy ilman arvailua.

Laita poikkeus yhteen tiedostoon, yksi isäntä kerrallaan

Poikkeus kuuluu sen isännän viereen, jota se koskee, ja kommentti kertoo, miksi se on olemassa.

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

Laajuus merkitsee enemmän kuin itse arvo. Jokerimerkintä kytkee toiminnan pois kaikkialla, heittää pois vihjeen, joka auttaa hyvin käyttäytyvissä verkoissa, eikä jätä kenellekään mahdollisuutta sanoa, milloin se ilmestyi. Isäntäkohtainen merkintä on luettava, palautettava ja triviaalin helppo poistaa, kun verkko on korjattu. Käytä käyttäjätiedostoa henkilökohtaiseen kiertotiehen ja hallittua tiedostoa, kun koko laivasto tarvitsee saman poikkeuksen.

Ole täsmällinen siitä, mitä poikkeus ei kata. Se koskee SSH:ta, joten HTTPS-etävarasto, pakettipeili ja selain jäävät sen ulkopuolelle, ja vika missä tahansa niistä tarvitsee oman todisteensa. Bastionin kautta kulkevassa ketjussa jokainen hyppy käyttää asiakasohjelman asetuksia, ja jumittuva hyppy on se, joka kannattaa rajata.

Sulje kehä verkon omistajan kanssa

Luovuta löydös neljänä tosiasiana: asiakasohjelman versio, testattu reitti, käytössä oleva VPN-asiakasohjelma ja kumpi suunta kantoi merkinnän. Nämä neljä riittävät verkon omistajalle kohtelun toistamiseen ja päättämiseen, onko se tahallista.

Jos poikkeus ei paranna jumittumista, poista se. Kiertotie, joka selviää epäonnistuneesta kokeesta, muuttuu kansanperinteeksi, ja seuraava henkilö viettää tunnin todistaen, ettei se tee mitään. Jos se parantaa jumittumisen, reitti on yhä väärä jokaiselle muulle työkalulle, joka sen ylittää, ja korjaus kuuluu sille, joka ylläpitää välilaitetta.

Asiakasohjelman muutos on hätäratkaisu, jolla on vanhenemispäivä. Kirjoita se päivä kommenttiin.