MTU սև խոռոչը՝ ինչու փոքր հարցումները աշխատում են, իսկ վերբեռնումները կանգնում
Փոքր հարցումները ավարտվում են, մինչ մեծ վերբեռնումը կախված է մնում ընդմիշտ, և ուղարկողը երբեք չի իմանում, որ ուղին ավելի նեղ է։ Չափեք այն ճշգրիտ չափը, որտեղ այն կոտրվում է։
Էջը բեռնվում է, փոքր API կանչը վերադառնում է, և հետո ֆայլի վերբեռնումը կախված է մնում, մինչև հաճախորդը հանձնվի։ Սերվերի մատյանում ոչինչ չի բացատրում դա, քանի որ փաթեթները թափվել են ուղու մեջտեղում՝ առանց օգտակար պատասխան հետ ուղարկելու։ Այդ օրինաչափությունը MTU սև խոռոչ է՝ ուղարկողի ենթադրածից ավելի նեղ կապ, գումարած լուռ հրաժարում դա ասելուց։ Ձախողվող չափը կրկնելի է, և հենց դա է այն դարձնում ախտորոշելի։
Ինչն է խոռոչը սև դարձնում
Յուրաքանչյուր կապ ունի առավելագույն փոխանցման միավոր, և հաջորդ թռիչքի սահմանից մեծ փաթեթը կա՛մ պետք է մասնատվի, կա՛մ մերժվի դա ասող ICMP հաղորդագրությամբ։ Ուղու MTU հայտնաբերումը կախված է նրանից, որ այդ հաղորդագրությունը հասնի և հարգվի։ Այն զտելը կամ անտեսելը ուղարկողին թողնում է կրկնել փաթեթ, որն երբեք չի տեղավորվի։
Ինկապսուլյացիան դա սովորական է դարձնում VPN-ների շուրջ, քանի որ թունելը արտաքին վերնագիր է ավելացնում այն փաթեթին, որն արդեն չափված էր ֆիզիկական կապի համար։ Ներքին փաթեթը օրինական է 1500 բայթում, իսկ ինկապսուլացվածը՝ ոչ, ուստի այն մահանում է սահմանին, մինչ փոքր փաթեթները սահում են անցնում։ Ավարտված ձեռքսեղմումը և աշխատող մուտքի էջը միայն ապացուցում են, որ փոքր փաթեթներն աշխատում են։ Ամենամեծ փաթեթը, որը հավելվածը փորձում է ուղարկել, այն է, ինչը նշանակություն ունի։
Գտեք այն չափը, որտեղ այն կոտրվում է
Երկուական որոնումով գտեք բեռնվածքի չափը առանց մասնատման թեստով, թունելի մի կողմի հոսթից մյուս կողմի հոսթ։ Ամենամեծ բեռնվածքը, որն անցնում է, ձեր օգտագործելի ուղու MTU-ն է հանած վերնագրի ծախսը։
ping -M do -s 1400 -c 2 192.0.2.20
ping -M do -s 1200 -c 2 192.0.2.20
ping -f -l 1372 192.0.2.201472 բայթ բեռնվածքն անցնում է մաքուր 1500 բայթ Ethernet ուղով, երբ ավելացվում են IPv4-ի և ICMP-ի վերնագրերի 28 բայթերը։ Երբ նույն թեստը թունելը բարձրանալուց հետո հաջողվում է միայն ավելի փոքր բեռնվածքի դեպքում, տարբերությունը ինկապսուլյացիայի ծախսն է, և թունելի սահմանն այն տեղն է, որտեղ պետք է ստեղծվեր մերժման հաղորդագրությունը։ Գրանցեք երկու թվերը՝ միանալուց առաջ և հետո, քանի որ այդ զույգն է ապացույցը։ Կրկնեք թեստը IPv6-ի համար, երբ հավելվածն օգտագործում է այն, քանի որ վերնագիրն ավելի մեծ է, և ձախողման շեմը տեղաշարժվում է։
Կարդացեք ապացույցները, նախքան թունելին մեղադրելը
Հեռավոր հավելվածների սխալները, գերբեռնվածությունը և սովորական կորուստը նույնպես կանգնեցնում են վերբեռնումները, ուստի մեկ ձախողված փոխանցումը սև խոռոչ չի նույնացնում։ Դրանք բաժանում է չափերի հարաբերությունը՝ կրկնելի հաջողություն 1200 բայթում և կրկնելի կանգ 1400 բայթում, նույն ուղղությամբ, նույն վերջնակետով։
Երկու ծայրերում գրավումը ցույց է տալիս, որ մեծ փաթեթները դուրս են գալիս և երբեք չեն հասնում, առանց միջև մերժման։ Դա այն պահն է, երբ պետք է նայել սահմանային սարքին, այլ ոչ սերվերին, որը պատասխանում է իրականում ստացած յուրաքանչյուր հարցման։ Գերբեռնվածությունը նույնպես կանգնեցնում է, բայց տարբեր չափեր կանգնեցնում է տարբեր ժամանակներում, և դա այլ ստորագրություն է։
Ստուգեք վերանորոգումը երկու տրանսպորտում
Աջակցվող վերանորոգումն այն է, որ սահմանը հաղորդի իրական սահմանը, կամ այնտեղ սահմանափակվի TCP-ի առավելագույն սեգմենտի չափը, որպեսզի չափից մեծ սեգմենտ չփորձվի։ Ցանցի յուրաքանչյուր MTU-ի իջեցումը կամ firewall-ի անջատումը թաքցնում է ախտանիշը և թողնում կարգավորում, որի մասին ոչ ոք հետագայում չի կարողանա դատել։
ip link show dev tun0
sudo nft list ruleset | grep -i -E 'mtu|mss'
sysctl net.ipv4.tcp_mtu_probing
ping -M do -s 1400 -c 2 192.0.2.20Ստուգեք նույն չափի թեստով, ապա այն հավելվածով, որը ձախողվեց, և ստուգեք երկրորդ արձանագրություն, քանի որ UDP հավելվածները երբեք չեն ստանում TCP-ի սեգմենտի չափի ուղղումը։ Պահեք սկզբնական արժեքները տոմսում, քանի որ չշրջվող վերանորոգումը երկրորդ խնդիր է, որը սպասում է տեղի ունենալուն։ Եթե չափի թեստը անցնում է, և վերբեռնումը դեռ կանգնում է, ապա սև խոռոչը պատճառը չէր, և հետաքննությունը պետք է շարունակվի՝ փոփոխությունը չընդլայնելով։