IPIP-ը WireGuard-ի ներսում. այն լրացուցիչ 20 բայթը, որը ոչ ոք բյուջեում չէր դրել
IPIP-ը WireGuard-ի ներսում 20 լրացուցիչ բայթ է արժենում։ Բյուջեն արեք ճիշտ շերտում, նախքան կենդանի թունելում կանգնած փոխանցման համար ֆրագմենտացիային մեղադրելը։
Փոքր ping-երը ամբողջ օրը անցնում են թունելով, SSH-ի պաստառը հասնում է, և հետո ֆայլի փոխանցումը սկսելու պահին սեսիան սառչում է։ Այս օրինաչափությունը մատնանշում է սխալ շերտում հաշված բայթային բյուջեի մասին, որտեղ արտաքին թունելը չափվել էր իր իսկ ծախսի համար, և ոչ ոք չէր հանել ներքինը։ Ներդրված IPIP փաթեթը WireGuard-ի համար ուղղակի ևս մեկ IP փաթեթ է, և հենց դրա համար է այն սպառում բայթեր, որոնք դուք երբեք չեք վերապահել։ Ուղղումը թվաբանություն է, և այն տեղավորվում է երեք հրամանում և մեկ աղյուսակում։
Այն ախտանիշը, որը մատնում է այն
Ֆրագմենտացիայի խնդիրը ինքն իրեն հայտարարում է չափով, երբեք հասցեներով։ Ձեր զուգընկերը մեկ ժամ պատասխանում է 56 բայթանոց ping-ին, ապա լռում է 1400 բայթի վրա, մինչ թունելը մնում է բարձրացված, և ոչ մի երթուղի չի փոխվել։ Ձեռքսեղմումը տեղավորվում է, առաջին ամբողջական TCP պատուհանը՝ ոչ, և փոխանցումը կանգ է առնում առողջ երևալուց վայրկյաններ անց։
Չափեք առաստաղը, նախքան որևէ բան խմբագրելը, որովհետև չչափված առաստաղը այն է, որի հետևից կընկնեք երկու անգամ։ Ուղարկեք մեկ զոնդ կասկածելի չափից ցածր՝ do-not-fragment բիթը միացված, ping -M do -s 1000 10.9.0.2, ապա կրկնեք այն չափով, որն արդեն գիտեք, որ շատ մեծ է։ Երբ շրջադարձը հետևում է բեռնվածքի չափին, մինչ նպատակակետը մնում է անփոփոխ, երթուղավորումն անում է իր գործը, և բյուջեից մի վերնագիր բացակայում է։
Հաշվեք յուրաքանչյուր վերնագիր մեկ անգամ, ճիշտ շերտում
Սկսեք ուղու ամենափոքր MTU-ից, ոչ թունելի ինտերֆեյսից, որովհետև պատը գտնվում է երկու ծայրերից վերևում։ WireGuard-ը 60 բայթ է ծախսում IPv4 արտաքին տրանսպորտի վրա՝ 20 IP-ի, 8 UDP-ի և 32 իր իսկ վերնագրի համար, և 80 բայթ, երբ այդ տրանսպորտը IPv6 է։ 1420 բայթանոց wg0-ը պահում է 20 բայթ ազատ տարածք 1440-ից ցածր, որն 1500 բայթանոց ուղին իրոք կարող է հասցնել, և դրա համար վիքիից պատճենված թիվը դեռ տեղավորվում է այստեղ։ Նկարեք ամբողջ կույտը գծապատկերի վրա, որովհետև հաջորդ անգամ MTU-ն փոխողը այլապես նոր կլոր թիվ կընտրի և կժառանգի ձեր սխալը։
| Layer | Bytes | Remaining |
|---|---|---|
| Path MTU on the wired link | none yet | 1500 |
| WireGuard outer: IP, UDP, WG header | 60 | 1440 |
| Slack kept for safety | 20 | 1420 (wg0) |
| IPIP header inside the tunnel | 20 | 1400 (ipip0) |
| Original IPv4 and TCP headers | 40 | 1360 payload |
Հինգերորդ տողն այն տեղն է, որտեղ բյուջեները սխալ են գնում, որովհետև ներդրված ինտերֆեյսի կրած 1400 բայթերն արդեն ներառում են բնօրինակ փաթեթի սեփական 40 բայթ վերնագրերը։ Այդ բայթերից միայն 1360-ն է հասնում ֆայլը կարդացող գործընթացին։ 1400-ը դիտարկեք որպես հավելվածի բեռնվածք, ինչպես ձեզ հրավիրում է այդ սյունակը չունեցող ցանկացած գծապատկեր, և ներքին սարքը հայտնվում է 40 բայթ ավելորդ առատաձեռն չշարժված պատի առաջ։
Սահմանեք երկու MTU-ն առանձին
Կրողը և ներդրված սարքը առանձին օբյեկտներ են, ուստի յուրաքանչյուրին իր արժեքն է պետք։ Կիրառեք դրանք այս հերթականությամբ, որովհետև ներդրված սարքը ոչինչ չի ժառանգում կրողից:
ip link set wg0 mtu 1420
ip tunnel add ipip0 mode ipip remote 203.0.113.9 local 198.51.100.4
ip link set ipip0 mtu 1400Հիշելու արժանի կանոնը՝ ներքին MTU = արտաքին MTU - 20, երբ IPIP թունելի կրած փաթեթը IPv4 է, և - 40, հենց որ ներքին փաթեթի ցանկացած կողմը IPv6 է, որովհետև ներդրված վերնագիրը 20 բայթից աճում է 40-ի։ Այդ հանումից ուրիշ ոչինչ չի մտնում։ WireGuard-ի ծախսն արդեն իսկ կատարվել էր, երբ ընտրեցիք 1420-ը, և այն երկու անգամ գանձելը ստեղծում է թունել, որն անթերի է աշխատում և դանդաղ է մնում, քանի դեռ ոչ ոք չի չափում այն։ Այն տեղադրումը, որտեղ երկու սարքերն էլ կրում են կլոր 1400, հենց այդ սխալի մատնահիշն է։
IPv6-ը ներդրված փաթեթի ցանկացած կողմում վերացնում է վերևի բոլոր թվերը, ուստի վերահաշվեք՝ նմանատիպ կայքից թիվ պատճենելու փոխարեն։ Հանվող վերնագրերը 40 բայթ են յուրաքանչյուրը, հենց որ IPv6-ը հայտնվում է արտաքին ուղում կամ բնօրինակ դեյտագրամում, և բեռնվածքի թիվը նվազում է հենց այդքան։
Այն հրաչապաշտպանի կանոնը, որն, ամենայն հավանականությամբ, ձեզ պետք չէ
Երկու WireGuard զուգընկերների միջև լարի վրա միակ բանը UDP-ն է, ուստի 4 արձանագրության համար մուտքային կանոնը, այն համարը, որ RFC 2003-ը տալիս է IPv4-ը-IPv4-ում փաթաթմանը, ոչ ստեղծում է ներդրված ուղին, ոչ էլ պահում է այն կենդանի։ IPIP-ի վերնագիրը ապրում է գաղտնագրված բեռնվածքի ներսում, որտեղ ոչ մի եզրային հրաչապաշտպան այն չի տեսնում։ 4 արձանագրության բացումն այդուհանդերձ ոչինչ չի գնում, բացի հոսթ մուտքի ևս մեկ թույլատրելի ուղուց։
Բնօրինակ փաթեթի աղբյուրներն ու նպատակակետերը հիշատակող քաղաքականությունը տեղ ունի ապափաթաթումից հետո՝ թունելի ինտերֆեյսներում և երթուղային աղյուսակում։ Դրեք այն այնտեղ, և եզրային կանոնը կարող է փակ մնալ։
Ինչ է իրականում վավերացնում WireGuard-ը
AllowedIPs-ը դատում է WireGuard-ի կրած փաթեթի աղբյուրը, և այն, ինչ նա կրում է, IPIP-ով փաթաթված փաթեթն է։ Թույլատրված IPIP աղբյուրը ընդունվում է նույնիսկ այն դեպքում, երբ ներսի վերնագիրը նշում է հոսթ, որը դուք նախընտրում եք չերթուղավորել։ Այսպիսով, բնօրինակ աղբյուրը այն չէ, ինչ զուգընկերը ստուգել է ձեզ համար, և ներքին այդ զույգ հասցեները ապափաթաթումից հետո իրենց սեփական կիրառման կարիքն ունեն։
Փաթաթոցը տալիս է երթուղային կառուցվածք, ոչ թե գաղտնագրության երկրորդ շերտ։ IPIP-ը WireGuard-ի ներսում լրացուցիչ պաշտպանություն անվանելը նկարագրում է այլ նախագիծ։
Ստուգեք աստիճանով, ոչ թե մեկ ping-ով
Փորձարկեք ձեր հաշված սահմանը երկու կողմից շրջապատող չափեր, ապա հաստատեք, թե ինչ է կարծում միջուկը երկու սարքերի մասին։ Երբ 1360 բայթ բեռնվածքը գումարած 40 բայթ վերնագրերը տալիս են 1400, ներքևի առաջին արձագանքը տեղավորվում է, իսկ երկրորդը նստում է առաստաղից մեկ բայթ այն կողմ:
ping -M do -s 1372 10.9.0.2
ping -M do -s 1373 10.9.0.2
wg show wg0
ip -d link show ipip0Առաստաղից ներքև մաքուր անցումը և դրա վերևի առաջին չափի ձախողումը նշանակում են, որ թվաբանությունը դիմանում է ծայրից ծայր։ Այնուհետև կրկին գործարկեք սկզբում կանգ առած փոխանցումը, որովհետև սինթետիկ զոնդը ապացուցում է բյուջեն և ոչինչ չի ասում ուղարկողի սեփական գրառման չափերի մասին։ Եթե ներդրված ուղին դեռ կոտրվում է ձեր ապացուցած տեղավորող չափի վրա, ստուգեք հեռավոր ծայրի ապափաթաթումն ու երթուղիները, նախքան MTU-ից ևս տասը բայթ կտրելը։