لا يجوز تشغيل التطبيق أثناء اتصال VPN: ما الذي يفرض ذلك

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

الأسطورة: مفتاح الحماية يمنع البرامج من البدء

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

الترتيب الذي يقرر فعلاً هل يجوز أن يبدأ برنامج هو التحكم في التطبيقات. على Windows يعني ذلك AppLocker أو WDAC، وعلى macOS المُدار يعني قائمة سماح يفرضها ملف تعريف الجهاز. وكلاهما مستقل عن النفق، ولهذا يُدمَج الشرطان في تذكرة واحدة ثم لا يلبّيهما أي منهما.

سمِّ الوضع قبل أن تسمي الأداة

اكتب القاعدة كآلة حالات بثلاث حالات: الاستخدام العادي، وجلسة عمل VPN، والمغادرة. التداخل المحظور يخص الحالة الوسطى، لا برنامج العميل.

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

ما الذي يفعله التعارض ثنائي الاتجاه حقًا

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

هذه ليست قائمة منع. وصّل الاعتماد بالاتجاه المعاكس فتصبح بداية التطبيق توقف VPN بدلاً من ذلك، وهذا هو العطل الذي يجب أن تشك فيه عندما ينقطع النفق من تلقاء نفسه في لحظة متوقعة. فتطبيق سطح المكتب ليس وحدة systemd، واتصال NetworkManager ليس وحدة كذلك، لذا يعمل هذا النمط فقط مع الخدمات التي تغلّفها بنفسك.

افحص الانتقالات، لا أول تشغيل فقط

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

systemctl show work-vpn.service -p Conflicts -p After
systemctl start work-vpn.service
systemctl is-active office-sync.service
nmcli connection show --active

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

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