SSH-ը կախված է SSH2_MSG_KEX_ECDH_REPLY-ի վրա։ միշտ չէ, որ MTU-ն է

Թունելը միացած է, բանները հասնում է, և հաճախորդը տպում է հաղորդագրություն բանալիների փոխանակման պատասխանին սպասելու մասին։ Որոնման արդյունքները ուղիղ ցույց են տալիս MTU-ին, և երբեմն դա ճիշտ է։ Հաճախ այդպես չէ. պատասխանը գուցե երբեք չի ուղարկվել, որովհետև հաճախորդը չի կարողացել կարդալ բանալու ֆայլ կամ կողմերը երբեք չեն համաձայնել ալգորիթմի շուրջ։ Տողը նկարագրում է, թե ինչին է սպասում հաճախորդը, ոչ թե ինչու սկսվեց սպասումը։ Վերաբերվեք դրան որպես ախտանիշ և առանձնացրեք երեք պատճառները ցանկացած չափ փոխելուց առաջ։

Կարդացեք հետքը՝ տեսնելու, թե արդյոք ընդհանրապես պատասխան էր սպասվում

Մանրամասն ելքը ցույց է տալիս լռությունից առաջ վերջին հաջող քայլը։ Եթե սերվերի արձանագրության բանները հասել է, TCP-ն աշխատում է, և հեռավոր ծայրը կենդանի է. բաց հարցը այն է, թե ինչ պատահեց մեկ կոնկրետ փաթեթի հետ։ Բաններից հետո մեկ րոպե լռությունը նման է ուղու խնդրի։ Համապատասխան բանալիների փոխանակման մեթոդ չլինելու մասին հաղորդագրությունը քաղաքականության խնդիր է։ Երկար սպասումը, որն ավարտվում է սերվերի կողմից նստաշրջանի փակմամբ, նշանակում է, որ սերվերը հանձնվել է, և նրա մատյանը բացատրում է պատճառը։

Վերջին դեպքում կարդացեք սերվերի նույնականացման մատյանը՝ հաճախորդին դիպչելուց առաջ։ Հաճախորդը չի կարող տեսնել որոշում, որը սերվերը երբեք չի ուղարկել։

Ինչու փոքր պատասխանը կարող է դեռ չափազանց մեծ լինել

Բանալիների փոխանակման պատասխանները սովորաբար շատ փոքր են, այնպես որ չափին մեղադրելը սխալ է հնչում։ Հոսթի վկայականների դեպքում պատասխանը փոքր չէ, որովհետև այն կրում է սերվերի վկայականների շղթան։ Դա այն դարձնում է նստաշրջանի առաջին փաթեթը, որը կարող է գերազանցել թունելի օգտագործելի բեռը։ Երբ ուղու MTU-ի հայտնաբերման հետադարձ կապը ինչ-որ տեղ կորչում է երթուղու վրա, ուղարկողը շարունակաբար վերաուղարկում է փաթեթ, որը չի տեղավորվում, և հաճախորդը հավերժ սպասում է նույն տողում։

Որոշեք չափը՝ ենթադրելու փոխարեն։ Կարդացեք թունելի MTU-ն ip link show tun0-ով, ապա ուղարկեք փորձարկումներ, որոնք չպետք է բաժանվեն. ping -4 -M do -s 1352 host՝ կրկնված ավելի փոքր բեռերով։ Որոշակի չափի դեպքում ձախողումից հաջողության անցումը ապացույց է. միատեսակ ձախողումը ենթադրում է, որ ICMP-ն զտվում է, և ձեզ ոչինչ չի ասում։

Ժամանակավոր նվազումը արագ հաստատում է տեսությունը, իսկ մշտական տարբերակը տեղ ունի պրոֆիլում կամ որպես MSS սահմանափակում այն երթուղիչում, որը փոխանցում է թունելը.

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

Երկու պատճառ, որոնք ընդօրինակում են չափի խնդիրը

Բանալու ֆայլը, որը հաճախորդը չի կարող կարդալ, առաջացնում է նույն սպասումը՝ առանց նախազգուշացման նույնիսկ մանրամասն ելքում։ known_hosts-ի մեկ օրինակ դա հեշտացնում է. @cert-authority գրառում, որը ցույց է տալիս CA-ի հանրային բանալուն, որը կարող է կարդալ միայն մեկ հաշիվ։ Ֆայլին տիրապետող հաշիվը միանում է, և մնացած բոլոր հաշիվները կախվում են։ Եթե ձախողումը հետևում է օգտվողին, այլ ոչ թե հոսթին, ստուգեք ֆայլի ռեժիմները փաթեթների չափերից առաջ։

Թարմացումը կարող է նաև հեռացնել ալգորիթմը, որը երկու կողմերը նախկինում կիսում էին։ Ամրացրեք մեկ մեթոդ, որը սերվերը դեռ առաջարկում է, որպես ախտորոշում. ssh -oKexAlgorithms=ecdh-sha2-nistp521 user@host։ Անմիջապես հաջողվող կապը ապացուցում է, որ ուղին լավ է, և ուղղումը պատկանում է երկու կողմերի բանակցային քաղաքականությանը։

Երեք փաստ, որոնք արժե գրի առնել

Գրի առեք թունելի MTU-ն ցանկացած փոփոխությունից առաջ և հետո, արդյոք մեծ ֆայլի պատճենումը ձախողվում է կրկնվող չափի վրա, և արդյոք նույն թունելի վկայական չունեցող հոսթը նույնպես կախվում է։ Այդ երեք դիտարկումները չափը թույլտվություններից և բանակցություններից ավելի արագ են բաժանում, քան հրամանների կույտը։

Դրանք նաև թույլ չեն տալիս հաջորդ մարդուն իջեցնել MTU-ն մի խափանման պատճառով, որը երբեք չափի մասին չի եղել։

Եթե պատկերը դեռ պարզ չէ, փորձարկեք նույն թունելի երկրորդ հաճախորդից։ Միացող հաճախորդը խափանումը ուղուց տեղափոխում է առաջին մեքենայի կարգավորում։