SSH takerdub SSH2_MSG_KEX_ECDH_REPLY juures: alati pole süüdi MTU

Tunnel töötab, bänner jõuab kohale ja klient trükib teate, et ootab võtmevahetuse vastust. Otsingutulemused osutavad otse MTU-le ja mõnikord on see õige. Tihti pole: vastus võib olla saatmata jäänud, sest klient ei saanud võtmefaili lugeda või pooled ei jõudnud algoritmis kokkuleppele. Rida kirjeldab, mida klient ootab, mitte miks ootamine algas. Käsitlege seda sümptomina ja eristage kolm põhjust enne mis tahes suuruse muutmist.

Lugege jälge, et näha, kas vastust üldse oodati

Üksikasjalik väljund näitab viimast õnnestunud sammu enne vaikust. Kui serveri protokollibänner on kohale jõudnud, töötab TCP ja kaugpool on elus; lahtine küsimus on, mis juhtus ühe konkreetse paketiga. Minut vaikust pärast bännerit näeb välja nagu tee probleem. Teade sobiva võtmevahetusmeetodi puudumise kohta on poliitika probleem. Pikk ootamine, mis lõpeb serveri poolt sessiooni sulgemisega, tähendab, et server andis alla, ja selle logi selgitab, miks.

Viimasel juhul lugege serveri autentimislogi enne, kui klienti puudutate. Klient ei näe otsust, mida server kunagi ei saatnud.

Miks väike vastus võib siiski liiga suur olla

Võtmevahetuse vastused on tavaliselt tillukesed, seega suuruse süüdistamine kõlab valesti. Hostisertifikaatidega ei ole vastus tilluke, sest see kannab serveri sertifikaadiahelat. See teeb sellest sessiooni esimese paketi, mis võib ületada tunneli kasutatava kandevõime. Kui tee-MTU avastamise tagasiside kaob kuskil marsruudil, saadab saatja ikka ja jälle paketti, mis ei mahu, ja klient ootab igavesti samal real.

Tehke suurus kindlaks, mitte ärge oletage seda. Lugege tunneli MTU-d käsuga ip link show tun0, seejärel saatke proove, mida ei tohi fragmenteerida: ping -4 -M do -s 1352 host, korratuna väiksemate koormustega. Muutus ebaõnnestumisest õnnestumiseks kindlal suurusel on tõend; ühtlane ebaõnnestumine viitab sellele, et ICMP on filtreeritud, ega ütle teile midagi.

Ajutine vähendamine kinnitab teooriat kiiresti, ja püsiv versioon kuulub profiili või MSS-piiranguna marsruuterile, mis tunnelit edasi saadab:

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

Kaks põhjust, mis jäljendavad suuruse probleemi

Võtmefail, mida klient ei saa lugeda, tekitab sama ootamise, hoiatamata isegi üksikasjalikus väljundis. Üks known_hosts muster teeb selle lihtsaks: @cert-authority kirje, mis osutab CA avalikule võtmele, mida saab lugeda ainult üks konto. Faili omav konto ühendub ja iga teine konto takerdub. Kui tõrge järgib kasutajat, mitte hosti, kontrollige failiõigusi enne paketi suurusi.

Uuendus võib ka eemaldada algoritmi, mida mõlemad pooled varem jagasid. Kinnitage üks meetod, mida server veel pakub, diagnostikaks: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. Ühendus, mis kohe õnnestub, tõestab, et tee on korras, ja parandus kuulub mõlema poole läbirääkimispoliitikasse.

Kolm fakti, mida tasub üles kirjutada

Kirjutage üles tunneli MTU enne ja pärast mis tahes muudatust, kas suure faili kopeerimine ebaõnnestub korrataval suurusel ja kas sama tunneli sertifikaadita host takerdub samamoodi. Need kolm tähelepanekut eristavad suurust õigustest ja läbirääkimistest kiiremini kui hunnik käske.

Need takistavad ka järgmisel inimesel MTU langetamist rikke tõttu, mis ei olnud kunagi suuruse kohta.

Kui pilt on endiselt ebaselge, proovige sama tunneli teisest kliendist. Ühenduv klient viib rikke teelt esimese masina konfiguratsiooni.