WireGuard کے اندر IPIP: وہ اضافی 20 بائٹ جو کسی نے بجٹ میں شامل نہیں کیے
IPIP WireGuard کے اندر 20 اضافی بائٹ خرچ کرتا ہے۔ زندہ ٹنل پر رکے ہوئے منتقلی کے لیے فریگمنٹیشن کو مورد الزام ٹھہرانے سے پہلے صحیح پرت پر بجٹ بنائیں۔
چھوٹے ping دن بھر سرنگ سے گزرتے ہیں، SSH بینر آتا ہے اور پھر فائل کی منتقلی شروع ہوتے ہی سیشن جم جاتا ہے۔ یہ نمونہ غلط پرت پر گنے گئے بائٹ بجٹ کی طرف اشارہ کرتا ہے، جہاں بیرونی سرنگ اپنے ہی اوور ہیڈ کے لیے ناپی گئی اور اندرونی کو کسی نے کم نہیں کیا۔ WireGuard کے لیے اندر رکھا گیا IPIP پیکٹ محض ایک اور IP پیکٹ ہے، اور اسی لیے یہ وہ بائٹ استعمال کرتا ہے جو آپ نے کبھی مخصوص نہیں کیے۔ درستی حساب ہے، اور یہ تین کمانڈوں اور ایک جدول میں سما جاتی ہے۔
وہ علامت جو اسے بے نقاب کرتی ہے
فریگمنٹیشن کا مسئلہ اپنا اعلان سائز سے کرتا ہے، کبھی پتوں سے نہیں۔ آپ کا پیر ایک گھنٹے تک 56 بائٹ کے ping کا جواب دیتا ہے اور پھر 1400 بائٹ پر خاموش ہو جاتا ہے، جبکہ سرنگ قائم رہتی ہے اور کوئی راستہ تبدیل نہیں ہوا۔ ہینڈ شیک سماتا ہے، پہلی مکمل TCP ونڈو نہیں، اور منتقلی صحت مند دکھائی دینے کے چند سیکنڈ بعد رک جاتی ہے۔
کوئی بھی ترمیم کرنے سے پہلے حد ناپیں، کیونکہ نہ ناپی گئی حد وہی ہے جس کا آپ دو بار پیچھا کریں گے۔ مشکوک سائز سے نیچے do-not-fragment بٹ سیٹ کر کے ایک پروب بھیجیں، ping -M do -s 1000 10.9.0.2، پھر اسے اس سائز پر دہرائیں جو آپ پہلے سے جانتے ہیں بہت بڑا ہے۔ جب منزل بغیر تبدیل رہے اور الٹ پلٹ پے لوڈ کے سائز کی پیروی کرے، تو روٹنگ اپنا کام کر رہی ہے اور بجٹ سے ایک ہیڈر غائب ہے۔
ہر ہیڈر ایک بار گنیں، صحیح پرت پر
سرنگ انٹرفیس سے نہیں، راستے کے سب سے چھوٹے MTU سے شروع کریں، کیونکہ دیوار دونوں سروں سے اوپر ہے۔ WireGuard IPv4 بیرونی ٹرانسپورٹ پر 60 بائٹ خرچ کرتا ہے: 20 IP کے لیے، 8 UDP کے لیے اور 32 اپنے ہیڈر کے لیے، اور جب وہ ٹرانسپورٹ IPv6 ہو تو 80 بائٹ۔ 1420 بائٹ کا wg0 1500 بائٹ کے راستے کے حقیقی طور پر پہنچا سکنے والے 1440 سے نیچے 20 بائٹ کی گنجائش رکھتا ہے، اور اسی لیے وکی سے نقل کیا گیا عدد یہاں بھی فٹ بیٹھتا ہے۔ پورا اسٹیک خاکے پر لکھیں، کیونکہ اگلی بار MTU بدلنے والا ورنہ نیا گول عدد چنے گا اور آپ کا بگ ورثے میں پائے گا۔
| Layer | Bytes | Remaining |
|---|---|---|
| Path MTU on the wired link | none yet | 1500 |
| WireGuard outer: IP, UDP, WG header | 60 | 1440 |
| Slack kept for safety | 20 | 1420 (wg0) |
| IPIP header inside the tunnel | 20 | 1400 (ipip0) |
| Original IPv4 and TCP headers | 40 | 1360 payload |
پانچویں قطار وہ جگہ ہے جہاں بجٹ بگڑتے ہیں، کیونکہ اندر رکھا گیا انٹرفیس جو 1400 بائٹ لے کر جاتا ہے ان میں اصل پیکٹ کے اپنے 40 بائٹ ہیڈر پہلے ہی شامل ہیں۔ ان بائٹ میں سے صرف 1360 فائل پڑھنے والے عمل تک پہنچتے ہیں۔ 1400 کو ایپلیکیشن پے لوڈ سمجھیں، جیسا کہ اس کالم کے بغیر کوئی بھی خاکہ آپ کو مدعو کرتا ہے، اور اندرونی آلہ نہ ہلنے والی دیوار کے سامنے 40 بائٹ زیادہ فیاض ٹھہرتا ہے۔
دونوں MTU الگ الگ مقرر کریں
کیریئر اور اندر رکھا گیا آلہ الگ الگ اشیاء ہیں، اس لیے ہر ایک کو اپنی قدر چاہیے۔ انہیں اسی ترتیب سے لاگو کریں، کیونکہ اندر رکھا گیا آلہ کیریئر سے کچھ بھی ورثے میں نہیں پاتا:
ip link set wg0 mtu 1420
ip tunnel add ipip0 mode ipip remote 203.0.113.9 local 198.51.100.4
ip link set ipip0 mtu 1400یاد رکھنے کے قابل قاعدہ: اندرونی MTU = بیرونی MTU - 20 جب IPIP سرنگ جو پیکٹ لے کر جاتی ہے وہ IPv4 ہو، اور - 40 جیسے ہی اندرونی پیکٹ کا کوئی بھی پہلو IPv6 ہو جائے، کیونکہ اندر رکھا گیا ہیڈر 20 بائٹ سے بڑھ کر 40 ہو جاتا ہے۔ اس تفریق میں اور کچھ نہیں آتا۔ آپ کے 1420 چننے کے وقت WireGuard کا اوور ہیڈ پہلے ہی خرچ ہو چکا تھا، اور اسے دو بار وصول کرنا ایسی سرنگ بناتا ہے جو بالکل ٹھیک کام کرتی ہے اور جب تک کوئی اسے نہ ناپے سست رہتی ہے۔ جس تعیناتی میں دونوں آلات گول 1400 لے کر چلتے ہیں وہ اسی غلطی کی انگلی کا نشان ہے۔
اندر رکھے گئے پیکٹ کے کسی بھی پہلو پر IPv6 اوپر کے ہر عدد کو باطل کر دیتا ہے، اس لیے ملتے جلتے سائٹ سے عدد نقل کرنے کے بجائے دوبارہ حساب کریں۔ جیسے ہی IPv6 بیرونی راستے میں یا اصل ڈیٹاگرام میں ظاہر ہو، تفریق شدہ ہیڈر ہر ایک 40 بائٹ کے ہو جاتے ہیں، اور پے لوڈ کا عدد بالکل اتنا ہی گرتا ہے۔
وہ فائر وال قاعدہ جس کی آپ کو شاید ضرورت نہیں
دو WireGuard پیروں کے درمیان تار پر واحد چیز UDP ہے، اس لیے پروٹوکول 4 کے لیے اندر آنے والا قاعدہ، وہ نمبر جو RFC 2003 IPv4-میں-IPv4 انکیپسولیشن کو دیتا ہے، نہ اندر رکھا گیا راستہ بناتا ہے نہ اسے زندہ رکھتا ہے۔ IPIP ہیڈر خفیہ کردہ پے لوڈ کے اندر رہتا ہے، جہاں کوئی کنارہ فائر وال اسے نہیں دیکھتا۔ پروٹوکول 4 کھولنا بہرحال میزبان تک ایک اور مجاز راستے کے سوا کچھ نہیں خریدتا۔
اصل پیکٹ کے ماخذ اور منزلوں کا ذکر کرنے والی پالیسی ڈی انکیپسولیشن کے بعد، سرنگ انٹرفیسوں اور روٹنگ جدول میں آتی ہے۔ اسے وہیں رکھیں اور کنارہ قاعدہ بند رہ سکتا ہے۔
WireGuard اصل میں کیا تصدیق کرتا ہے
AllowedIPs WireGuard جو پیکٹ لے کر جاتا ہے اس کے ماخذ کا فیصلہ کرتا ہے، اور یہ جو لے کر جاتا ہے وہ IPIP-انکیپسولیٹڈ پیکٹ ہے۔ مجاز IPIP ماخذ تب بھی قبول کیا جاتا ہے جب اندرونی ہیڈر ایسے میزبان کا نام لے جسے آپ روٹ نہ کرنا پسند کریں۔ اس لیے اصل ماخذ وہ نہیں جو پیر نے آپ کے لیے جانچا، اور اس اندرونی پتوں کے جوڑے کو ڈی انکیپسولیشن کے بعد اپنی تنفیذ چاہیے۔
غلاف روٹنگ ڈھانچہ دیتا ہے، دوسری کرپٹوگرافی پرت نہیں۔ WireGuard کے اندر IPIP کو اضافی تحفظ کہنا مختلف ڈیزائن بیان کرتا ہے۔
ایک ping نہیں، سیڑھی سے تصدیق کریں
آپ کے حساب کردہ کنارے کے دونوں طرف آنے والے سائز آزمائیں، پھر تصدیق کریں کہ کرنل دونوں آلات کے بارے میں کیا سمجھتا ہے۔ جب 1360 بائٹ پے لوڈ اور 40 بائٹ ہیڈر مل کر 1400 بناتے ہیں، نیچے کی پہلی بازگشت سماتی ہے اور دوسری حد سے ایک بائٹ آگے بیٹھتی ہے:
ping -M do -s 1372 10.9.0.2
ping -M do -s 1373 10.9.0.2
wg show wg0
ip -d link show ipip0حد سے نیچے صاف گزرنا اور اس سے اوپر پہلے سائز پر ناکامی کا مطلب ہے کہ حساب شروع سے آخر تک قائم ہے۔ پھر وہ منتقلی دوبارہ چلائیں جو اصل میں رکی تھی، کیونکہ مصنوعی پروب بجٹ ثابت کرتا ہے اور بھیجنے والے کے اپنے لکھنے کے سائز کے بارے میں کچھ نہیں کہتا۔ اگر اندر رکھا گیا راستہ اس سائز پر بھی ٹوٹے جو آپ نے سماتے ہوئے ثابت کیا، تو MTU سے مزید دس بائٹ کاٹنے سے پہلے دور سرے کی ڈی انکیپسولیشن اور راستے دیکھیں۔