IPv6 փաթեթը չափազանց մեծ է՝ ինչու են կանգնում մեծ VPN փոխանցումները

Ping-ը աշխատում է, բրաուզերը բացում է փոքր էջ, իսկ ֆայլի փոխանցումը կանգնում է՝ այս ամենը IPv6-ով նույն թունելով։ Այս օրինաչափությունը սովորաբար նշանակում է, որ ուղարկողը երբեք չի իմացել ուղու իրական չափը, այլ ոչ թե թունելը դանդաղ է։ IPv6-ը ակնկալում է, որ երթուղիչները խնդիրը հաղորդեն Packet Too Big հաղորդագրությամբ, իսկ ինկապսուլյացիան ավելացնում է լրացուցիչ ծախս, նախքան փաթեթը կհասնի արտաքին ցանց։ Եթե այդ հաղորդագրությունը զտվի, ուղարկողը շարունակում է կրկնել չափ, որ չի կարող անցնել։

Փոքր հարցումներ, մեծ կանգառներ

Թունելը յուրաքանչյուր փաթեթ փաթաթում է ևս մեկ վերնագրի մեջ, ուստի ներսում օգտագործելի չափն ավելի փոքր է, քան դրսում։ Փաթեթը, որը չափվել էր ֆիզիկական կապի համար մինչև ինկապսուլյացիան, դրանից հետո դառնում է չափազանց մեծ։ IPv4 երթուղիչները կարող են բաժանել ճանապարհին, մինչդեռ IPv6 երթուղիչները դա չեն անում ուղարկողի փոխարեն, ուստի ուղարկողն ինքը պետք է հարմարվի։ Եվ այդ հարմարումը լիովին կախված է հետադարձ կապը ստանալուց։

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

Packet Too Big-ը հետադարձ կապ է, ոչ թե տրաֆիկ

ICMPv6 Packet Too Big հաղորդագրությունը կրում է այն չափը, որը կարող է ընդունել հաջորդ թռիչքը, և ուղարկողն օգտագործում է այն իր գնահատականը իջեցնելու համար։ Այն զտելը համարժեք է ճանապարհային նշանը հանելուն, ապա վարորդներին մեղադրելուն։ Կանոնը, որը դեն է նետում ողջ ICMPv6-ը, խիստ է թվում, բայց կոտրում է ուղու հայտնաբերումը յուրաքանչյուր կապում, որին այն պետք է։ Հաղորդագրությունը ուղու մասին հսկողական տեղեկություն է, ոչ թե հավելվածի բեռ։

Ընտրովի զտումը դեռ խելամիտ է։ Echo հարցումները և հարևանների հայտնաբերումը տարբեր դեր ունեն, քան սխալի հաղորդագրությունները, և քաղաքականությունը կարող է նրանց այլ կերպ վերաբերվել։ Հետևեք հարթակի փաստաթղթավորված զտման ուղեցույցին՝ ամբողջ արձանագրությունը ընդունելու կամ դեն նետելու փոխարեն, քանի որ RFC 8201-ը սահմանում է, թե ինչպես է այդ հետադարձ կապը ղեկավարում հայտնաբերումը։

Փորձարկեք հասցեների երկու ընտանիքներն առանձին

Փորձարկեք IPv6-ը առանձին, քանի որ հաջող IPv4 փոխանցումը ոչինչ չի ապացուցում IPv6 ուղու մասին։ Այնուհետև գրանցեք հսկողական հաղորդագրությունները, մինչ մեծ փոխանցումը կանգնած է։ Երկու գրառումները միասին կամ ցույց են տալիս, որ հետադարձ կապը դուրս է գալիս, կամ ապացուցում են, որ այն երբեք չի հասել։

ping -6 -M do -s 1400 host.internal
ip -6 route get 2001:db8:2::10
sudo tcpdump -ni any 'icmp6 and ip6[40] == 2'

Զոնդն ուղարկում է փաթեթ՝ do-not-fragment բիթը դրված, և հաղորդում այն չափը, որի դեպքում ձախողվում է՝ այն թիվը, որը թունելը պետք է տեղավորի։ Երթուղու հարցումը նշում է այն ինտերֆեյսը, որը կտաներ նպատակակետը, այնպես որ դուք գիտեք, թե որ կապի MTU-ն է գործում։ Գրառումը զտում է ICMPv6 տիպ 2-ը՝ Packet Too Big հաղորդագրությունը, և ցույց է տալիս՝ արդյոք այն ընդհանրապես հասնում է այս հոսթին։ Եթե հաղորդագրությունը երևում է գրառման մեջ, իսկ փոխանցումը դեռ կանգնած է, ուղարկողը անտեսում է այն, ինչը հետազոտությունը տեղափոխում է ցանցից դեպի ստեկ։

Փոխեք թունելի չափը միայն ապացույցներից հետո

Թունելի MTU-ն իջեցնելը կարող է թաքցնել զտված հաղորդագրությունը և վերացնել ախտանիշը՝ յուրաքանչյուր փաթեթի վրա ավելի շատ ծախսի գնով։ Սա շրջանցում է, ոչ ախտորոշում, և պետք է հետևի գրառմանը, ոչ թե փոխարինի այն։ Կամայական ցածր արժեքը նույնպես տեսանելի ոչինչ չի կոտրում, այդ պատճառով էլ տարիներ շարունակ մնում է կարգավորումներում։ Փոխեք այն գիտակցաբար, գրանցեք արժեքը և նշեք, թե որ չափումն է այն արդարացրել։

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