VPN کے ذریعے راستے کے MTU کی دریافت: سائز اور ICMP کا خلا

سرنگ اپنا ہاتھ ملانا مکمل کرتی ہے، چھوٹی درخواستیں واپس آتی ہیں، اور پہلی بڑی منتقلی رک جاتی ہے۔ یہ نمونہ تھرو پٹ کی طرف اشارہ کرنے سے بہت پہلے راستے کے MTU کی طرف اشارہ کرتا ہے۔ راستے کا ہر ربط پیکٹ کے سائز کو محدود کرتا ہے، اور انکیپسولیشن اس اجازت کا کچھ حصہ بیرونی ہیڈرز پر خرچ کرتا ہے، اس لیے اندرونی پیکٹ خام راستے کے اشارے سے چھوٹا ہونا چاہیے۔ ناکامی خاموش ہے، اور یہی اسے تشخیص کرنا مہنگا بناتا ہے۔

راستے کا MTU دراصل کیا ناپتا ہے

راستے کا MTU دو ہوسٹوں کے درمیان راستے پر سب سے چھوٹا ربط MTU ہے، نہ کہ آپ کے مقامی انٹرفیس پر چھپا ہوا MTU۔ مقامی قدر وہ نقطہ ہے جہاں سے اندازہ شروع ہوتا ہے، اور راستہ طے کرتا ہے کہ یہ کہاں ختم ہونا چاہیے۔ یہی وجہ ہے کہ ایک جیسی سرنگ ایک رسائی نیٹ ورک پر کام کر سکتی ہے اور دوسرے پر رک سکتی ہے: راستہ بدلا، ترتیب نہیں۔ ایک بار ناپ کر ہر جگہ فرض کر لینا وہی غلطی ہے جو اس مسئلے کو زندہ رکھتی ہے۔

سرنگ کے لیے اہم عدد اندرونی MTU ہے، جو بیرونی راستے کی اجازت منفی وہ جو انکیپسولیشن خرچ کرتی ہے۔ WireGuard بیرونی IP ہیڈر اور UDP ہیڈر شامل کرتا ہے؛ دیگر ٹرانسپورٹ اپنے شامل کرتے ہیں۔ اندرونی سائز بہت زیادہ رکھیں تو ہر پورے سائز کے پیکٹ کو ایسی تقسیم درکار ہوگی جو شاید کبھی نہ ہو۔

سرنگ قابل استعمال پیکٹ کو کیوں چھوٹا کرتی ہے

اگر سرنگ کا انٹرفیس طبعی ربط کا MTU رکھے، تو ہر بڑا پیکٹ اس بات پر منحصر ہے کہ نیچے کوئی اسے تقسیم کرنے کو تیار ہو۔ IPv4 اصولی طور پر اجازت دیتا ہے، لیکن جس راؤٹر کو تقسیم نہ کرنے کا کہا گیا ہو وہ اس کے بجائے خرابی واپس کرتا ہے۔ IPv6 راؤٹر گزرگاہ میں کبھی تقسیم نہیں کرتے، اس لیے وہی ترتیب پتہ خاندان کے مطابق مختلف برتاؤ کرتی ہے۔ بہرحال، کوئی چیز واپس رپورٹ کرنے تک بھیجنے والا کچھ نہیں سیکھتا۔

عملی نتیجہ ایسا سائز ہے جو ہاتھ ملانے میں فٹ ہوتا ہے مگر پے لوڈ میں نہیں۔ TLS ClientHello یا DNS استفسار چھوٹے ہوئے راستے سے بغیر چھوئے گزرنے کے لیے کافی چھوٹا ہوتا ہے، جبکہ بڑی منتقلی ایسی نہیں۔ اس لیے علامات مخصوص ہوسٹوں کے بجائے مخصوص کارروائیوں کے گرد جمع ہوتی ہیں۔

دریافت صرف اس وقت کام کرتی ہے جب رائے واپس آئے

IPv4 دریافت don't-fragment بٹ پر منحصر ہے: جو راؤٹر پیکٹ آگے نہیں بھیج سکتا وہ اگلی چھلانگ کے MTU کے ساتھ ICMP fragmentation-needed واپس کرتا ہے، اور بھیجنے والا اپنا اندازہ کم کرتا ہے۔ IPv6 اس کے بجائے Packet Too Big پیغامات استعمال کرتا ہے، کیونکہ راؤٹر گزرگاہ میں تقسیم نہیں کرتے۔ دونوں طریقے یہ فرض کرتے ہیں کہ پیغام بھیجنے والے تک واپس راستہ پائے گا، سرنگ سے ہوتا ہوا اور واپسی کے راستے پر کسی بھی فائر وال سے آگے۔ جب یہ مفروضہ ناکام ہوتا ہے، بھیجنے والا ایسا سائز بار بار آزمانے لگتا ہے جو راستہ اٹھا نہیں سکتا۔

