أنفاق VPN المتداخلة: لماذا يتوقف النفق الداخلي عند الحزم الكبيرة
كل نفق يستهلك جزءًا من ميزانية حزم المسار قبل أن يبدأ التالي. اجمع الترويسات وستفشل الجلسة الداخلية عند الحزم الكبيرة.
يُحلّ DNS، وتبقى جلسة SSH قائمة، ثم يتجمّد رفع كبير بينما لا يزال ping إلى المضيف نفسه يجيب. هذا الانفصال يشير إلى حجم الحزمة لا إلى نفق معطوب. تبلغ الأنفاق المتداخلة ذلك عند أحجام لا يبلغها أي من النفقين منفردًا. الجلسة الداخلية سليمة؛ إنما تُسلَّم حزمًا لم تعد تتّسع.
أين يذهب MTU المسار فعليًا
كل تغليف يستهلك بايتات قبل أن تحصل الطبقة التالية على دورها. مسار Ethernet يقدّم 1500 بايت للحزمة الخارجية، ويأخذ النفق الخارجي نصيبه قبل أن يمكن عنونة أي شيء داخله. أي قيمة تقديرية واحدة للحمولة الإضافية ستكون خاطئة بالمقدار الذي يهم بالضبط.
اسرد الطبقات بالترتيب: مسار الوصول، والنقل الخارجي، والنفق الخارجي، والنقل الداخلي، والنفق الداخلي، والتطبيق. احسب كل ترويسة مرة واحدة، وافصل UDP عن ترويسة النفق ووسمه.
طبقتا WireGuard، محسوبتان مرة واحدة
خذ مسار وصول IPv4 مع نفق WireGuard داخل آخر. تكلّف الطبقة الخارجية 20 بايت من IPv4 و8 من UDP و32 لترويسة بيانات WireGuard مع وسم المصادقة. وداخل ذلك، يحتاج النفق الداخلي إلى ترويسة IPv4 خاصة به من 20 بايت وترويسة UDP من 8 بايت قبل 32 بايت ثانية من حمولة WireGuard. وما يتبقى يحمل ترويسة IPv4 وترويسة TCP والبيانات. ومسار IPv6 خارجي يكلّف 40 بدلًا من 20 ويترك 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 بايت. طبقة واحدة بالقواعد نفسها تترك 1400 لحمولة TCP، أي 1500 ناقص 20 و8 و32 و20 و20، والفرق البالغ 60 بايت هو بالضبط التغليف الداخلي الذي يضيفه النفق الثاني.
طبّق 1400 على مسار متداخل ويصبح النفق الداخلي ناقصًا 60 بايت، وهو أمر غير مرئي حتى تصبح الحزمة كبيرة بما يكفي لاحتياجه. الحشو وخيار التجزئة الخاص بالبروتوكول يحرّكان الأرقام مرة أخرى، لذا ثق بالجدول.
MTU وMSS والتجزئة تعمل في مواضع مختلفة
يحدّ MTU الواجهة مما ستُصدره الواجهة، بينما يغيّر تثبيت MSS في TCP ما يرغب نظير TCP في إرساله. التثبيت يصلح جلسات TCP ولا يفعل شيئًا لحزمة UDP كبيرة، وهكذا يبدو الإصلاح ناجحًا لتطبيق ويخطئ التطبيق التالي بصمت. وخيار التجزئة الخاص بالبروتوكول هو رافعة ثالثة بفشلها الخاص. وMTU الواجهة هو الخطوة الأولى الشائعة وأكثرها بلادة.
الأنفاق الجسرية والموجّهة تحمل أطرًا مختلفة، لذا نادرًا ما تنتقل الأرقام من نشر آخر. اكتشاف MTU المسار، الموصوف في RFC 8201، لا يساعد إلا ما دامت رسائل ICMP التي يعتمد عليها مسموحًا بمرورها.
إيجاد الطبقة الناقصة
تحقّق من كل نفق على حدة قبل تداخلهما، إن كانت المتطلبات تسمح بمقارنة. مسبار بحجم ثابت يحسم الأمر: ping -M do -s 1472 -c 3 10.8.0.1 يرسل حزمة IPv4 كاملة من 1500 بايت داخل تلك الطبقة. أضف الطبقة الثانية وكرّر المسبار نفسه، حتى ينتمي أي فشل إلى تغيير معروف.
عندما يتوقف نقل، غيّر معاملًا موثّقًا واحدًا في كل مرة وسجّل الحجم الفاشل. افحص مسار العودة أيضًا، لأن التكرار المتداخل للمسارات قد يحاكي مشكلة حجم الحزمة بدقة تكفي لتكلفك بعد الظهر. وردّ ICMP المفلتر قد يخفي الحد الحقيقي، لذا المسبار أهم من الاستدلال.
اكتب الميزانية حيث سيجدها الشخص التالي
جدول بصف لكل طبقة يعيش أطول من قاعدة عامة. احتفظ به بجانب مخطط النفق حتى لا يعيد أحد الحساب تحت الضغط.
المزيد من الأنفاق يعني مزيدًا من التبعيات، لذا تستحق خطة التراجع مكانها بجانب الميزانية. إن لم تتطابق الأرقام، فقِس المسار بدلًا من التخمين مرة أخرى. الهدف رقم تستطيع الدفاع عنه، لا رقم تتذكره.