IPIP داخل WireGuard: العشرون بايتًا الإضافية التي لم يحسبها أحد
يكلّف IPIP عشرين بايتًا إضافية داخل WireGuard. احسب الميزانية في الطبقة الصحيحة قبل أن تلوم التجزئة على نقل متوقف في نفق حيّ.
تعبر الرنّات الصغيرة النفق طوال اليوم، ويصل لافت SSH، ثم تتجمد الجلسة في اللحظة التي يبدأ فيها نقل ملف. تشير هذه الصورة إلى ميزانية بايتات محسوبة في الطبقة الخطأ، حيث قُدّر النفق الخارجي بعبئه الخاص ولم يخصم أحد النفق الداخلي. حزمة IPIP المتداخلة ليست إلا حزمة IP أخرى بقدر ما يهم WireGuard، ولهذا بالضبط تستهلك بايتات لم تحجزها قط. التصحيح حسابي، ويتسع لثلاثة أوامر وجدول واحد.
العَرَض الذي يفضح الأمر
تُعلن مشاكل التجزئة عن نفسها بالحجم، لا بالعناوين أبدًا. يستجيب نظيرك لـ ping بحجم 56 بايت لمدة ساعة ثم يصمت عند 1400 بايت بينما يبقى النفق قائمًا ولم يتغير أي مسار. تتسع المصافحة، ولا تتسع نافذة TCP الكاملة الأولى، فيتوقف النقل بعد ثوانٍ من ظهوره سليمًا.
قِس السقف قبل أن تعدّل أي شيء، لأن السقف غير المقيس هو سقف ستطارده مرتين. أرسل مسبارًا واحدًا تحت الحجم المشتبه به مع تعيين بت منع التجزئة، ping -M do -s 1000 10.9.0.2، ثم كرّره بحجم تعرف مسبقًا أنه كبير جدًا. عندما يتبع الانقلاب حجم الحمولة بينما تبقى الوجهة دون تغيير، فالتوجيه يؤدي عمله ورأس واحد ناقص من الميزانية.
عُدّ كل رأس مرة واحدة، في الطبقة الصحيحة
ابدأ من أصغر MTU على المسار بدلًا من واجهة النفق، لأن الجدار يقع أعلى المصدر من كلا الطرفين. ينفق WireGuard 60 بايت على نقل خارجي IPv4، موزعة 20 لـ IP و8 لـ UDP و32 لرأسه الخاص، و80 بايت عندما يكون ذلك النقل IPv6. يحتفظ wg0 بحجم 1420 بايت بـ 20 بايت من الهامش تحت 1440 التي يمكن لمسار بحجم 1500 أن يوصلها فعلًا، ولهذا يظل الرقم المنسوخ من ويكي مناسبًا هنا. ارسم المكدس كاملًا على المخطط، لأن من سيغيّر 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. لا شيء آخر ينتمي إلى ذلك الطرح. لقد أُنفق عبء WireGuard بالفعل عندما اخترت 1420، وتحصيله مرتين ينتج نفقًا يعمل بشكل مثالي ويظل بطيئًا ما دام لا أحد يقيسه. النشر الذي يحمل فيه كلا الجهازين 1400 مستديرًا هو بصمة ذلك الخطأ بالضبط.
IPv6 على أي جانب من الحزمة المتداخلة يبطل كل رقم أعلاه، لذا أعد الحساب بدلًا من نسخ رقم من موقع مشابه. الرؤوس المطروحة 40 بايت لكل منها بمجرد ظهور IPv6 في المسار الخارجي أو في مخطط البيانات الأصلي، ورقم الحمولة ينخفض بالمقدار نفسه تمامًا.
قاعدة الجدار الناري التي على الأرجح لا تحتاجها
بين نظيري WireGuard، الشيء الوحيد على السلك هو UDP، لذا فإن قاعدة واردة للبروتوكول 4، وهو الرقم الذي يخصصه RFC 2003 لتغليف IPv4 داخل IPv4، لا تنشئ المسار المتداخل ولا تُبقيه حيًا. يعيش رأس IPIP داخل الحمولة المشفرة، حيث لا يراه أي جدار ناري طرفي. فتح البروتوكول 4 مع ذلك لا يشتري شيئًا يتجاوز مسارًا مسموحًا آخر إلى المضيف.
السياسة التي تذكر مصادر الحزمة الأصلية ووجهاتها تنتمي إلى ما بعد فك التغليف، على واجهات النفق وفي جدول التوجيه. ضعها هناك ويمكن لقاعدة الطرف أن تبقى مغلقة.
ما يتحقق منه WireGuard فعلًا
AllowedIPs يحكم على مصدر الحزمة التي يحملها WireGuard، وما يحمله هو الحزمة المغلفة بـ IPIP. يُقبل مصدر IPIP مسموح حتى عندما يسمّي الرأس بالداخل مضيفًا تفضّل ألا توجه إليه. لذا فإن المصدر الأصلي ليس ما تحقق منه النظير لأجلك، وذلك الزوج الداخلي من العناوين يحتاج إلى تطبيقه الخاص بعد فك التغليف.
الغلاف يوفر بنية توجيه، لا طبقة تشفير ثانية. وصف IPIP بأنه حماية إضافية داخل WireGuard يصف تصميمًا مختلفًا.
تحقق بسلم، لا برنة واحدة
اختبر أحجامًا تلامس الحد الذي حسبته، ثم أكّد ما تعتقده النواة بشأن كلا الجهازين. مع 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.