أتمتة L2TP على Android: السكربت يطلب ولا يبني

الأسطورة أن L2TP على Android مجرد شيء آخر يمكن لسكربت أن يشغله: أضف مسارًا، نادِ الخدمة القديمة، انتهيت. هذا غير ممكن، لأن أربع طبقات مختلفة يجب أن تتفق قبل أن ينقل النفق حزمة واحدة. طبقة IPsec تحمي المسار، وL2TP تحمل الجلسة، وPPP تتفاوض على الرابط، وعلى Android أن يسجل النتيجة كشبكة VPN يمكن التوجيه حولها. حاولت هذا مرتين بأوامر منسوخة، وفي المرتين كان المسار موجودًا بينما لم يكن هناك أي تشفير.

ما الذي يفعله تغيير المسار فعلاً

إضافة مسار تحدد إلى أين تذهب الحزمة تاليًا. إنها لا تتفاوض على ارتباط أمني، ولا تفتح جلسة L2TP، ولا تنفذ تبادل PPP الذي ينتج عنوانًا ونظيرًا وإعدادات DNS. على الهاتف يكون الناتج المرئي مرورًا يخرج من المسار الخطأ، أو يخرج ويموت، دون أي حالة نفق.

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

أربعة مالكين، والسكربت ليس واحدًا منهم

خذها بالترتيب. IPsec ينشئ المسار المحمي ويصونه ويوثق النظراء. L2TP يحمل الجلسة فوقه، وهذا الترتيب هو سبب تعامل المعيار معهما كآليتين منفصلتين لا كبروتوكول واحد. وداخله يتفاوض PPP على معاملات الرابط التي سيستخدمها العميل. ثم يملك Android الجانب الخاص بالمنصة: واجهة VPN المسجلة، ونطاق كل تطبيق، وحالة التشغيل الدائم، ودورة الحياة التي تقرر ما يحدث عند قتل التطبيق.

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

لماذا لا يكون البرنامج الخفي طريقًا مختصرًا أيضًا

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

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

كيف تبدو المسارات المدعومة

إذا كان بإمكان المؤسسة الانتقال إلى ملف تعريف يوفره Android نفسه، فمسار المنصة هو الخيار الصادق. منذ API 30، VpnManager يدعم توفير ملفات تعريف VPN المنصة والتحكم بها من التطبيقات، مع سير عمل تصريح مرتبط بالتطبيق المستدعي. وهو ليس محول L2TP: نموذج ملف التعريف الذي يوفره لـIKEv2 لا يترجم إعداد L2TP قائمًا، ونقل البروتوكول هو هجرة لا إعادة تسمية. يجب نقل الهويات والمسارات وDNS الخاص وأذونات الوصول عن قصد.

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

ما تفعله الأتمتة الصحيحة

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

اكتب أي مكون يملك كل طبقة قبل كتابة السطر الأول، ثم افحص النتيجة على ذلك:

• يتولى العميل IPsec وPPP، لا مسارات السكربت.
• يظهر الاتصال في حالة VPN الخاصة بالمنصة، فيسري عليه نطاق كل تطبيق والتشغيل الدائم.
• لا يحمل أي استدعاء خدمة داخلي أو رقم معاملة أو وسيط مخمن أي بيانات اعتماد.
• الفشل في أي خطوة لا يترك ملف تعريف نصف مسجل.