د IPv6 ناکامۍ ډېری وخت پر پروتوکول ورټوپ کیږي، نه پر هغه بستې اندازې چې دوی یې رامنځته کړي۔ دواړه کورنۍ واقعاً له ډېره لوی بستې سره بېلابېل چلند کوي، او تونل هغه شی دی چې دا توپیر مهم کوي۔ د IPv4 رټرونه کولای شي بسته برخې کړي کله چې قواعد اجازه ورکړي، خو د IPv6 رټرونه باید په لاره کې هېڅکله برخې ونه کړي۔ IPv6 پر ځای لېږونکي ته وایي، او د لېږونکي څخه تمه کیږي چې غبرګون وښيي۔ هر څه چې وروسته سم نه وي، د دې پورې اړه لري چې هغه پیغام رسي یا نه۔

هره کورنۍ څه کوي

جدول په څلورو کرښو کې میکانیزم دی، او یوه کرښه ډېره ګډوډي تشریح کوي۔

BehaviourIPv4IPv6
Router fragments an oversized packetAllowed while DF is clearNever
Signal returned to the senderICMP Fragmentation NeededICMPv6 Packet Too Big
Size that must always work68 bytes1280 bytes
Fragmentation possibleRouters or sourceSource only

IPv6 په لاره کې برخه کول نه لري او د پاکولو لپاره DF بیرغ هم نه لري، نو کله چې بسته ډېره لویه وي د تکیه کولو لپاره څه نشته۔ لېږونکي ته باید وویل شي، او لېږونکی باید دا ومني۔

تونل لاره په غلیم اواز کې تنګوي

VPN بسته له کوربه وتلو مخکې بهرني سرلیکونه ورزیاتوي، او په کوډ شوي حالت کې بشپړتیا ډاټا هم ورزیاتوي۔ داخلي بسته کولای شي په هغه انټرفېس MTU کې ځای شي چې دا یې ویني، خو بهرنۍ بسته د بلې تړنې حد تېروي، او له همدې کبله دا لومړی په تونل کې ښکاري۔ د تونل د انټرفېس MTU په قصد کم کړئ، یا په لاره کې TCP MSS کلک کړئ، او ولیکئ چې کومه شمېره مو غوره کړه او ولې۔

د ESP اضافي بار د حالت او الګوریتمونو پورې اړه لري، نو سم تونل MTU یوه محاسبه ده، دود نه۔ هر څه چې غوره کړئ، باید د بشپړې 1280 بایټې داخلي IPv6 بستې لپاره ځای پرېږدي، ځکه هر IPv6 تړنه باید هومره وړي۔ هغه تونل چې 1280 بایټه IPv6 نشي وړل کولای، د تنظیم ستونزه نه ده؛ دا د هغې کورنۍ لپاره ماتېدلې لاره ده۔ همدا محدودیت دی چې کله د یوازې IPv4 لرونکې ځای پرځای کېدنې څخه MTU ارزښت کاپي شي، ورک کیږي۔

ولې نښه د بندېدو په څېر ښکاري

ناکامي پاکه تېروتنه نه ده، او له همدې کبله یې غلط تشخیص کیږي۔ TCP لاس ورکول بشپړیږي، کوچني ځوابونه رسي، او اړیکه هغه ساه بنديږي چې لوی ځواب یا لوی اپلوډ پیل شي، ځکه هغه لومړنۍ بستې دي چې د غورځولو لپاره کافي لویې دي۔ SSH نښلېږي او بیا په لومړني لوی وتلو کې بند پاتې کیږي، او د پاڼې سرلیک بار کیږي خو بدن یې هېڅکله نه بشپړیږي۔

که د ICMPv6 د ډېرې لویې بستې پیغامونه فلټر شي، لېږونکی هېڅکله نه پوهیږي او هماغه اندازه بیا بیا هڅوي۔ دا توره سوري ده، نه وروسته لاره، او د دې نښه تصادفي ضایعه نه ده، بلکې تکرارېدونکې اندازه-پوله ده۔ د اړوند کنټرول ترافیک اجازه ورکول د کارکوونکې IPv6 ځای پرځای کېدنې برخه ده، مهرباني نه۔

هغه پیغامونه چې ستاسو خپله لاره پرې تکیه ده مه بندوئ او بیا پایله د IPv6 خرابۍ په توګه مه بیانوئ۔ هماغه دلیل د IPv4 د Fragmentation Needed پیغامونو لپاره هم معتبر دی، چې د فایر وال لیکوالانو په منځ کې هماغسې نامشهور او هماغسې اړین دي۔

پوله اندازه کړئ، بیا پوړ سم کړئ

د اټکل پر ځای وګورئ: په IPv4 کې د don't-fragment بیرغ او په IPv6 کې ثابتې پیلوډ اندازې وکاروئ، او ولیکئ چې ځوابونه چېرته درېږي۔ ping -M do -s 1472 او ping -6 -s 1400 د ستونزې بڼه ټاکلو لپاره کافي دي، او tracepath په لاره کې موندل شوې د لارې MTU راپور کوي۔

بیا هغه پوړ سم کړئ چې د دې شمېرې څښتن دی: د تونل د انټرفېس MTU، د TCP لپاره MSS کلکول، یا پخپله لاره۔ د IPv6 قاعدې لپاره RFC 8200 حواله ده، او لوستل یې له هغې پېښې لنډ دي چې مخه یې نیسي۔

هغه کورنۍ وآزمویئ چې اپلیکیشن واقعاً کاروي، ځکه دوه-سټیک نوم کېدای شي په یوه کورنۍ ځواب ورکړي او په بله نه، او اپلیکیشن کېدای شي د شبکې بدلون وروسته بدل شي۔ هغه پته ولیکئ چې وآزمول شوه، ځکه د A ریکارډ په وړاندې پایله د AAAA ریکارډ په اړه هېڅ نه وایي۔

د اندازې پولې ته د ثبوت په سترګه وګورئ

تکرارېدونکې اندازه-پوله یوه له هغو لږو شبکوي خرابیو ده چې هر ځل په هماغه بایټ شمېر، له هماغه سرچینې څخه په سمه توګه تکرارېږي۔ دا هغه ډالۍ جوړوي نه معما، او دا هم مانا لري چې سمون کولای شو تایید شي نه چې هیله ورته ولرو۔

موندل شوې MTU، هغه تونل MTU چې تاسو تنظیم کړی او هغه ازموینه چې توپیر یې ثابت کړ په ټکټ کې ولیکئ۔ بل کس به په بله تړنه کې هماغه حساب ومومي۔

اړوندې مقالې