Ճանապարհի MTU-ի հայտնաբերումը VPN-ի միջով՝ չափը և ICMP-ի բացը

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

Ինչ է իրականում չափում ճանապարհի MTU-ն

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

Թունելի համար կարևոր թիվը ներքին MTU-ն է, այսինքն՝ արտաքին ճանապարհի թույլատրելիությունը հանած այն, ինչ ծախսում է ներդիրը։ WireGuard-ը ավելացնում է արտաքին IP վերնագիր և UDP վերնագիր. այլ տրանսպորտներ ավելացնում են իրենցը։ Ներքին չափը չափից բարձր դրեք, և յուրաքանչյուր լրիվ չափի փաթեթի համար բեկորացում կպահանջվի, որը գուցե երբեք չկատարվի։

Ինչու է թունելը փոքրացնում օգտագործելի փաթեթը

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

Գործնական հետևանքը չափ է, որը տեղավորվում է ձեռքսեղմման մեջ, բայց ոչ բեռնվածքի։ TLS ClientHello-ն կամ DNS հարցումը բավական փոքր են, որպեսզի անխաթար անցնեն փոքրացած ճանապարհով, մինչդեռ զանգվածային փոխանցումը՝ ոչ։ Այդ պատճառով ախտանիշները կուտակվում են կոնկրետ գործողությունների շուրջ, ոչ թե կոնկրետ հոսթերի։

Հայտնաբերումն աշխատում է միայն այն ժամանակ, երբ հետադարձ կապը հասնում է

IPv4 հայտնաբերումը հենվում է don't-fragment բիթի վրա. այն երթուղիչը, որը չի կարող փաթեթը փոխանցել, վերադարձնում է ICMP fragmentation-needed՝ հաջորդ ցատկի MTU-ով, և ուղարկողը իջեցնում է իր գնահատումը։ IPv6-ը փոխարենը օգտագործում է Packet Too Big հաղորդագրություններ, որովհետև երթուղիչները տարանցման ընթացքում չեն բեկորացնում։ Երկու մեխանիզմներն էլ ենթադրում են, որ հաղորդագրությունը ճանապարհ կգտնի հետ դեպի ուղարկողը՝ թունելի միջով և վերադարձի ճանապարհի ցանկացած ֆայրվոլից այն կողմ։ Երբ այդ ենթադրությունը ձախողվում է, ուղարկողը շարունակում է նորից ու նորից փորձել մի չափ, որը ճանապարհը չի կարող տանել։

Ֆայրվոլը, որը թույլ է տալիս echo request և echo reply, պարտադիր չէ, որ թույլ տված լինի այդ սխալի տեսակները։ ICMP-ն ընտանիք է, և այստեղ կարևոր անդամները սխալներն են, ոչ թե արձագանքի զույգը։ Ստուգեք կառավարման երթևեկության քաղաքականությունը թունելի երկու ծայրերում և նրանց միջև ընկած ճանապարհին, և հետևեք հարթակի աջակցվող ուղեցույցին՝ ամենուր բոլոր ICMP տեսակները թույլ տալու փոխարեն։

Նույն զտումը կարող է լինել թունելի ներսում։ Եթե ներքին ճանապարհը գցում է սխալը, բայց արտաքինը տանում է այն, ուղարկողը կարող է հարմարվել մի սահմանի, որը ներդրված երթևեկությունը երբեք իրականում չի տեսնում։

Փորձարկեք ճանապարհը՝ թվի գուշակության փոխարեն

Նպատակակետը, մուտքի ցանցը և թունելը թողեք անփոփոխ, ապա փոխեք միայն փաթեթի չափը։ MTU ակնարկով ձախողվող don't-fragment փորձարկումը տալիս է հաջորդ ցատկի սահմանը. կրկնեք, մինչև մի չափ անցնի, և գրանցեք թե չափը, թե հասցեների ընտանիքը։

ping -M do -s 1400 10.60.20.10
ping -M do -s 1300 10.60.20.10
ping -6 -M do -s 1300 2001:db8::10

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

PLPMTUD-ը, որը նկարագրված է RFC 4821-ում, փորձարկում է դեպի վեր և օգտագործում տրանսպորտի հաստատումներ՝ հանձնված սխալներին վստահելու փոխարեն։ Այն օգնում է ICMP-ն զտող ճանապարհների վրա, բայց աջակցությունը տարբերվում է ըստ ստեկի և ըստ հավելվածի։ TCP հոսքը կարող է ինքնուրույն վերականգնվել, մինչդեռ ֆիքսված դատագրամի չափով UDP հավելվածը շարունակում է ձախողվել։

Ընտրեք արժեք և գրանցեք հիմնավորումը

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

IPv4 մեխանիզմը նկարագրված է RFC 1191-ում, իսկ IPv6 փաթեթավորման ուղեցույցը՝ RFC 8201-ում. երկուսն էլ նշելը հետևյալ ինժեներին զերծ է պահում ենթադրությունը նորից ածանցելուց։ Եթե փոխանցումը դեռ կանգ է առնում ձեր ընտրած չափի վրա, դադարեցրեք թիվը իջեցնելը և նայեք հաջորդ շերտին։ Ճանապարհը, որը ձախողվում է ամեն չափի դեպքում, MTU-ի խնդիր չէ։