OpenVPN-ը PPPoE-ում. link-mtu, tun-mtu կամ mssfix նվազեցնելու ընտրությունը
Ping-ը աշխատում է, բայց մեծ էջերը կախվում են PPPoE կամ DS-Lite կապում։ Որոշեք link-mtu, tun-mtu և mssfix-ի միջև՝ չափելով ուղին, ոչ թե գուշակելով։
Ping-երը պատասխանում են, DNS-ը լուծում է, և յուրաքանչյուր էջ, որը լրիվ չափի սեգմենտի կարիք ունի, կախվում է։ Այն կապում, որն ավելացնում է իր սեփական ինկապսուլյացիան, ուղին լուռ կորցնում է մի քանի տասնյակ բայթ բյուջեից, և մաքուր Ethernet-ի համար գրված պրոֆիլը շարունակում է պահանջել փաթեթներ, որոնք գիծը չի կարող տանել։ Կապը դանդաղ չէ՝ այն դեն է նետում հենց այն փաթեթները, որոնք կարևոր են։
Երեք տարբերակ կարող են շտկել սա, և դրանք աշխատում են տարբեր շերտերում։ Սխալը ընտրելը կամ ոչինչ չի անում, կամ թունելը նոր ձևով փխրուն է դարձնում, ուստի ընտրությունը սկսվում է նրանից, ինչ ուղին իրականում աջակցում է։
Երեք կարգավորիչ, երեք տարբեր շերտ
link-mtu-ն արտաքին բյուջեն է. գաղտնագրված բեռնվածքը գումարած OpenVPN-ի վերնագիրը, UDP-ի վերնագիրը և արտաքին IP վերնագիրը։ Այն նկարագրում է, թե ինչ է դուրս գալիս մեքենայից, և դրա համար է, որ հենց այդ թիվն է սահմանափակում ֆիզիկական ուղին։
tun-mtu-ն ներքին բյուջեն է. այն ինտերֆեյսը, որը տեսնում է ձեր տրաֆիկը։ Այն մեծ է ուղու կրածից ճշգրիտ թունելի ծախսի չափով, և OpenVPN-ը սովորաբար ինքն է այն ածանցում՝ փոխարենը ձեզ ստիպելու այն սահմանել։
mssfix-ը լրիվ այլ մեխանիզմ է։ Այն վերագրում է TCP-ի ձեռքսեղմումների ընթացքում հայտարարվող սեգմենտի առավելագույն չափը, որպեսզի TCP գործընկերներն ընտրեն սեգմենտներ, որոնք տեղավորվում են ինկապսուլյացիայից հետո։ Այն չի փոխում ինտերֆեյսի MTU-ն և ոչ մի ազդեցություն չունի UDP-ի վրա։
Եթե link-mtu-ն բացահայտ սահմանեք, OpenVPN-ը հանում է իր իսկ ծախսը՝ ներքին MTU-ն ածանցելու համար։ Այդ ծախսը հաստատուն չէ. այն կախված է գաղտնագրից և նույնականացումից, դրա համար է, որ ֆորումից պատճենված արժեքը կարող է սխալ լինել այլ պրոֆիլում։ Եթե սահմանեք և՛ link-mtu-ն, և՛ tun-mtu-ն, կլիենտին կտաք երկու հակասական հրահանգ։
Չափեք ուղին՝ նախքան որևէ թիվ ընտրելը
Չափեք ֆիզիկական ինտերֆեյսից, ոչ թե թունելի ներսից, և հիշեք, որ ping-ը հաղորդում է բեռնվածքը, ոչ թե փաթեթի չափը։ Ավելացրեք 28 բայթ IPv4-ի և ICMP-ի վերնագրերի համար, նախքան բեռնվածքը 1500 բայթի շրջանակի հետ համեմատելը, և հիշեք այդ ուղղումը, երբ գործընկերը այլ թիվ հաղորդի։
Linux կլիենտում ping -M do -s 1472-ը արգելում է բեկորատումը և ձախողվում, եթե փաթեթը չափազանց մեծ է։ Նվազեցրեք բեռնվածքը, մինչև այն անցնի, ապա ավելացրեք 28՝ ուղու MTU-ն ստանալու համար։ PPPoE-ն արժե 8 բայթ, ուստի DSL-ում 1492-ը նորմալ է։ DS-Lite-ը և որոշ բջջային ուղիներ արժեն 40 կամ ավելի, և պատասխանը սովորաբար ցածր է, քան անվանական կապի արագությունն է հուշում։
Եթե ping-ի բոլոր չափերը հաջողվում են, բայց մեծ փոխանցումները դեռ կախվում են, կասկածեք սև խոռոչի, այլ ոչ թե պարզ չափի սահմանի։ Պահանջվող բեկորատման մասին ICMP հաղորդագրությունը զտվում է ուղու ինչ-որ տեղ, ուստի ուղարկողը երբեք չի սովորում փոքրացնել, և միայն մեծ սեգմենտ պահանջող հոսքերն են դա նկատում։
Նախ սահմանափակեք TCP-ն, հետո փոքրացրեք թունելը
TCP-ի ձեռքսեղմումներն այն միակ բանն են, որին դիպչում է mssfix-ը, ինչը սովորաբար դարձնում է այն ամենաքիչ խանգարող կառավարումը՝ առաջինը փորձելու համար։ Սահմանեք այն ուղու իրական բյուջեից մի փոքր ցածր, սերվերից ուղարկեք նույն արժեքը, որպեսզի երկու ծայրերը համաձայնեն, և նորից փորձեք մեծ ներբեռնումը։ Եթե կախումը վերանա, խնդիրը TCP սեգմենտի չափն էր, և ուրիշ ոչինչ պետք չէ փոխել։
Նվազեցրեք ներքին MTU-ն, երբ տուժած տրաֆիկը TCP չէ։ UDP ծառայությունը, թունելի ներսում գտնվող թունելը կամ լրիվ չափի դատագրամներ ուղարկող հավելվածը կշարունակի ձախողվել MSS սահմանափակումից հետո, քանի որ ոչինչ չի վերագրում նրա փաթեթի չափը։ Այդ դեպքում նվազեցրեք tun-mtu-ն, կամ սահմանեք link-mtu-ն և թողեք կլիենտը ածանցի ներքին արժեքը, բայց երբեք երկուսն էլ։
Չդիմեք հին բեկորատման տարբերակին։ Այն թունելի ներսում բաժանում էր փաթեթները, ավելացնում ծախս և հնացել է լավ պատճառներով. ժամանակակից OpenVPN-ը ակնկալում է ուղու ճշգրիտ նկարագրություն։
Ինչու փոքր փորձերը շարունակում են աշխատել
DNS հարցումները, ICMP արձագանքները և TCP ձեռքսեղմումները բոլորն էլ շատ ցածր են ձախողվող չափից։ Ուստի թունելը առողջ է թվում յուրաքանչյուր արագ թեստում, մինչդեռ TLS ձեռքսեղմումները և HTTP պատասխանները լուռ ձախողվում են։ Հենց այդ համակցությունը՝ աշխատող traceroute-ը և առաջին մեծ պատասխանին կախվող զննարկիչը, այն նշանն է, որ պետք է փնտրել։ Դիմեք լրիվ չափի փորձի, նախքան նոր պրոֆիլի դիմելը։
Ստուգեք այն տրաֆիկով, որը ձախողվել է։ Բեռնեք մեծ էջ, ուղարկեք լրիվ չափի UDP դատագրամ, եթե հենց այդ ծառայությունն է տուժել, և կրկնեք երկրորդ կլիենտից մեկ այլ կապում։ Գրանցեք չափված ուղու MTU-ն և ձեր ընտրած արժեքը, որովհետև հակառակ դեպքում պրոֆիլին կպչող հաջորդ մարդը թիվը կհամարի կամայական։
Երբ IPv6-ը գործում է թունելով, երբեք ներքին MTU-ն 1280-ից ցածր մի՛ իջեցրեք, որովհետև դա այն նվազագույնն է, որը պետք է կրի յուրաքանչյուր IPv6 կապ։ Ավելի փոքր MTU-ն ուղու մասին փաստ է, ոչ թե կատարողականության կարգավորում, որը լարվում է զգացողությամբ։