جو فائر وال echo request اور echo reply کی اجازت دیتا ہے اس نے ضروری نہیں کہ ان خرابی کی اقسام کی بھی اجازت دی ہو۔ ICMP ایک خاندان ہے، اور یہاں اہم ارکان خرابیاں ہیں، ایکو جوڑی نہیں۔ سرنگ کے دونوں سروں پر اور ان کے درمیان راستے پر کنٹرول ٹریفک کی پالیسی جانچیں، اور ہر جگہ ہر ICMP قسم کی اجازت دینے کے بجائے پلیٹ فارم کی معاون رہنمائی کی پیروی کریں۔

وہی فلٹرنگ سرنگ کے اندر بھی ہو سکتی ہے۔ اگر اندرونی راستہ خرابی کو گرا دے مگر بیرونی راستہ اسے لے جائے، تو بھیجنے والا ایسی حد سے ہم آہنگ ہو سکتا ہے جسے انکیپسولیٹڈ ٹریفک کبھی واقعی نہیں دیکھتا۔

عدد کا اندازہ لگانے کے بجائے راستہ جانچیں

منزل، رسائی نیٹ ورک اور سرنگ کو مستقل رکھیں، پھر صرف پیکٹ کا سائز بدلیں۔ MTU اشارے کے ساتھ ناکام ہونے والا don't-fragment امتحان آپ کو اگلی چھلانگ کی حد دیتا ہے؛ کسی سائز کے گزرنے تک دہرائیں، اور سائز اور پتہ خاندان دونوں درج کریں۔

ping -M do -s 1400 10.60.20.10
ping -M do -s 1300 10.60.20.10
ping -6 -M do -s 1300 2001:db8::10

فٹ ہونے والا پنگ یہ ثابت نہیں کرتا کہ کسی حقیقی اطلاق کے پورے سائز کے قطعے فٹ ہوں گے، اس لیے جو منتقلی واقعی ناکام ہوئی اس کے ساتھ امتحان دہرائیں۔ سب سے بڑے کامیاب امتحان کا موازنہ اپنے ترتیب کردہ سرنگ MTU سے کریں، اور دونوں اعداد اپنے نوٹس میں الگ رکھیں۔ اگر وہ تقریباً ایک ہیڈر کے برابر مختلف ہوں، تو آپ نے خرابی کے بجائے انکیپسولیشن اوور ہیڈ پا لیا ہے۔

RFC 4821 میں بیان کردہ PLPMTUD اوپر کی طرف جانچتا ہے اور پہنچائے گئے نقائص پر بھروسے کے بجائے ٹرانسپورٹ تصدیقیں استعمال کرتا ہے۔ یہ ICMP فلٹر کرنے والے راستوں پر مدد کرتا ہے، مگر معاونت اسٹیک اور اطلاق کے مطابق مختلف ہوتی ہے۔ TCP بہاؤ خود بحال ہو سکتا ہے جبکہ مقررہ ڈیٹا گرام سائز والی UDP اطلاق ناکام رہتی ہے۔

قدر منتخب کریں اور وجہ درج کریں

سرنگ MTU کم کرنا تشخیص بھی ہے اور جائز اصلاح بھی ایک بار جب آپ راستہ جان لیں۔ یہ یہ جاننے کا متبادل نہیں کہ کون سا راستہ اور کون طریقہ رائے شامل تھا، کیونکہ موبائل ربط کے لیے ترتیب دی گئی قدر فائبر کنکشن پر بلا ضرورت چھوٹی ہوگی۔ منتخب سائز، اسے جائز قرار دینے والا امتحان اور واپسی کا مرحلہ درج کریں۔

IPv4 طریقہ RFC 1191 میں اور IPv6 پیکٹائزیشن رہنمائی RFC 8201 میں بیان کی گئی ہے؛ دونوں کا نام لینا اگلے انجینئر کو مفروضہ دوبارہ اخذ کرنے سے روکتا ہے۔ اگر منتقلی آپ کے منتخب سائز پر اب بھی رکتی ہے، تو عدد کم کرنا بند کریں اور اگلی تہہ دیکھیں۔ ہر سائز پر ناکام ہونے والا راستہ MTU مسئلہ نہیں ہے۔