قفزتان عبر VPN على التوالي: من يرى حركة المرور فعلاً؟
القفزات المتسلسلة تفك التشفير وتعيده عند البوابة الأولى؛ والقفزات المتداخلة تزيل الطبقة الخارجية فقط. تتبّع التصميمين لترى أي مشغّل يقرأ ماذا.
كل ملف تعريف للعميل يسمّي خادماً واحداً، لذا من مقعد المستخدم هناك نفق واحد ومكان واحد تنتهي عنده الحماية. ما يحدث بعد تلك البوابة الأولى قرار تصميمي لا يراه العميل أبداً، والتصميمان الشائعان يتصرفان بشكل مختلف جداً عند الفحص. في السلسلة المتسلسلة تفك البوابة الأولى التشفير ثم تعيده. وفي السلسلة المتداخلة تزيل طبقة خارجية وتمرّر نفقاً داخلياً لا تستطيع فتحه. عدد القفزات متطابق في الحالتين، ولهذا يجب رسم الفرق بدل عدّه.
ابدأ من العميل وسمِّ الطرفين
ابدأ من حيث يبدأ المستخدم، في ملف الاتصال. فهو يحمل عنواناً بعيداً واحداً وطريقة مصادقة واحدة، وعندما يدعم التصميم ذلك قائمة مسارات. سمِّ ذلك النفق الخارجي من العميل إلى البوابة A وأعطه عناوين مثال: عنوان نفق العميل 10.77.0.2، وعنوان A هو 10.77.0.1، ونقطة النهاية العامة لـ A هي 198.51.100.10، مأخوذة من نطاق التوثيق TEST-NET-2 كي لا يتصادم شيء في المثال مع مضيف حقيقي.
لا يذكر ذلك الملف البوابة B، وهذا ليس عيباً. القفزة الثانية تخص A، وواجب العميل الوحيد هو إيصال حركة المرور إلى A وقبول ما يعود. أما هل تنهي A النفق أو تمرّره أو تفتح نفقاً جديداً، فهو السؤال الذي يجيب عنه بقية هذا الشرح، وهو الذي يحدد ما تستطيع A قراءته.
متسلسل: A تفك التشفير ثم تعيده
في التصميم المتسلسل تنهي A حركة المرور مرتين. تزيل الحماية عن العميل، وتحصل على حزمة IP الخاصة بالتطبيق، ثم ترسل تلك الحزمة عبر نفق ثانٍ تنشئه A نحو B. بين العمليتين تجلس الحزمة في مسار التمرير لدى A كحزمة IP عادية موجّهة إلى وجهة خاصة.
ينتج عن ذلك نتيجتان جديرتان بالقول الصريح. تستطيع A تطبيق سياسة على الحزمة الداخلية، في شكل مسارات وقواعد تصفية وتسجيل للمصدر والوجهة، ويجب أن تحتفظ A بمجموعتين من بيانات الاعتماد، واحدة كخادم للعميل وأخرى كعميل لـ B. الحماية موجودة في كل لحظة، لكن الشيء المحمي يغيّر هويته عند A.
لا يعني ذلك أن A تقرأ نص التطبيق الصريح. عندما يشغّل العميل والخدمة TLS ويتحقق كل منهما من شهادة الآخر، ترى A تدفق سجلات TLS بدل طلب مقروء. تأكيد أين تنتهي تلك الحماية يستلزم النظر إلى سلسلة شهادات الخدمة، لا إلى مخطط النفق.
متداخل: A تزيل الطبقة الخارجية فقط
في التصميم المتداخل يبني العميل نفقاً داخلياً إلى B أولاً ثم يحمل ذلك النفق داخل النفق الخارجي إلى A. تجرّد A الترويسة الخارجية، فتجد نفقاً داخلياً، وتمرّره دون أن تحمل مفاتيحه، لذا تظل الحماية الداخلية تنتهي عند B.
حينها يحمل الرابط الصاعد للعميل طبقتين، بينما يحمل المسار بين A وB طبقة واحدة. ترى A العناوين الخارجية للنفق الداخلي، وهو ما يكفي لمعرفة أن حركة المرور موجودة وإلى أين تتجه تقريباً، ولا يكفي لقراءة الحمولة. هذا هو الفرق كله عن الحالة المتسلسلة، ولا يُظهره أي عدّاد قفزات. ما تزال A قادرة عليه هو رفض تمرير ما لا تستطيع قراءته، وهو متاح دائماً لمشغّل تلك البوابة.
التداخل يكلّف مقابل تلك الخاصية. كل طبقة تضيف ترويسة إضافية، فتصبح تخطيطات MTU وMSS إلزامية بدل أن تكون ترتيباً، ويمكن لمسار يعمل بطبقة واحدة أن يُسقط حزماً كبيرة بصمت بطبقتين. كل طبقة تحتاج أيضاً إلى سلوك إعادة اتصال وإبقاء حياة خاص بها، ويبدو عطل في طبقة كخروج جزئي عبر الأخرى.
ارسم المراقبين، لا الأنفاق فقط
الأنفاق هي الجزء السهل من الرسم. المراقبون هم جوهر التصميم، لذا اكتب صفاً لكل نقطة رصد واملأ ما يستطيع كل واحد قراءته فعلاً.
| Vantage point | Serial chain | Nested chain |
|---|---|---|
| Client's access network | Outer tunnel only | Outer tunnel only |
| Operator of A | Inner IP packet between A and B | Outer addresses of the inner tunnel, not its payload |
| Path between A and B | Second tunnel | Second tunnel |
| Operator of B | Inner packet re-originated by A | Payload after the inner layer is removed |
| Service edge | Traffic from the exit address | Traffic from the exit address |
يخلط بين صفين باستمرار: مشغّل A ومزوّد نفق العميل. قد يكونان كياناً واحداً، والأسماء المنفصلة للبوابات لا تجعلهما مستقلين. الملكية المستقلة تحتاج تحكماً إدارياً منفصلاً وبيانات اعتماد منفصلة وتسجيلاً منفصلاً.
البيانات الوصفية تبقى في التصميمين. يظل التوقيت وأحجام الحزم وأعداد الاتصالات قابلة للملاحظة عند كل قفزة، لذا ترفع قفزتان كلفة الربط بدل إزالة الإشارة. التصميم الذي يعد بالاختفاء ينبغي فحصه مقابل تلك القائمة قبل أن يعتمد عليه أحد.
امشِ مسارات الفشل قبل أن تختار
اعطب الأشياء عمداً من العميل، بالترتيب الذي سيلاقيه المستخدم. ابدأ بالواجهة وMTU الخاصة بها، لأن التداخل يفشل عند حجم الحزمة قبل أن يفشل عند المصادقة بوقت طويل.
ip -4 addr show dev tun0
ip link show dev tun0 | grep mtu
ping -M do -s 1380 -c 2 10.77.1.1ثم تحقّق من نقاط نهاية الحماية بدل افتراضها. اطلب من الخدمة شهادتها من داخل أي نفق قائم، وقارن السلسلة التي يراها العميل بالسلسلة التي تعرضها الخدمة فعلاً. البوابة التي تعيد التوقيع أو تعترض تغيّر تلك الشهادة، ويصبح الفحص مرئياً بأمر واحد.
openssl s_client -connect intranet.example.com:443 -brief < /dev/nullأنهِ بمصفوفة إعادة الاتصال: يسقط نفق العميل، ويسقط نفق B، ويتغير المسار بين A وB. لاحظ ما يعود وما لا يعود، وهل يرتد اتصال داخلي يوماً إلى مسار خارج ناقله المقصود. سجّل العناوين التي استخدمها كل اختبار، لأن تكراره على شبكة وصول مختلفة يجيب عن سؤال مختلف. أعد أيضاً فحص MTU بعد كل إعادة اتصال، لأن مساراً متغيراً قد يخفض الحجم الصالح دون أن يتحرك سطر إعداد واحد.
اختر المتسلسل عندما يجب أن تطبق A سياسة على الحزمة الداخلية، أو عندما لا يستطيع العميل تشغيل نفقين متراكبين. اختر التداخل عندما يجب أن تبقى الحمولة الداخلية غير مقروءة عند A. دوّن الاختيار مع مراقبيه وأرقام MTU الخاصة به، فلن يحتاج الشخص التالي إلى إعادة رسم الصورة كاملة للإجابة عن سؤال واحد.