کیا چھوٹا VPN MTU تیز ہے؟ اصل شواہد کا موازنہ کریں
کم MTU راستے کی حد سے بچ سکتا ہے اور پھر بھی تھروپٹ کی قیمت دے سکتا ہے۔ تبدیلی رکھنے سے پہلے اصل پابندی، پیکٹ اوور ہیڈ اور کام کا بوجھ موازنہ کریں۔
ٹنل بڑی منتقلیاں چھوڑ دیتا ہے مگر پنگ گزرنے دیتا ہے، اس لیے مشورہ جلدی آتا ہے: MTU کم کریں۔ درستی کبھی کبھی کام کرتی ہے، اور پھر اسے ہر نیٹ ورک کے ہر پروفائل پر لاگو کیا جاتا ہے۔ وہیں پر نشانہ بنائی گئی مرمت مستقل کارکردگی ٹیکس بن جاتی ہے۔ جو موازنہ کرنا ہے وہ راستے کی اصل حد اور اس کے نیچے ہر پیکٹ کو چھوٹا کرنے کی لاگت کے درمیان ہے۔
MTU کم کرنے پر واقعی کیا سکڑتا ہے
ہر پیکٹ آپ کا ڈیٹا لے جانے سے پہلے ہیڈر لے جاتا ہے۔ 1500 بائٹ کے ایتھرنیٹ راستے پر IPv4 اور TCP 40 بائٹ لیتے ہیں اور پے لوڈ کے لیے 1460 چھوڑتے ہیں؛ انکیپسولیشن اوپر بیرونی IP، UDP اور ٹنل ہیڈر شامل کرتا ہے، اس لیے اندرونی پے لوڈ بجٹ دوبارہ کم ہوتا ہے۔ انٹرفیس کا MTU کم کرنا اس بجٹ کو جان بوجھ کر چھوٹا کرتا ہے۔
لاگت بائٹس کی تعداد کے بجائے پیکٹوں کی تعداد کے متناسب ہے۔ وہی فائل زیادہ پیکٹوں میں تقسیم ہو تو راستے کے ہر آلے پر زیادہ خلل، زیادہ روٹنگ فیصلے اور فی پیکٹ زیادہ پروسیسنگ درکار ہوتی ہے۔ جو راؤٹر پہلے ہی فی سیکنڈ پیکٹ کی حد کے قریب ہے، وہاں یہ گولائی کی غلطی نہیں بلکہ حقیقی سستی ہے۔ لاگت اس وقت بھی ظاہر ہوتی ہے جب خود منتقلی کامیاب ہو۔
اسی لیے چھوٹا MTU کسی پابندی کے گرد گھومنے کا راستہ ہے، عام اصلاح نہیں۔ یہ بڑی فریم نہ لے جا سکنے والے راستے کے خلاف بھروسہ خریدتا ہے اور ہر اس پیکٹ سے اوور ہیڈ وصول کرتا ہے جسے کمی کی ضرورت نہ تھی۔
چھوٹا MTU کب درست درستی ہے
کلاسیک علامت مخصوص ہے: TCP ہینڈ شیک مکمل ہوتا ہے، چھوٹے جواب آتے ہیں، اور بڑی ڈاؤن لوڈ رک جاتی ہے یا ری سیٹ ہو جاتی ہے۔ 1472 بائٹ پر نہ تقسیم کریں بٹ کے ساتھ پنگ ناکام ہوتی ہے جبکہ 1400 بائٹ کی پنگ کامیاب ہوتی ہے، جو ایسے راستے کی طرف اشارہ کرتا ہے جو پورے سائز کا پیکٹ نہیں لے سکتا اور وہ ICMP پیغام نہیں پہنچاتا جو بھیجنے والے کو کم کرنے کو کہتا۔
راستے کے MTU کی دریافت انہی ICMP تقسیم کی ضرورت کے پیغامات پر منحصر ہے۔ جب فائر وال انہیں پھینک دیتا ہے، بھیجنے والا بڑا پیکٹ بار بار دہراتا ہے اور کنکشن لٹکا ہوا لگتا ہے۔ ٹنل کی طرف MTU کم کرنا تکرار سے بچاتا ہے، اور یہ اس نیٹ ورک کے لیے جائز مرمت ہے۔
رسائی ٹیکنالوجیز بھی اپنی حدیں لگاتی ہیں: PPPoE عام طور پر 1492 پر محدود ہوتا ہے، کچھ موبائل اور DSL راستے کم ہیں، اور نیسٹڈ ٹنل اوور ہیڈ دو بار کم کرتے ہیں۔ گائیڈ سے عدد نقل کرنے کے بجائے اصل راستہ ناپیں، اور یاد رکھیں کہ IPv6 اسے لے جانے والے ہر لنک پر کم از کم 1280 بائٹ MTU مانگتا ہے، جیسا کہ RFC 8200 بیان کرتا ہے۔
ایک بدلنے سے پہلے تین کنٹرول موازنہ کریں
MTU، MSS اور تقسیم مختلف تہوں کے مختلف کنٹرول ہیں، اور غلط بدلنے سے علامت اپنی جگہ رہتی ہے۔
| Control | Layer | What it changes | Where it misleads |
|---|---|---|---|
| Interface MTU | IP link | Largest frame the interface will send | Penalizes every protocol, not just the one that failed |
| TCP MSS clamp | TCP | Segment size advertised in the handshake | Leaves UDP and QUIC untouched |
| DF and fragmentation | IP | Whether a router may split a packet | Can break path MTU discovery and security assumptions |
| Tunnel overhead | Encapsulation | Inner MTU after outer headers | Mismatch shows up only for large inner packets |
MSS محدود کرنا اکثر سب سے کم مداخلت والی مرمت ہے، کیونکہ یہ صرف TCP پر اثر ڈالتا ہے اور انٹرفیس کو دوسرے ٹریفک کے لیے آزاد چھوڑتا ہے۔ کم انٹرفیس MTU زیادہ وسیع اور سمجھنے میں آسان ہے، اسی لیے صارفی راؤٹروں پر عام ہے، مگر یہ ایک پروٹوکول کا مسئلہ ہر پروٹوکول سے وصول کرتا ہے۔
نہ تقسیم کریں رویہ بند کرنا تقسیم کی اجازت دے کر علامت چھپاتا ہے، اور عام طور پر تاخیر کو مزید خراب کرتا ہے جبکہ اس فیڈ بیک کو توڑتا ہے جو درست سائز ڈھونڈتا۔ مستقل حل کے طور پر اس سے بچیں۔
ایک عدد کے بجائے سمجھوتہ ناپیں
نہ تقسیم کریں پروب سے راستے کی حد تلاش کریں، اونچائی سے شروع کریں اور جواب آنے تک نیچے آئیں:
ping -M do -s 1472 203.0.113.10
ping -M do -s 1400 203.0.113.10
tracepath 203.0.113.10پھر دونوں ترتیبات پر اصل کام کا موازنہ کریں: وہی فائل منتقلی، وہی اینڈ پوائنٹ اور وہی نیٹ ورک۔ تکمیل کا وقت اور دوبارہ بھیجنا ریکارڈ کریں، مثلاً nstat -az TcpRetransSegs کے ساتھ، اور اگر ٹنل چھوٹے راؤٹر پر ختم ہو تو آلے کا CPU دیکھیں۔ مختصر مصنوعی تھروپٹ ٹیسٹ اس رکاوٹ کو چوک سکتا ہے جو چند میگا بائٹ کے بعد ہی ظاہر ہوتی ہے۔
کمی کے بعد پیکٹ کاؤنٹر بڑھیں گے، کیونکہ وہی منتقلی اب زیادہ پیکٹ استعمال کرتی ہے۔ یہ متوقع ہے اور زیادہ تھروپٹ کا ثبوت نہیں۔ مکمل شدہ ایپلیکیشن ڈیٹا، دوبارہ بھیجنے کی تعداد اور جوابدہی کا موازنہ کریں، صرف پیکٹ کی شرح کا نہیں۔
تبدیلی مرحلوں میں لائیں اور اسے محدود رکھیں
اصل مقدار ریکارڈ کریں، ایک کنٹرول بدلیں، اور مستقل کرنے سے پہلے پیمائش دہرائیں۔ اگر شواہد فائدہ نہ دکھائیں تو پچھلی مقدار اسی انٹرفیس کمانڈ سے بحال کریں جو آپ نے اسے سیٹ کرنے کے لیے استعمال کی:
ip link set dev wg0 mtu 1420
ip link set dev wg0 mtu 1500نتیجہ اسی نیٹ ورک تک محدود رکھیں جسے اس کی ضرورت تھی۔ جس پروفائل کو ہوٹل Wi-Fi، موبائل ہاٹ اسپاٹ اور دفتر کے LAN پر چلنا ہے، اسے ان میں سے کسی کی مطلوبہ کم ترین مقدار ورثے میں نہیں ملنی چاہیے، الا یہ کہ کلائنٹ راستہ نہ پہچان سکے۔
درست مقدار وہ سب سے بڑا MTU ہے جو راستے پر زندہ رہتا ہے، نہ کہ سب سے چھوٹا جو علامت مٹا دے۔ راستہ، پروب کا نتیجہ اور واپسی ریکارڈ کریں، اور رسائی نیٹ ورک بدلنے پر ترتیب دوبارہ دیکھیں۔