نیسٹڈ VPN ٹنلیں: بڑے پیکٹوں پر اندرونی ٹنل کیوں رکتی ہے
ہر ٹنل اگلی کے شروع ہونے سے پہلے راستے کے پیکٹ بجٹ کا حصہ خرچ کرتی ہے۔ ہیڈر جمع کریں اور بڑے پیکٹوں پر اندرونی سیشن ناکام ہو جاتا ہے۔
DNS حل ہوتا ہے، SSH سیشن قائم رہتا ہے، پھر بڑا اپ لوڈ رک جاتا ہے جبکہ اسی ہوسٹ کو ping اب بھی جواب دیتا ہے۔ یہ تقسیم خراب ٹنل کی نہیں بلکہ پیکٹ کے حجم کی طرف اشارہ کرتی ہے۔ نیسٹڈ ٹنلیں ایسے حجم پر وہاں پہنچتی ہیں جہاں کوئی ایک ٹنل تنہا نہیں پہنچتی۔ اندرونی سیشن ٹھیک ہے؛ اسے ایسے پیکٹ دیے جا رہے ہیں جو اب فٹ نہیں ہوتے۔
راستے کا MTU اصل میں کہاں جاتا ہے
ہر انکیپسولیشن اگلی پرت کی باری آنے سے پہلے بائٹ خرچ کرتی ہے۔ ایک Ethernet راستہ بیرونی پیکٹ کو 1500 بائٹ دیتا ہے، اور بیرونی ٹنل اپنا حصہ اس سے پہلے لے لیتی ہے کہ اندر کسی چیز کو پتہ دیا جا سکے۔ ایک اندازہ شدہ اوور ہیڈ قیمت بالکل اتنی ہی غلط ہوگی جتنا اہم ہے۔
پرتیں ترتیب سے درج کریں: رسائی کا راستہ، بیرونی نقل و حمل، بیرونی ٹنل، اندرونی نقل و حمل، اندرونی ٹنل، ایپلیکیشن۔ ہر ہیڈر کو ایک بار گنیں، اور UDP کو ٹنل کے اپنے ہیڈر اور ٹیگ سے الگ رکھیں۔
دو WireGuard پرتیں، ایک بار گنی گئیں
ایک IPv4 رسائی راستہ لیں، جس کے اندر ایک اور WireGuard ٹنل ہو۔ بیرونی پرت 20 بائٹ IPv4، 8 بائٹ UDP اور WireGuard ڈیٹا ہیڈر نیز اس کے توثیقی ٹیگ کے لیے 32 بائٹ خرچ کرتی ہے۔ اس کے اندر اندرونی ٹنل کو اپنا 20 بائٹ کا IPv4 ہیڈر اور 8 بائٹ کا UDP ہیڈر چاہیے، اس کے دوسرے 32 بائٹ WireGuard اوور ہیڈ سے پہلے۔ جو بچتا ہے اس میں IPv4 ہیڈر، TCP ہیڈر اور ڈیٹا آ جاتا ہے۔ بیرونی IPv6 راستہ 20 کے بجائے 40 لیتا ہے اور 1320 چھوڑتا ہے۔
| Layer | Bytes |
|---|---|
| Path MTU | 1500 |
| Outer IPv4 header | 20 |
| Outer UDP header | 8 |
| Outer WireGuard header and tag | 32 |
| Inner transport IPv4 header | 20 |
| Inner UDP header | 8 |
| Inner WireGuard header and tag | 32 |
| Innermost IPv4 header | 20 |
| TCP header | 20 |
| Payload that fits | 1340 |
حساب 1340 بائٹ پر آتا ہے۔ انہی قواعد کے ساتھ ایک پرت TCP پے لوڈ کے لیے 1400 چھوڑتی ہے، یعنی 1500 منفی 20، 8، 32، 20 اور 20، اور 60 بائٹ کا فرق بالکل وہی اندرونی انکیپسولیشن ہے جو دوسری ٹنل شامل کرتی ہے۔
1400 کو نیسٹڈ راستے پر لاگو کریں اور اندرونی ٹنل 60 بائٹ کم پڑتی ہے، جو پیکٹ کے اس کی ضرورت کے مطابق بڑا ہونے تک نظر نہیں آتا۔ پیڈنگ اور پروٹوکول کا اپنا فریگمنٹیشن آپشن پھر سے اعداد ہلاتے ہیں، اس لیے جدول پر بھروسہ کریں۔
MTU، MSS اور فریگمنٹیشن الگ الگ جگہوں پر کام کرتے ہیں
انٹرفیس MTU محدود کرتا ہے کہ انٹرفیس کیا بھیجے گا، جبکہ TCP MSS کلپنگ بدلتی ہے کہ TCP ساتھی کیا بھیجنے کو تیار ہے۔ کلپنگ TCP سیشن ٹھیک کرتی ہے اور بڑے UDP ڈیٹاگرام کے لیے کچھ نہیں کرتی، اسی طرح ایک درستی ایک ایپلیکیشن کے لیے کامیاب دکھائی دیتی ہے اور اگلی کو خاموشی سے چھوڑ دیتی ہے۔ پروٹوکول کا اپنا فریگمنٹیشن آپشن اپنی ناکامیوں والا تیسرا لیور ہے۔ انٹرفیس MTU عام پہلا قدم اور سب سے موٹا ہے۔
پل والی اور روٹ شدہ ٹنلیں مختلف فریم لے جاتی ہیں، اس لیے کسی دوسری تنصیب کے اعداد شاذ و نادر ہی منتقل ہوتے ہیں۔ راستے کی MTU دریافت، جس کا ذکر RFC 8201 میں ہے، صرف تب مدد کرتی ہے جب اس پر منحصر ICMP پیغامات کو گزرنے دیا جائے۔
کم پڑنے والی پرت تلاش کرنا
اگر تقاضے موازنے کی اجازت دیں تو نیسٹ کرنے سے پہلے ہر ٹنل الگ جانچیں۔ مقررہ حجم کی پروب یہ طے کرتی ہے: ping -M do -s 1472 -c 3 10.8.0.1 اسی پرت کے اندر 1500 بائٹ کا مکمل IPv4 پیکٹ بھیجتی ہے۔ دوسری پرت شامل کریں اور وہی پروب دہرائیں، تاکہ کوئی بھی ناکامی کسی معلوم تبدیلی کی ہو۔
جب منتقلی رک جائے تو ایک وقت میں ایک دستاویزی پیرامیٹر بدلیں اور ناکام ہونے والا حجم لکھیں۔ واپسی کا راستہ بھی دیکھیں، کیونکہ نیسٹڈ روٹ ریکرشن پیکٹ کے حجم کے مسئلے کی اتنی قریب نقل کر سکتا ہے کہ ایک دوپہر ضائع ہو جائے۔ فلٹر شدہ ICMP جواب اصل حد چھپا سکتا ہے، اس لیے پروب استدلال سے زیادہ اہم ہے۔
بجٹ وہاں لکھیں جہاں اگلے شخص کو ملے
ہر پرت کے لیے ایک قطار والا جدول انگوٹھے کے قاعدے سے زیادہ چلتا ہے۔ اسے ٹنل کے نقشے کے پاس رکھیں تاکہ دباؤ میں کوئی حساب دوبارہ نہ کرے۔
زیادہ ٹنلیں یعنی زیادہ انحصار، اس لیے رول بیک منصوبہ بجٹ کے پاس اپنی جگہ کا حقدار ہے۔ اگر اعداد پھر بھی نہ ملیں تو دوبارہ اندازہ لگانے کے بجائے راستہ ناپیں۔ مقصد وہ عدد ہے جس کا آپ دفاع کر سکیں، یاد رکھنے والا نہیں۔