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.201472 بائٹ کا پے لوڈ صاف 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 کی سیگمنٹ سائز کی درستی کبھی نہیں ملتی۔ ٹکٹ میں اصل اقدار رکھیں، کیونکہ ناقابلِ واپسی مرمت ہونے کے انتظار میں دوسرا مسئلہ ہے۔ اگر سائز کی جانچ پاس ہو جائے اور اپ لوڈ پھر بھی رکے، تو سیاہ سوراخ سبب نہیں تھا، اور تحقیقات کو تبدیلی پھیلانے کے بجائے آگے بڑھنا چاہیے۔