SSH stringa ties SSH2_MSG_KEX_ECDH_REPLY: tai ne visada MTU

Tunelis veikia, baneris ateina, o klientas išspausdina pranešimą, kad laukia raktų mainų atsakymo. Paieškos rezultatai rodo tiesiai į MTU, ir kartais tai tiesa. Dažnai ne: atsakymas galėjo būti niekada neišsiųstas, nes klientas negalėjo perskaityti rakto failo arba šalys niekada nesusitarė dėl algoritmo. Eilutė aprašo, ko klientas laukia, o ne kodėl laukimas prasidėjo. Traktuokite tai kaip simptomą ir atskirkite tris priežastis prieš keisdami bet kokį dydį.

Perskaitykite pėdsaką, kad pamatytumėte, ar atsakymo apskritai buvo tikimasi

Išsami išvestis rodo paskutinį sėkmingą žingsnį prieš tylą. Jei serverio protokolo baneris atėjo, TCP veikia ir nuotolinis galas gyvas; atviras klausimas yra tai, kas nutiko vienam konkrečiam paketui. Minutė tylos po banerio atrodo kaip kelio problema. Pranešimas apie jokio atitinkančio raktų mainų metodo nebuvimą yra politikos problema. Ilgas laukimas, kuris baigiasi serveriui uždarant sesiją, reiškia, kad serveris pasidavė, o jo žurnalas paaiškina kodėl.

Pastaruoju atveju perskaitykite serverio autentifikavimo žurnalą prieš liesdami klientą. Klientas negali matyti sprendimo, kurio serveris niekada neišsiuntė.

Kodėl mažas atsakymas vis tiek gali būti per didelis

Raktų mainų atsakymai paprastai būna mažyčiai, todėl kaltinti dydį skamba neteisingai. Su prieglobos sertifikatais atsakymas nėra mažytis, nes jis neša serverio sertifikatų grandinę. Tai daro jį pirmuoju sesijos paketu, galinčiu viršyti naudingą tunelio apkrovą. Kai kelio MTU aptikimo grįžtamasis ryšys kažkur maršrute pametamas, siuntėjas nuolat siunčia iš naujo paketą, kuris netelpa, o klientas amžinai laukia toje pačioje eilutėje.

Nustatykite dydį, o ne spėkite. Perskaitykite tunelio MTU su ip link show tun0, tada siųskite zondus, kurių negalima fragmentuoti: ping -4 -M do -s 1352 host, kartokite su mažesnėmis apkrovomis. Pasikeitimas nuo nesėkmės prie sėkmės tam tikrame dydyje yra įrodymas; vienoda nesėkmė rodo, kad ICMP filtruojamas, ir nieko jums nesako.

Laikinas sumažinimas greitai patvirtina teoriją, o ilgalaikė versija priklauso profiliui arba MSS apribojimui maršrutizatoriuje, kuris persiunčia tunelį:

sudo ip link set dev tun0 mtu 1200
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Dvi priežastys, imituojančios dydžio problemą

Rakto failas, kurio klientas negali perskaityti, sukelia tą patį laukimą, be įspėjimo net išsamioje išvestyje. Vienas known_hosts šablonas tai palengvina: @cert-authority įrašas, nukreiptas į CA viešąjį raktą, kurį gali perskaityti tik viena paskyra. Paskyra, kuriai priklauso failas, prisijungia, o visos kitos paskyros stringa. Jei gedimas seka vartotoją, o ne prieglobą, patikrinkite failo režimus prieš paketų dydžius.

Atnaujinimas taip pat gali pašalinti algoritmą, kurį abu galai anksčiau dalijosi. Užfiksuokite vieną metodą, kurį serveris dar siūlo, kaip diagnostiką: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. Ryšys, kuris iškart pavyksta, įrodo, kad kelias tvarkingas, o pataisa priklauso abiejų pusių derybų politikai.

Trys faktai, kuriuos verta užsirašyti

Užrašykite tunelio MTU prieš ir po bet kokio pakeitimo, ar didelio failo kopijavimas nepavyksta pasikartojančiame dydyje ir ar priegloba be sertifikato tame pačiame tunele stringa taip pat. Tie trys stebėjimai atskiria dydį nuo teisių ir nuo derybų greičiau nei komandų krūva.

Jie taip pat neleidžia kitam žmogui sumažinti MTU dėl gedimo, kuris niekada nebuvo susijęs su dydžiu.

Jei vaizdas vis dar neaiškus, išbandykite iš antro kliento tame pačiame tunele. Klientas, kuris prisijungia, perkelia gedimą iš kelio į pirmosios mašinos konfigūraciją.