Ջամբո կադրերը VPN ուղին 9000 բայթանոց փաթեթներ կրելու չեն ստիպում

Դուք միացրել եք 9000 բայթանոց կադրերը LAN-ում և սպասում էիք, որ VPN-ը կարագանա։ Այն դանդաղեց, կամ ընդհանրապես դադարեց անցկացնել մեծ փոխանցումներ։ Ջամբո կադրերը տեղական կապի համաձայնություն են, և դրանք չեն ընդարձակում այն ուղին, որը հատում է թունելը։

Օգտագործելի բյուջեն որոշվում է ուղու ամենափոքր սահմանով՝ ներառյալ այն փաթաթումը, որ ավելացնում է թունելը։

Ինչ են իրականում փոխում ջամբո կադրերը

MTU-ն մեկ ինտերֆեյսի հատկություն է։ Այն բարձրացնելը սերվերի և նրա սվիչի վրա նշանակում է, որ այդ երկուսը կարող են ավելի մեծ կադրեր փոխանակել առանց բեկորատման։ Դա ոչինչ չի ասում սվիչից այն կողմ գտնվող երթուղիչի, ISP-ի կամ թունելի մյուս ծայրի մասին։ Այդ սարքերն ունեն իրենց սահմանները, և այն փաթեթը, որ գերազանցում է դրանցից մեկը, դեն է նետվում կամ բեկորատվում է ձեր չսահմանած կանոններով։

Տեղական համաձայնություն, գլոբալ հետևանքներ։ Դա է ամբողջ շփոթությունը։

Փաթաթման հարկը

Թունելը ձեր փաթեթը փաթաթում է մեկ այլի մեջ։ WireGuard-ը IPv4 UDP-ի վրա ավելացնում է մոտավորապես 60 բայթ ավելցուկ՝ OpenVPN-ի UDP ռեժիմը նույն տիրույթում է, իսկ IPsec-ը տարբերվում է ըստ ռեժիմի և ալգորիթմների։ Այդ բայթերը գալիս են արտաքին ուղու բյուջեից, ոչ թե օդից։

Այսպիսով՝ 1500 բայթանոց արտաքին կապը չի կարող կրել 1500 բայթանոց ներքին փաթեթ, երբ ավելացվում է թունելի վերնագիրը։

Թվաբանությունը արժե մեկ անգամ անել։ 1500 բայթանոց ուղու վրա WireGuard ինտերֆեյսն ուզում է մոտ 1420 MTU, որպեսզի փաթաթված փաթեթը տեղավորվի։ Ներքին ինտերֆեյսը դրեք 9000-ի վրա, և յուրաքանչյուր մեծ փաթեթի կպահանջվի բեկորատում, որը թունելը չի կարող կատարել, կամ այն դեն կնետվի։

Գտեք ուղու ամենափոքր կապը

Անցեք երթուղին և գտեք ամենացածր MTU-ն։ LAN-ը սովորաբար 1500 կամ 9000 է, WAN-ը սովորաբար 1500, իսկ բջջային կամ PPP կապը կարող է ավելի ցածր լինել։ Այնուհետև հանեք թունելի ավելցուկը։ Եթե արդյունքը փոքր է ներքին ինտերֆեյսի MTU-ից, ապա ձեր պատասխանը սա է։ Ուղու MTU հայտնաբերումը կարող է դա գտնել ինքնաշխատ, բայց միայն այն դեպքում, երբ թույլատրվում է անցնել այն ICMP հաղորդագրություններին, որոնցից այն կախված է։

Զտված ICMP-ն այն դասական պատճառն է, թե ինչու մեծ փոխանցումը կախվում է, մինչ փոքր հարցումները լավ են աշխատում։

Փորձարկեք չափից կախվածությունը՝ չընդարձակելով փոփոխությունը

Օգտագործեք ներկայացուցչական փոխանցում և պահպանեք սկզբնական արժեքները, որպեսզի կարողանաք վերադարձնել դրանք։ ping -M do -s 1472-ը փորձարկում է 1500 բայթանոց փաթեթ DF բիթով միացված՝ նվազեցրեք չափը, մինչև այն անցնի։ Եթե միայն մեծ փաթեթներն են ձախողվում, ապա խնդիրը չափի է, ոչ թե երթուղման։

Զգուշացեք հոսթի կողմի offload-ից գրավումները կարդալիս։ Սեգմենտացման offload-ը կարող է ցույց տալ շատ ավելի մեծ կադրեր, քան իրականում անցել է լարով, ինչը աշխատող ուղին դարձնում է կոտրված, իսկ կոտրվածը՝ կարգին։

Երբ մեծ MTU-ն ճիշտ ձևավորում է

Վերահսկվող մասնավոր ցանցը կարող է օրինականորեն ծայրից ծայր վարել ավելի մեծ կադրեր, պայմանով, որ ուղու յուրաքանչյուր սարք համաձայն է, և թունելի ավելցուկը հաշվի է առնված։ Դա փաստաթղթավորված արժեքով համակարգված ձևավորում է յուրաքանչյուր կապի համար, ոչ թե մեկ մեծ թիվ, որ մուտքագրված է հաճախորդում։

Սովորական հրապարակային ելքի համար ենթադրեք 1500 կամ ավելի քիչ և թողեք թունելը ընտրի անվտանգ ներքին MTU։ RFC 8201-ը ընդգրկում է ուղու MTU հայտնաբերումը IPv6 դեպքի համար և օգտակար հղում է, թե ինչպես պետք է աշխատի հետադարձ կապը։