هل يحجب مزوّد الخدمة UDP، أم أن التطبيق داخل النفق هو السبب؟

يُبلّغ أحدهم أن الـVPN "يحجب UDP"، وهذه العبارة تخفي ادّعاءين مختلفين تمامًا. أحدهما يتعلّق بالنقل الذي تراه شبكة الوصول، والآخر بحزم التطبيق بعد فكّ تشفيرها داخل النفق. يمكن تصفية نفق مشفّر من الخارج دون أي مفتاح، ويمكن أن يفشل تطبيق UDP داخلي لأسباب لا علاقة لها بالتصفية. حدّد أي ادّعاء تختبره قبل أن تجمع الأدلة.

رأسان، كلمة واحدة

في نشر IPsec مع اجتياز NAT، تكون الحزمة الخارجية UDP موجّهة بين طرفَي الـVPN، عادةً على المنفذ 4500. وداخل ذلك تحمل الحمولة المشفّرة كل ما يمرّره النفق، وقد يكون هو نفسه TCP أو UDP. لذلك تظهر كلمة UDP مرّتين بمعنيين مختلفين ودرجة ظهور مختلفة.

ترى الشبكة الوسيطة الرأس الخارجي ولا ترى شيئًا من الرأس الداخلي. ويمكنها السماح بالتدفّق الخارجي أو تشكيله أو إسقاطه، وهي لا تحتاج إلى فكّ تشفير أي شيء لفعل ذلك. هذا التفاوت هو سبب الخلط كلّه بين الادّعاءين: الكلمة نفسها تصف ما تصفّيه الشبكة وما يرسله التطبيق. اكتب الطبقة بجوار الكلمة كلّما سجّلت نتيجة، وسيختفي الخلط في معظم الحالات.

لا يصبح الرأس الداخلي مرئيًا إلا عند الطرف المستقبِل، بعد فكّ التشفير. ومن تلك النقطة تُمرَّر الحزمة كأي حزمة أخرى، رهنًا بالمسارات والسياسات والتصفية الخاصة بالطرف نفسه. وهذه قرارات منفصلة تتّخذها صناديق مختلفة.

ما يمكن للشبكة أن تراه رغم ذلك

يُخفي التشفير الحمولة ورأس النقل الداخلي، لا حقيقة وجود تدفّق. تبقى عناوين الأطراف والمنافذ وأحجام الحزم والتوقيت مرئية، وهي كافية لتصنيف حركة المرور استكشافيًا أو لحجب وجهة معيّنة.

sudo tcpdump -ni eth0 'udp port 4500'
sudo tcpdump -ni tun0 'udp port 5201'

يُظهر الالتقاط الأول التدفّق الخارجي على الواجهة الفيزيائية، ويُظهر الثاني التدفّق الداخلي على واجهة النفق. وتشغيل الاثنين معًا يجيب عن السؤال مباشرةً: إذا وُجد التدفّق الخارجي ولم يوجد الداخلي، فإن التطبيق لم يرسل شيئًا إلى النفق أصلًا. وإذا وُجد الاثنان ولم يرجع شيء، فالمشكلة أبعد من النفق، عند الوجهة أو على مسار العودة.

RFC 3948 يحدّد تغليف UDP الخارجي، وتحدّد مواصفة ESP التخطيط المحمي داخله. ولا يَعِد أيّ من الوثيقتين بأن شبكة الوصول ستمرّر التدفّق الخارجي، ولهذا يستحقّ اختبار قابلية الوصول على الصفّ الخارجي أن يُجرى قبل أي نظرية عن الصفّ الداخلي. فالصفّ الخارجي المحجوب ينتج نفقًا لا يتشكّل أبدًا، لا نفقًا يتشكّل ثم يفقد أحد التطبيقات.

لماذا يفشل تطبيق UDP واحد داخل نفق عامل

النفق الذي يحمل تطبيق ويب ولا يحمل تطبيق UDP له تفسيرات معقولة عدّة، وتصفية مزوّد الخدمة للبروتوكول الداخلي ليست أولها. الأكثر شيوعًا هو التغطية: فالتطبيقان لا يدخلان النفق نفسه معًا، لأن مسار وجهة UDP مفقود أو لأن قواعد النفق المنقسم عند العميل تستثنيه.

الثاني هو الطرف. فخادم VPN يسمح بقائمة بروتوكولات، أو جدار ناري عند الوجهة، أو خدمة لا تستمع أبدًا على المنفذ المتوقّع، كلّها ستنتج مهلة تبدو مطابقة لحجب شبكي.

الثالث هو حجم الحزمة. فكثيرًا ما ترسل تطبيقات UDP بيانات أكبر من طلب ويب، ويقلّل التغليف حجم MTU المتاح، لذا قد يعقب مصافحة ناجحة صمت عند أول حمولة كاملة الحجم. ويسهل قراءة هذا النمط على أنه حجب، لأن الحزم الصغيرة تنجح والكبيرة تختفي. وفحص سريع لـMTU يحسم الأمر في أقل من دقيقة، والجواب عادةً حمولة أصغر أو MSS مصحّح لا مُرشِّح شبكي.

ping -M do -s 1400 -c 2 10.60.0.20
iperf3 -u -c 10.60.0.20 -p 5201 -b 1M -t 5

يختبر الأمر الأول ما إذا كانت حزمة كبيرة تنجو من المسار مع تعطيل التجزئة، وهذا يكشف مشكلة MTU بسرعة. ويرسل الثاني تدفّق UDP صغيرًا محدودًا ويبلّغ عن الفقد والتذبذب. والتدفّق الذي يبدأ ثم يتوقّف يشير إلى الحجم لا إلى الحجب.

أبلغ عن الطبقة، لا عن البروتوكول

اكتب النتيجة في أحد ثلاثة أشكال: فشل التسليم الخارجي، أو فشل التوجيه الداخلي، أو فشل التطبيق. ولكلّ منها مسؤول مختلف، وخلطها يرسل التذكرة إلى الفريق الخطأ.

تغيير منفذ محلي لا يمكن أن ينشئ مستمعًا مطابقًا في الطرف البعيد، لذا فإن حلًّا بديلًا من جهة العميل يبدو مفيدًا هو عادةً دليل على أن الوجهة الأصلية كانت خاطئة. وبالمثل، فإن ملف تعريف بديلًا مُقدَّمًا يثبت شيئًا عن قابلية الوصول ولا شيء عن صحة إعداد التطبيق.

افصل الاستنتاج عن الملاحظة أيضًا. يمكن لتحليل حركة المرور أن يقترح ماهية تدفّق ما دون فكّ تشفيره، وهذه نتيجة مفيدة، لكنها ليست الادّعاء نفسه بقراءة الرأس الداخلي. اذكر أيّهما لديك فعلًا.