د MTU تور سوری: ولې کوچني غوښتنې کار کوي خو اپلوډونه ودرېږي

یو پاڼه بارېږي، یوه کوچنۍ API غوښتنه بېرته راځي، او بیا د فایل اپلوډ تر هغې ځنډېږي چې پیرودونکی تسلیم شي۔ د سرور په لاګ کې هېڅ شی دا نه تشریح کوي، ځکه چې پاکټونه د لارې په منځ کې پرته له دې چې ګټوره ځواب بېرته ولېږل شي وغورځول شول۔ دا بڼه د MTU تور سوری دی: له هغې تنګه اړیکه چې لېږدونکی یې فکر کوي، په ګډون له یوې غلې انکار چې دا ووایي۔ هغه اندازه چې ناکامېږي تکرارېدونکې ده، او همدا یې د تشخیص وړ ګرځوي۔

څه سوری تور کوي

هره اړیکه د لېږد اعظمي واحد لري، او له راتلونکي ټوپ حد څخه لوی پاکټ باید یا ټوټه شي یا د ICMP پیغام سره رد شي چې دا وایي۔ د لارې MTU کشف په دې تکیه دی چې هغه پیغام ورسیږي او درناوی یې وشي۔ د هغه فلټرول یا نادیده ګڼل لېږدونکی پرېږدي چې هغه پاکټ تکرار کړ چې هېڅکله نه ځایېږي۔

انکپسولیشن دا د VPN شاوخوا عادي کوي، ځکه چې تونل هغه پاکټ ته بهرنی سرلیک ورزیاتوي چې لا دمخه د فزیکي اړیکې لپاره اندازه شوی و۔ داخلي پاکټ په 1500 بایټ کې قانوني دی او انکپسول شوی نه، نو ځکه په پوله کې مري او کوچني پاکټونه تېریږي۔ بشپړ شوی لاسروښانه او کار کوونکې ننوتلو پاڼه یوازې دا ثابتوي چې کوچني پاکټونه کار کوي۔ تر ټولو لوی پاکټ چې اپلیکیشن یې لېږلو هڅه کوي هماغه مهم دی۔

هغه اندازه ومومئ چې هلته ماتېږي

د نهټوټې کېدو ازموینې سره د پېلود اندازه په دوه اړخیزه لټون ومومئ، د تونل یوې خوا میزبان څخه بلې خوا میزبان ته۔ تر ټولو لوی پېلود چې تېریږي هغه ستاسو د کارېدونکي لارې MTU دی چې د سرلیک لګښت ورڅخه کم شوی۔

ping -M do -s 1400 -c 2 192.0.2.20
ping -M do -s 1200 -c 2 192.0.2.20
ping -f -l 1372 192.0.2.20

د 1472 بایټ پېلود په پاکه 1500 بایټ Ethernet لاره تېریږي کله چې د IPv4 او ICMP سرلیکونو 28 بایټ ورزیات شي۔ کله چې هماغه ازموینه د تونل له پورته کېدو وروسته یوازې په کوچني پېلود بریالۍ شي، توپیر د انکپسولیشن لګښت دی، او د تونل پوله هماغه ځای دی چې د رد پیغام باید جوړ شوی وای۔ دواړه شمېرې، له نښلېدو مخکې او وروسته، ولیکئ، ځکه چې هماغه جوړه ثبوت دی۔ ازموینه د IPv6 لپاره تکرار کړئ کله چې اپلیکیشن هغه کاروي، ځکه چې سرلیک لوی دی او د ناکامۍ حد ځای بدلوي۔

د تونل په ملامتولو مخکې شواهد ولولئ

د لیرې اپلیکیشنونو تېروتنې، ګڼه ګوڼه او عادي زیان هم اپلوډونه ودروي، نو یو ناکام لېږد تور سوری نه پېژني۔ هغه څه چې دوی بېلوي د اندازې اړیکه ده: په 1200 بایټ کې تکرارېدونکې بریا او په 1400 بایټ کې تکرارېدونکی ځنډ، په هماغه لور، د هماغه پای نقطې له لارې۔

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

ترمیم په دواړو لېږدونو کې وګورئ

ملاتړ شوی ترمیم دا دی چې پولې ته اجازه ورکړئ ریښتینی حد راپور کړي، یا هلته د TCP اعظمي سګمنټ اندازه کلېم کړئ تر څو ډېر لوی سګمنټ هڅه نه شي۔ په شبکه کې هره MTU ټیټول، یا فایر وال بندول، نښه پټوي او یو ترتیب پرېږدي چې وروسته به هیچا پرې استدلال نه شي کولی۔

ip link show dev tun0
sudo nft list ruleset | grep -i -E 'mtu|mss'
sysctl net.ipv4.tcp_mtu_probing
ping -M do -s 1400 -c 2 192.0.2.20

د هماغې اندازې ازموینې سره تایید کړئ، بیا د هغه اپلیکیشن سره چې ناکام شو، او دوهم پروتوکول وګورئ، ځکه چې UDP اپلیکیشنونه هېڅکله د TCP د سګمنټ اندازې سمون نه ترلاسه کوي۔ په ټکټ کې اصلي ارزښتونه وساتئ، ځکه چې د نه بدلېدونکی ترمیم یوه دوهمه ستونزه ده چې د پېښېدو په تمه ده۔ که د اندازې ازموینه بریالۍ شي او اپلوډ لا هم ځنډېږي، تور سوری لامل نه و، او پلټنه باید مخکې لاړه شي نه دا چې بدلون پراخ کړي۔