أطفئ الـ Mac بعد عمل الـ VPN، لا قبله

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

المقارنة أدناه بين «النفق أولًا» و«العمل أولًا»، لأن هذا الاختيار وحده يفسر معظم النتائج السيئة.

ترتيبان للإطفاء، نتيجتان

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

العمل أولًا أبطأ ببضع ثوانٍ وأهدأ بكثير. تكتمل العملية الخاصة، وتُفصل المشاركة عمدًا، وعندها فقط يختفي النفق. الإطفاء التالي لم يبقَ له ما يقاطعه.

لماذا يجب أن تذهب المشاركة قبل النفق

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

افصل عبر الإجراء المدعوم بعد توقف نشاط الملفات. في macOS هذا هو زر الإخراج في Finder أو أمر diskutil unmount متعمد لنقطة التثبيت، لا قطع الاتصال بالشبكة تحته. ثم أكد في الشريط الجانبي أن المشاركة اختفت قبل لمس الـ VPN.

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

أوقف العميل الذي يملك الجلسة

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

راقب الاستعادة التلقائية. قد تبدأ قاعدة On Demand أو ملف تعريف مُدار الاتصال من جديد بعد ثوانٍ من إيقاف متعمد، وهو ما يبدو كأن العميل يتجاهل الأمر. هذا السلوك سياسة وليس خللًا، ويجب حله مع من يملك السياسة بدلًا من محاربته بمساعد لا يكف عن قطع الاتصال.

بعض العملاء يفصلون بين «طُلب قطع الاتصال» و«اكتمل التفكيك». إذا كانت سير العمل تنتظر الاكتمال، فاقرأ حالة العميل نفسه وأعطه مهلة محدودة. انتظار ثانية واحدة بشكل عشوائي ليس انتظارًا، وقتل كل عملية باسم يشبه الـ VPN ليس تفكيكًا.

اترك إطفاء نظام التشغيل وشأنه

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

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

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

ضع المهلة في الخطة

إذا كان الـ Mac يجب أن يكون مطفأً في وقت محدد، فابدأ التحضير ما دامت جلسة المستخدم حية. الانتظار حتى الدقيقة الأخيرة للتنظيف هو الطريق الذي يتحول فيه طلب MFA أو كتابة غير مكتملة أو تثبيت عنيد إلى حادث. أعطِ التسلسل وقت بداية، لا وقت نهاية فقط.

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

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