Ֆիքսված 1,500 բայթ ներքին փաթեթի փոխադրում VPN-ով

Դուք ունեք պահանջ, որը չի ճկվում. հեռավոր կողմը պետք է ստանա այն նույն 1,500 բայթ IP փաթեթը, որը ուղարկում է ուղարկողը, ներառյալ վերնագրերը: Թունելը չի կարող այդ փաթեթը իր սեփական շրջանակման հետ փաթաթել երկրորդ 1,500 բայթ IP փաթեթի մեջ, ուստի դիզայնում ինչ-որ բան պետք է զիջի: Ստորև բերված հերթականությունը այն է, որը ես օգտագործում եմ փոփոխության պատուհանում. գրել բայթերի բյուջեն, ապացուցել, թե ինչ կարող է իրականում կրել ստորին ցանցը, ապա ընտրել ճիշտ մեկ փոխադրման մեխանիզմ և հաստատել ներքին փաթեթը հեռավոր կողմում:

Գրեք բայթերի բյուջեն նախքան պրոֆիլը խմբագրելը

Կապսուլավորումը բայթեր ավելացնում է մի քանի շերտերում, և ընդհանուրը ձեր պրոֆիլի հատկությունն է, ոչ թե հաստատուն, որը կարելի է փնտրել: Հասցեների ընտանիքը, ծածկագրման ընտրությունը, տրանսպորտային արձանագրությունը և ցանկացած սեղմման կամ շրջանակման տարբերակ շարժում են այդ թիվը, դրա համար էլ այլ տեղակայումից պատճենված հանումը որպես բյուջե արժեք չունի: Սկսեք ներքին պահանջից, ավելացրեք ձեր սեփական կոնֆիգուրացիայի չափված փաթեթային ծախսը և ստացված արտաքին չափը գրեք փոփոխության տոմսի վրա, նախքան որևէ մեկը կխմբագրի ֆայլ:

Երկու թիվ որոշում են դիզայնը. ամենամեծ արտաքին փաթեթը, որը ուղին կրում է առանց բաժանման, և լրացուցիչ բայթերը, որոնք անհրաժեշտ են ձեր կապսուլավորմանը: Երբ առաջինը փոքր է երկրորդից գումարած 1,500-ից, նրանցից մեկը պետք է փոխվի: Ընտրությունն այդ ժամանակ նեղ է, ոչ ստեղծագործական, դրա համար ես գրում եմ երկու թվերն էլ նախքան տարբերակները քննարկելը: Թունելի շերտում ոչինչ չի սեղմում այդ բայթերը, և ոչ մի MTU ամբողջ թիվ չի վերացնում ձեզ տրված պահանջը:

Ստուգեք ստորին ցանցը առանց բաժանման ping-երով

Չափեք ուղին, փոխարենը վստահելու ինտերֆեյսի MTU-ին, որովհետև արտաքին ուղու ամենափոքր օղակն է, որ կարևոր է: Linux-ում -M do սահմանում է առանց բաժանման բիթը, իսկ -s վերցնում է ICMP բեռը, ուստի 1,500 բայթ շրջանակը պատասխանում է 1,472 բայթ բեռի դեպքում՝ 20 բայթ IP վերնագիրը և 8 բայթ ICMP վերնագիրը հանելուց հետո: Բարձրացրեք բեռը, մինչև ստուգումը ձախողվի, ապա անցեք jumbo չափի՝ տեսնելու, թե ուղին ընդհանրապես կրում է այն:

ping -M do -s 1472 -c 2 198.51.100.10
ping -M do -s 8972 -c 2 198.51.100.10
tracepath -n 198.51.100.10

Ուղին, որն անցնում է 1,472-ը և ձախողվում 8,972-ի վրա, չի կարող մեկ արտաքին փաթեթում կրել 1,500 բայթ ներքին փաթեթը ծախսերի հետ միասին: Սա այն պատասխանն է, որ ձեզ պետք էր նախքան VPN կոնֆիգուրացիան բացելը: Այն նաև որոշում է, թե հաջորդ երկու բաժիններից որն է ձեզ վերաբերում, ուստի երկու ստուգման արդյունքները պահեք տոմսի կողքին: Այստեղ գուշակելը արժենում է մեկ սպասարկման պատուհան, որովհետև իրեն աշխատող հայտարարող թունելը ոչինչ չի ասում այն ամենամեծ փաթեթի մասին, որը ուղին կընդունի:

Բարձրացրեք ուղու MTU-ն միայն այնտեղ, որտեղ համաձայն է յուրաքանչյուր ցատկ

