شبكة VPN متداخلة: أي نفق يحمل الاتصال الخارجي؟

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

ثلاثة شروط تحدد التداخل

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

الثاني هو ما إذا كنت ترى المسار في كل طبقة. إذا لم تستطع سؤال النواة أي مسار سيستخدم هدف معين، فأنت تستنتج السلسلة من عنوان IP خروج نهائي، وهذا بالضبط الدليل الذي لا يستطيع التمييز بين التداخل والمصادفة.

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

الشرط الأول: أي نقطة نهاية تحتاج أي مسار

ip route get 203.0.113.10 يجيب عن ذلك السؤال مباشرة: يطبع المسار وعنوان المصدر والواجهة التي ستستخدمها النواة لذلك الهدف الآن.

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

الشرط الثاني: افحص المسار في كل طبقة

اختيار المسار أكثر من الجدول الرئيسي في عميل حديث. يمكن لقواعد السياسة إرسال حزم موسومة إلى جدول آخر، ويمكن للعميل ربط مقبسه بواجهة، وللحاوية أو فضاء الأسماء جداول خاصة به. ip rule و ip route show table all هما الطريقة لمعرفة أي هذه الآليات مطروح.

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

الشرط الثالث: ما يحدث عندما يسقط النفق الخارجي

سلوك الفشل يحتاج إلى قرار، لا إلى قيمة افتراضية. اكتب ما ينبغي أن يحدث للنفق الداخلي عندما يختفي الخارجي، ثم اجعل العملاء يفعلون ذلك.

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

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

ما لا تعطيك إياه السلسلة

الطبقات الإضافية تضيف نقاط نهاية ومفاتيح وأوضاع فشل؛ وهي لا تضيف أي ضمان لإخفاء الهوية ولا تمنع المشغل الخارجي من رؤية أن نفقًا موجود. أي ادعاء بشأن ما يحمي منه التداخل يجب أن يسمي المراقب الذي يحمي منه.

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