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

Սկսեք ձախողման ձևից

Չափի ձախողումն ունի ստորագրություն․ կապը հաստատվում է, նույնականացումը և փոքր պատասխանները հաջողվում են, ապա փոխանցումը դադարում է անորոշ ժամանակով, հենց որ լրիվ չափի հատված է պետք։ Էջերը, որոնք բեռնում են տեքստը, բայց երբեք չեն ավարտում նկարը, նույն ձախողումն են ավելի փոքր մասշտաբով։ Եթե ընդհանրապես ոչինչ չի միանում, խնդիրը ուղու վրա ավելի վաղ է, և սահմանափակումը չի օգնի։ Սահմանափակումը չի կարող վերականգնել այն ձեռքսեղմումը, որը երբեք չի հասել։

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

Այս ախտանիշը կարդալիս տրանսպորտը պահեք տեսադաշտում։ Սահմանափակումը TCP ընտրանքի վերագրում է, ուստի նույն թունելի տակ կանգնող ձայնային կամ վիդեո զանգը MSS-ի խնդիր չէ և դրանից չի բարելավվի։ Գրի առեք տրանսպորտը, նախքան TCP ընտրանքին դիպչելը։

Գնահատեք ուղին, ապա համեմատեք թունելի հետ

Երկու թիվ կարևոր են, և դրանք հաճախ շփոթում են։ path-MTU-ն ամենամեծ փաթեթն է, որ ուղին կտանի առանց մասնատման, իսկ IPv4-ի համար հայտարարված MSS-ը այդ արժեքն է հանած IP և TCP վերնագրերի 40 բայթը, կամ հանած 60-ը IPv6-ի համար։ Թունելի ինկապսուլյացիան ծախսում է բյուջեի մի մասը դեռ ներքին փաթեթը չսկսած։

ping -M do -s 1400 198.51.100.20
tracepath 198.51.100.20

do-not-fragment բիթով ping-ը ձեզ ասում է՝ այդ ծանրաբեռնվածության չափի փաթեթը գոյատևում է, թե ոչ․ փոխեք չափը, մինչև այն ձախողվի, և դուք էմպիրիկորեն գտել եք ուղու սահմանը։ tracepath-ի ելքը հաղորդում է երթուղու երկայնքով հայտնաբերված MTU-ն, ինչն ավելի արագ է, երբ աշխատում է, և ավելի քիչ հուսալի, երբ միջանկյալ hop-ը զտում է զոնդերը։

Այժմ հանեք թունելի ծախսը։ Արտաքին IP վերնագիր, UDP վերնագիր և թունելին բնորոշ վերնագիր բոլորը գալիս են նույն 1500 բայթից, ուստի տիպիկ Ethernet հիմքի վրա օգտագործելի ներքին MTU-ն ավելի ցածր է, քան ֆիզիկական կապն է հուշում։ Եթե հաշվարկված ներքին MTU-ն ցածր է ձեր զուգընկերների հայտարարածից, դուք գտել եք իրական սահմանափակման թեկնածու, ոչ թե գուշակություն։ Եթե հաշվարկված արժեքն արդեն բարձր է զուգընկերների հայտարարությունից, կանգ առեք այստեղ և նայեք այլ տեղ։

Տեղադրեք սահմանափակումը այնտեղ, որտեղ անցնում է ձեռքսեղմումը

Սահմանափակումն աշխատում է վերագրելով MSS ընտրանքը SYN և SYN-ACK փաթեթներում, երբ նրանք անցնում են դարպասով։ Եթե կանոնը նստում է այնպիսի ինտերֆեյսի վրա, որը ոչ մի ուղղություն երբեք չի անցնում, բանակցությունը ավարտվում է անփոփոխ, և ախտանիշը մնում է, այդ պատճառով տեղադրումը արդյունքը որոշում է ավելի, քան արժեքը։

SymptomWhat it points toNext check
Handshake completes, large transfer stallsSegment size larger than the path can carryPath MTU against the tunnel's effective MTU
Nothing connects, small or largeRouting, firewall or keying failureNot MSS; look at the tunnel state
Only UDP applications stallDatagram size or a dropped ICMP errorPlatform-specific UDP handling, not clamping
Fixed after reconnect, returns laterClamp applied to one direction or one interfaceRule placement and the handshake path

Ուղղությունը մյուս կեսն է։ Մեկ ուղղության սահմանափակումը շտկում է հոսքերի կեսը և մնացածին թողնում է ձախողվել այնպես, որ ընդհատվող է թվում, ուստի կիրառեք այն փոխանցվող երթևեկության երկու ուղղություններին էլ։ Թունելային ինտերֆեյսի դասական Linux ձևը mangle կանոնն է, որը համապատասխանում է SYN փաթեթներին․

iptables -t mangle -A FORWARD -o tun0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Ուշադրություն դարձրեք, թե --clamp-mss-to-pmtu իրականում ինչ է անում․ այն արժեքը բխեցնում է երթուղու MTU-ից, ինչը միշտ չէ թունելի իրական օգտակար բեռնվածքի բյուջեն։ Երթուղու վրա հիմնված թունելում, որտեղ ներքին երթուղին և արտաքին ուղին տարբերվում են, նախորդ ստուգման մեջ հաշվարկված բացահայտ արժեքն ավելի կանխատեսելի է, քան ինքնաշխատը։

Ստուգեք նոր կապով և կենդանի պահեք հետադարձ կապը

Հաստատված կապը պահում է այն MSS-ը, որի շուրջ բանակցել է, ուստի նույն սեսիայում փորձարկելը ոչինչ չի ապացուցում։ Փոփոխությունից հետո բացեք նոր կապ և կարդացեք բանակցված արժեքը ուղղակիորեն՝ պատահաբար ավարտվող փոխանցումից այն ենթադրելու փոխարեն։

ss -tin dst 198.51.100.20
iptables -t mangle -S | grep TCPMSS

Առաջին հրամանը հաղորդում է socket-ի MSS-ը իր գերբեռնվածության վիճակի հետ միասին, ինչը սահմանափակումն ուժի մեջ մտնելու ամենաարագ հաստատումն է։ Երկրորդը հաստատում է, որ այն կանոնը, որ դուք կարծում եք ավելացրել եք, այն կանոնն է, որ գոյություն ունի, այն աղյուսակում, որտեղ տեղադրվել է։

Ապա պաշտպանեք այն մեխանիզմը, որը չեք ուղղել։ path-MTU հայտնաբերումը կախված է նրանից, որ ICMP fragmentation-needed հաղորդագրությունները հասնեն ուղարկողին, ուստի դրանք գցող firewall-ը կշարունակի կոտրել մեծ փոխանցումները նույնիսկ ճիշտ սահմանափակման դեպքում։ Թույլատրեք այդ հաղորդագրությունները թունելի ուղու համար, կամ ընդունեք, որ սահմանափակումը փոխհատուցում է ձեր ընտրած քաղաքականությունը։

Վերջում դիմադրեք սահմանափակումը որպես կարգավորման պտուտակ դիտելու գայթակղությանը։ Այն սահմանափակում է հատվածի չափը, ինչը թողունակության արժեք ունի այն ուղիների վրա, որոնք երբեք դրա կարիքը չեն ունեցել։ Երեք ստուգումներից հետո կիրառված՝ այն նպատակային վերանորոգում է․ առաջինը կիրառված՝ փոփոխություն է, որը թաքցնում է սկզբնական խափանումը և երկրորդ փոփոխական ավելացնում յուրաքանչյուր հետագա փորձարկմանը։ Այդ փոխանակումն արժե գիտակցաբար անել, ոչ լռելյայն։

Գրի առեք ձեր չափած path-MTU-ն, հանած թունելի ծախսը, ավելացված կանոնը և դրանից հետո տեսած MSS-ը։ Չորս թիվ հաջորդ միջադեպը դարձնում են որոնում՝ հետաքննության փոխարեն։

Առնչվող հոդվածներ