Jumbo շրջանակները ծայրից ծայր հատկություն են, ոչ թե կարգավորում, որը միացնում եք ձեր վերահսկողության տակ գտնվող երկու ծայրակետերում: Արտաքին ուղու յուրաքանչյուր անջատիչ, երթուղիչ և մատակարարի հանձնման կետ պետք է համաձայնի ավելի մեծ չափին, և մեկ 1,500 բայթ ցատկը լուռ կնետի ձեր հենց նոր մեծացրած փաթեթը: Միայն տեղական ինտերֆեյսը բարձրացնելը դասական կիսափոփոխությունն է, որի պատճառով թունելը կոտրված է երևում, մինչ ստորին ցանցը լուռ կորցնում է:

ip link set dev eth1 mtu 9000
ip link show dev eth1
ping -M do -s 8972 -c 2 198.51.100.10

Փոխեք ինտերֆեյսը, ապա նախքան ուրիշ ինչ-որ բան փոխելը նորից ստուգեք նույն ուղին: Եթե ստուգումը դեռ ձախողվում է, վերադարձրեք ip link set dev eth1 mtu 1500 -ով և անցեք բաժանման, փոխարենը վիճելու մատակարարի հետ ձեզ չպատկանող օղակի շուրջ:

Օգտագործեք թունելի բաժանում, երբ ստորին ցանցը չի կարող աճել

Ներքին փաթեթի տակ աջակցվող բաժանման մեխանիզմը թույլ է տալիս մի քանի արտաքին փաթեթների կրել մեկ ներքին փաթեթ, և հեռավոր թունելի ծայրակետը նորից հավաքում է դրանք նախքան բնօրինակը ստեկին հանձնելը: Community OpenVPN-ի UDP բաժանման տարբերակը այդ գաղափարի իրականացումներից մեկն է, և այն նույնը չէ, ինչ արտաքին փաթեթի սովորական IP բաժանումը: Երկու կողմերն էլ պետք է աշխատացնեն ձևաչափը աջակցող տարբերակ, և տվյալների ուղին պետք է լինի այն, ինչ դուք կարծում եք. OpenVPN 3 հաճախորդները և միջուկում արագացված տվյալների ալիքները տարբեր սահմաններ ունեն, ուստի մի հաճախորդի վրա աշխատող պրոֆիլը կարող է ձախողվել մյուսի վրա:

openvpn --config client.ovpn --tun-mtu 1500 --fragment 1400 --verb 4

Սովորական արտաքին բաժանումը մյուս տարբերակն է, և այն ավելի թույլ է: IPv6 երթուղիչները ընդհանրապես չեն բաժանում փոխանցվող փաթեթը, ուստի չափից մեծ արտաքին փաթեթը պարզապես մահանում է, և ուղարկողը իմանում է դրա մասին միայն այն դեպքում, եթե համապատասխան ICMPv6 հաղորդագրությունը գոյատևի ուղու վրա: Բեկորները նաև հրավիրում են զտում և կորստի ուժեղացում, դրա համար ես դա դիտարկում եմ որպես պահեստային, ոչ թե պլան:

Հոսքի վրա հիմնված արտաքին կրիչը շրջանցում է չափի հարցը՝ սեգմենտավորելով իր սեփական բայթային հոսքը, և վերակառուցված ներքին փաթեթը դեռ կարող է 1,500 բայթ լինել: Դա տրանսպորտի որոշում է՝ իր իսկ ծախսով, ներառյալ TCP-ի հայտնի վարքը TCP-ի ներսում, ուստի ընդունեք այն գիտակցաբար, ոչ թե որպես MTU վեճի կողմնակի ազդեցություն:

Հաստատեք, որ ներքին փաթեթը հասնում է անփոփոխ

Ստուգումը հաջող ձեռքսեղմում չէ: Նկարեք թունելի ինտերֆեյսի վրա երկու ծայրերում և համեմատեք հավելվածի իրականում ուղարկած փաթեթի չափն ու բովանդակությունը հեռավոր կողմի ստացածի հետ:

ip link show dev tun0
ping -M do -s 1472 -c 2 10.8.0.1
tcpdump -ni tun0 -c 5 'icmp and greater 1000'

Եթե նկարումը ցույց է տալիս լրիվ չափի ներքին փաթեթը հեռավոր ծայրում, փոխադրման ընտրությունը աշխատում է, և մնում է գրանցել այն: Եթե այն ոչինչ չի ցույց տալիս, մինչ թունելը հայտարարում է, որ աշխատում է, արտաքին փաթեթը ինչ-որ տեղ ծայրակետերի միջև դեն է նետվում, ինչը ձեզ վերադարձնում է ստուգմանը, ոչ թե ծածկագրման կարգավորումներին:

Տոմսը փակելուց առաջ գրանցեք երեք բան. չափված արտաքին բյուջեն, ընտրված մեխանիզմը և այն հրամանը, որն ապացուցեց, որ ներքին փաթեթը գոյատևել է: Հաջորդ մարդը, ով կդիպչի այս թունելին, կարիք կունենա բոլոր երեքին, և նրանցից ոչ մեկը հնարավոր չէ վերականգնել միայն կոնֿիգուրացիայի ֆայլից: