VPN-ի MTU առասպելները. ինչու են ձեր փաթեթները փոքրանում և ուր է գնում տեղը

Ինչ-որ մեկը ձեզ ասում է, որ VPN-ը «փաթեթներ է կորցնում MTU-ի պատճառով», դուք թունելը դնում եք 1400-ի վրա, և փոխանցումը նորից աշխատում է։ Այդ արդյունքը թվում է ախտորոշում։ Սովորաբար դա թվաբանական պատահականություն է՝ դուք ընտրել եք մի թիվ, որը բավական փոքր է, որպեսզի տեղավորվի մի սահմանի տակ, որը երբեք չեք հայտնաբերել, և նույն սահմանին նորից կհանդիպեք հաջորդ ցանցում՝ այլ բյուջեով։

Դրա մեծ մասը պայմանավորված է երկու առասպելով։ Առաջինն այն է, որ թունելի ինտերֆեյսի MTU-ն ուղու MTU-ն է։ Երկրորդն այն է, որ ինկապսուլյացիան արժե «մեկ վերնագիր», իսկ PPPoE-ն ոչինչ չարժե, որ արժե հաշվել։ Երկուսն էլ սխալ են այնպես, որ ձեր ընտրած թիվը թվում է կամայական, մինչդեռ այն իրականում որոշված է։

Առասպել առաջին. թունելի MTU-ն ուղու MTU-ն է

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

Ուղու MTU-ի հայտնաբերումը գոյություն ունի այդ երկուսը հաշտեցնելու համար, և այն կախված է արձագանքից։ IPv4-ում երթուղիչը, որը չի կարող փոխանցել ամբողջական չափի փաթեթ, պետք է ուղարկի ICMP «fragmentation needed» հաղորդագրություն, և ուղարկողը նվազեցնում է իր գնահատականը։ IPv6-ում համարժեքը Packet Too Big հաղորդագրությունն է, և երթուղիչները տրանզիտում ընդհանրապես չեն մասնատում։ Երբ այդ արձագանքը զտվում է, ուղարկողը շարունակում է արտադրել փաթեթներ, որոնք ուղին չի կարող տանել, և ոչինչ նրան չի ասում ինչու։

Առասպել երկրորդ. ինկապսուլյացիան արժե մեկ վերնագիր

Ազնվորեն հաշվեք արտաքին շերտերը։ Արտաքին IP վերնագիրը 20 բայթ է IPv4-ում կամ 40 IPv6-ում։ NAT-ով անցնելու համար UDP ինկապսուլյացիան ավելացնում է 8։ Թունելի արձանագրությունը ավելացնում է իր վերնագիրը, սկզբնավորման վեկտոր կամ nonce, լցոնում մինչև գաղտնագրի բլոկի կամ հավասարեցման սահմանը, վերջավորություն և ամբողջականության ստուգման արժեք։ Կախված արձանագրությունից և գաղտնագրից՝ գումարը հանգիստ տասնյակ բայթերում է, նախքան ներքին փաթեթը նույնիսկ կսկսվի։

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

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

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

Առասպել երրորդ. PPPoE-ն դեռ տալիս է ձեզ մաքուր 1500

Սովորական PPPoE մուտքի կապը չի տեղափոխում 1500 բայթանոց IP փաթեթ։ PPPoE վերնագիրը և PPP արձանագրության դաշտը վերցնում են 8 բայթ Ethernet շրջանակի ներսում, ինչը IP փաթեթին թողնում է 1492։ Սա այն ավանդական սահմանն է, որը նկարագրված է RFC 2516-ում։ Եթե VPN եք աշխատեցնում նման կապի վրա, թունելի ծախսը գալիս է այդ 1492-ից, ոչ թե 1500-ից։

RFC 4638-ը սահմանում է ավելի մեծ PPP բեռի շուրջ բանակցելու եղանակ, երբ և՛ մուտքի կոնցենտրատորը, և՛ հաճախորդի սարքավորումը դա աջակցում են, դրա համար էլ «այս կապը օգտագործում է PPPoE» արտահայտությունն ինքնին չի ապացուցում կոնկրետ թիվ։ Տեղական կարգավորումը չի կարող ստիպել միջանկյալ սարքին ընդունել փաթեթ, որի համար այն երբեք չի կարգավորվել, ուստի օգտակար հարցն այն է, թե ինչի շուրջ կապն իրականում բանակցել է, ոչ թե ինչ է ասում պիտակը։

Ինչու է ձախողումը թվում ընտրովի

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

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

Ինչ փոխել և ինչ հերթականությամբ

Սկսեք ապացույցներից։ Հաստատեք վերը նշված փորձարկումներով, որ անսարքությունը կախված է չափից, ապա գտեք ամենափոքր չափը, որն անցնում է, և ամենամեծը, որ ձախողվում է։ Ստուգեք մուտքի կապի իրական MTU-ն նախքան թունելին մեղադրելը. PPPoE կապը սահմանափակում է բյուջեն նախքան ձեր VPN-ը կդիպչի դրան։ Գրանցեք սկզբնական արժեքները, որպեսզի փոփոխությունը հնարավոր լինի հետարկել։

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