Megakad a Git VPN nélkül? Az OpenSSH IPQoS-szal jelöli a csomagokat

Egy klón az irodából működik, ugyanaz a klón telefonos hotspoton keresztül működik, és ugyanaz a klón egy szállodai hálózatról addig akad, amíg be nem kapcsolnak egy VPN-t. Az SSH kézfogás befejeződik, és a munkamenet elhallgat az első igazi átvitelnél. Az ügyfélkonfigurációhoz adott egyetlen sor egyszerre gyógyítja meg a gitet és az ssh-t. Amikor egyetlen ügyfélbeállítás több eszközt is helyrehoz egyszerre, a hiba abban van, amit az ügyfél küld, nem pedig abban a kapcsolatban, amelyen elküldi.

Olvassa a tünetet útvonal-különbségként

Egy problémát gyógyító alagút ritkán javítás. Kicseréli az útvonalat, a szolgáltatót és a köztes berendezéseket, miközben a laptop pontosan ugyanazokat a csomagokat állítja elő. Ha az egyik útvonal rosszul kezel egy fejlécet, a másik pedig érintetlenül engedi át, a különbség a köztes berendezés szabályzatában van, nem az ügyfélben. Itt az alagút tanú, nem megoldás.

Az a pont, ahol a munkamenet meghal, tovább szűkíti a kört. Semmi, ami a névfeloldásnál vagy a kulcscserénél elbukik, nem így néz ki. Egy munkamenet, amely hitelesít, kiír egy bannert, majd megfagy az első nagy írásnál, már bizonyította, hogy az útvonalkezelés, a névfeloldás és a hitelesítő adatok mind működnek.

Az ügyfél QoS-bájtot üt minden SSH-csatlakozóra

Minden OpenSSH-kapcsolat a 7.8-as verziótól kezdve értéket hordoz az IP-fejlécben, amelyet a routerek a forgalom priorizálására használhatnak. A terminál-munkamenetek egy értéket kapnak, a tömeges másolatok egy másikat, abból a feltevésből, hogy a gépelő ember jobb bánásmódot érdemel, mint egy fájlátvitel. A legtöbb hálózat teljesen figyelmen kívül hagyja a célzást, ezért évekig észrevétlen marad. A Wi-Fi-illesztőprogramok, mobiloperátorok és VPN-koncentrátorok kisebbsége tesz róla, és némelyikük rosszul tesz.

Amikor ezt az értéket a folyam közepén átírják vagy eldobják, a kapcsolat nem szakad meg, hanem megáll a haladásban. Az újraküldések nőnek, az ablak összeomlik, és az alkalmazás semmit nem jelent, mert semmi nem adott hibát. Ez a csend az oka, hogy az emberek a tünetet akadásnak írják le, nem hibának.

Először ellenőrizze az ügyfél verzióját a ssh -V paranccsal. A 7.8-as vagy újabb verziók alapértelmezés szerint hordozzák ezt a viselkedést.

Három parancs, amely elválasztja ezt az MTU-tól és a DNS-től

Két hasonló okot érdemes kizárni, mielőtt bármilyen konfigurációs fájlt szerkesztene. Az MTU-hiba átengedi a kis cseréket, és az első nagy csomagnál fagy meg, míg a névhiba soha nem hoz létre munkamenetet.

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

Az első parancs megismétli a sikertelen műveletet kikapcsolt jelöléssel, és a sikeres lefutása a legerősebb egyedi bizonyíték, ami rendelkezésre áll. A második kiírja azt a konfigurációt, amelyet az ügyfél valóban alkalmazni fog arra a célra, ami elkap egy elavult bejegyzést egy elfelejtett fájlban. A harmadik megmutatja a TOS-bájtot mindkét irányban, miközben az átvitel akad, és az érdekes minta az érték a törött útvonalon, és semmi a működőn.

A laptopon rögzítsen, ne a szerveren, mert a küldő állítja be az értéket, és bármelyik irány megváltoztathatja. Hasonlítson össze egy működő és egy hibás útvonalat ugyanazzal a rögzítéssel, és a különbség találgatás nélkül megjelenik.

Tegye a kivételt egyetlen fájlba, egyszerre egy gazdagépre

A kivétel ahhoz a gazdagéphez tartozik, amelyre vonatkozik, olyan megjegyzéssel, amely megmondja, miért létezik.

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

A hatókör fontosabb magánál az értéknél. A helyettesítő bejegyzés mindenhol kikapcsolja a viselkedést, eldob egy célzást, amely jól viselkedő hálózatokon segít, és senkinek nem hagyja megmondani, mikor jelent meg. A gazdagépenkénti bejegyzés olvasható, visszafordítható, és a hálózat javítása után triviálisan törölhető. Használja a felhasználói fájlt személyes kerülőúthoz, és a kezelt fájlt, amikor egy egész flottának ugyanarra a kivételre van szüksége.

Legyen világos abban, mit nem fed le a kivétel. SSH-ra vonatkozik, így a HTTPS-távoli, a csomagtükör és a böngésző mind kívül esik rajta, és bármelyikük hibája a saját bizonyítékát igényli. Egy bastionon átmenő láncban minden ugrás az ügyfélkonfigurációt használja, és az akadó ugrás az, amelyet érdemes leszűkíteni.

Zárja le a kört a hálózat tulajdonosával

Adja át a leletet négy tényként: ügyfélverzió, tesztelt útvonal, használt VPN-ügyfél, és hogy melyik irány hordozta a jelölést. Ez a négy elég a hálózat tulajdonosának, hogy megismételje a bánásmódot, és eldöntse, szándékos-e.

Ha a kivétel nem gyógyítja meg az akadást, távolítsa el. Egy sikertelen kísérletet túlélő kerülőút folklórrá válik, és a következő ember egy órát tölt azzal, hogy bebizonyítsa, semmit nem tesz. Ha viszont meggyógyítja az akadást, az útvonal még mindig rossz minden más eszköznek, amely áthalad rajta, és a javítás annak a dolga, aki a köztes berendezést üzemelteti.

Az ügyfél módosítása lejárati dátumú kényszermegoldás. Írja be azt a dátumot a megjegyzésbe.