VPN MTU کی خرافات: آپ کے پیکٹ کیوں سکڑتے ہیں اور جگہ کہاں جاتی ہے

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

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

پہلی خرافات: ٹنل کا MTU راستے کا MTU ہے

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

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

دوسری خرافات: انکیپسولیشن کی قیمت ایک ہیڈر ہے

بیرونی تہوں کو ایمانداری سے گنیں۔ بیرونی IP ہیڈر IPv4 میں 20 بائٹ یا IPv6 میں 40 ہے۔ NAT سے گزرنے کے لیے UDP انکیپسولیشن 8 کا اضافہ کرتی ہے۔ ٹنل پروٹوکول اپنا ہیڈر، ایک ابتدائی ویکٹر یا نونس، سائفر کی بلاک یا ترتیب کی حد تک پیڈنگ، ایک ٹریلر اور انٹیگریٹی جانچ کی قدر شامل کرتا ہے۔ پروٹوکول اور سائفر کے مطابق، اندرونی پیکٹ شروع ہونے سے پہلے ہی مجموعہ آرام سے درجنوں بائٹس میں پہنچ جاتا ہے۔

پھر خود اندرونی پیکٹ کے ہیڈروں کے لیے دوبارہ منہا کریں۔ ٹنل کے اندر TCP قطعہ اپنا 20 بائٹ IP ہیڈر اور 20 بائٹ TCP ہیڈر ڈھوتا ہے، اور TCP کا MSS MTU سے آتا ہے، ٹنل کے برائے نام پے لوڈ سے نہیں۔ اسی لیے ping چھوٹے پے لوڈ کے ساتھ کامیاب ہو سکتا ہے جبکہ فائل کی منتقلی رک جاتی ہے: اوزار مختلف چیزیں جانچتے ہیں، اور ان میں سے صرف ایک پورے حجم کا TCP قطعہ استعمال کرتا ہے۔

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

پہلا حکم مقرر کردہ ٹنل MTU کی اطلاع دیتا ہے۔ دونوں جانچیں 1472 بائٹ کا پے لوڈ بھیجتی ہیں، جو IPv4 اور ICMP ہیڈروں کے 28 بائٹس کے ساتھ 1500 بائٹ کا پیکٹ ہے، پھر چھوٹا۔ اگر بڑی جانچ مکمل ناکام ہو اور چھوٹی کامیاب ہو، تو آپ کے پاس حجم پر منحصر خرابی ہے، عام روٹنگ مسئلہ نہیں۔

تیسری خرافات: PPPoE اب بھی آپ کو صاف 1500 دیتا ہے

روایتی PPPoE رسائی لنک 1500 بائٹ کا IP پیکٹ نہیں ڈھوتا۔ PPPoE ہیڈر اور PPP پروٹوکول فیلڈ ایتھرنیٹ فریم کے اندر 8 بائٹ لیتے ہیں، جس سے IP پیکٹ کے لیے 1492 بچتے ہیں۔ یہ RFC 2516 میں بیان کردہ روایتی حد ہے۔ اگر آپ ایسے لنک پر VPN چلاتے ہیں، تو ٹنل کا اضافی خرچ انہی 1492 سے آتا ہے، 1500 سے نہیں۔

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

ناکامی انتخابی کیوں لگتی ہے

چھوٹی درخواستوں کا کامیاب ہونا اور بڑی منتقلیوں کا رک جانا راستے کے MTU کے سیاہ سوراخ کی کلاسیکی علامت ہے۔ ہاتھ ملانا، DNS استفسار اور API کال سب فٹ ہو جاتے ہیں؛ بڑی منتقلی پورے حجم کے قطعے بناتی ہے جو ایک لنک پر مر جاتے ہیں، اور وہ ICMP پیغام جو مسئلہ بتانا چاہیے تھا کبھی نہیں پہنچتا۔ کنکشن ٹھیک دکھتا ہے اور ڈاؤن لوڈ لٹک جاتا ہے، جس سے لوگ راستے کے بجائے سرور کو دیکھنے لگتے ہیں۔

دوسری، متعلقہ غلطی تین تعدادوں کو ملا دینا ہے: انٹرفیس MTU، TCP MSS اور پروٹوکول کی اپنی فریگمنٹیشن یا پیڈنگ ترتیب۔ راؤٹر پر MSS کلیمپنگ اعلان کردہ MSS کو دوبارہ لکھتی ہے تاکہ بھیجنے والا چھوٹے قطعے بنائے؛ یہ ٹنل MTU نہیں بدلتی اور UDP ٹریفک کی مدد نہیں کرتی۔ متعلقہ دکھنے کی وجہ سے تینوں کو ایک ہی تعداد دینا وہ طریقہ ہے جس سے نیک نیت تبدیلی کام کرتا سیٹ اپ توڑ دیتی ہے۔

کیا بدلیں، اور کس ترتیب سے

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

پھر کلائنٹ جو سب سے چھوٹی ایڈجسٹمنٹ دستاویز کرتا ہے اسے لاگو کریں۔ بہت سے کلائنٹ ٹنل MTU کے ساتھ MSS کی اصلاح کا آپشن دیتے ہیں، اور MSS آپشن اکثر TCP کے لیے بہتر لیور ہوتا ہے کیونکہ یہ ہر پیکٹ کو چھوٹا کیے بغیر بھیجنے والے تک پہنچتا ہے۔ وہی منزل اور وہی منتقلی دوبارہ جانچیں، اور جن تعدادوں پر آپ ٹھہرے انہیں نوٹ کریں۔ ایک رسائی نیٹ ورک پر کام کرنے والی ٹنل قدر عالمگیر مستقل نہیں ہے، اور اگلی سائٹ کا اپنا بجٹ ہوگا۔