SSH inakwama kwenye SSH2_MSG_KEX_ECDH_REPLY: si kila wakati ni MTU

Mtandao wa siri unafanya kazi, bango hufika, na mteja huchapisha ujumbe kuhusu kusubiri jibu la ubadilishanaji wa funguo. Matokeo ya utafutaji huelekeza moja kwa moja kwenye MTU, na wakati mwingine hiyo ni kweli. Mara nyingi sivyo: jibu huenda halikutumwa kamwe, kwa sababu mteja hakuweza kusoma faili ya ufunguo au pande mbili hazikukubaliana kamwe kuhusu algoriti. Mstari unaeleza anachosubiri mteja, si kwa nini kusubiri kulianza. Ichukulie kama dalili na tenganisha sababu tatu kabla ya kubadilisha ukubwa wowote.

Soma ufuatiliaji ili kuona kama jibu lilitarajiwa hata kidogo

Matokeo ya kina yanaonyesha hatua ya mwisho iliyofanikiwa kabla ya ukimya. Ikiwa bango la itifaki la seva limefika, TCP inafanya kazi na upande wa mbali uko hai; swali lililo wazi ni nini kilitokea kwa pakiti moja mahususi. Dakika moja ya ukimya baada ya bango inaonekana kama tatizo la njia. Ujumbe kuhusu hakuna njia ya ubadilishanaji wa funguo inayolingana ni tatizo la sera. Kusubiri kwa muda mrefu kunakoishia seva ikifunga kipindi humaanisha seva ilikata tamaa, na kumbukumbu yake inaeleza kwa nini.

Katika kisa cha mwisho, soma kumbukumbu ya uthibitishaji ya seva kabla ya kugusa mteja. Mteja hawezi kuona uamuzi ambao seva haikutuma kamwe.

Kwa nini jibu dogo bado linaweza kuwa kubwa mno

Majibu ya ubadilishanaji wa funguo kwa kawaida ni madogo sana, kwa hivyo kulaumu ukubwa kunasikika vibaya. Pamoja na vyeti vya mwenyeji jibu si dogo, kwa sababu hubeba mnyororo wa vyeti wa seva. Hilo huifanya kuwa pakiti ya kwanza katika kipindi inayoweza kuzidi mzigo unaoweza kutumika wa mtandao wa siri. Urejeshaji wa taarifa wa ugunduzi wa MTU ya njia unapopotea mahali fulani njiani, mtumaji huendelea kutuma tena pakiti isiyoweza kuingia, na mteja husubiri milele kwenye mstari huo.

Bainisha ukubwa badala ya kuudhania. Soma MTU ya mtandao wa siri kwa ip link show tun0, kisha tuma uchunguzi ambao haupaswi kugawanywa: ping -4 -M do -s 1352 host, ukirudiwa kwa mizigo midogo. Mabadiliko kutoka kushindwa hadi kufanikiwa kwa ukubwa mahususi ni ushahidi; kushindwa kwa usawa kunaonyesha ICMP inachujwa na hakukuambii chochote.

Upunguzaji wa muda huthibitisha nadharia haraka, na toleo la kudumu liko kwenye wasifu au kama kikomo cha MSS kwenye kipanga njia kinachopeleka mtandao wa siri:

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

Sababu mbili zinazoiga tatizo la ukubwa

Faili ya ufunguo ambayo mteja hawezi kusoma huzalisha kusubiri kulekule, bila onyo hata kwenye matokeo ya kina. Mchoro mmoja wa known_hosts hurahisisha hili: ingizo la @cert-authority linaloelekeza kwenye ufunguo wa umma wa CA ambao akaunti moja tu inaweza kuusoma. Akaunti inayomiliki faili huunganisha, na kila akaunti nyingine hukwama. Ikiwa hitilafu inamfuata mtumiaji badala ya mwenyeji, angalia modi za faili kabla ya ukubwa wa pakiti.

Sasisho pia linaweza kuondoa algoriti ambayo pande zote mbili ziliishirikisha hapo awali. Bandika njia moja ambayo seva bado inaitoa kama uchunguzi: ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host. Muunganisho unaofanikiwa mara moja unathibitisha njia ni sawa na marekebisho yako kwenye sera ya mazungumzo ya pande zote mbili.

Mambo matatu yanayofaa kuandikwa

Andika MTU ya mtandao wa siri kabla na baada ya mabadiliko yoyote, kama kunakili faili kubwa kunashindwa kwa ukubwa unaorudiwa, na kama mwenyeji asiye na cheti kwenye mtandao huo huo hukwama vivyo hivyo. Uchunguzi huo matatu hutenganisha ukubwa na ruhusa na mazungumzo kwa haraka zaidi kuliko rundo la amri.

Pia huwazuia watu wanaofuata kupunguza MTU kwa sababu ya hitilafu ambayo haikuhusiana kamwe na ukubwa.

Ikiwa picha bado haiko wazi, jaribu kutoka kwa mteja wa pili kwenye mtandao huo huo. Mteja anayeunganisha huhamisha hitilafu kutoka njia hadi usanidi wa mashine ya kwanza.