تعيين الأقراص قبل جهوزية VPN؟ اجعله مشروطًا بالخادم

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

لماذا يعمل التعيين مبكرًا جدًا

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

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

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

حالة متصل ليست مسارًا

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

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

فحص جهوزية يسمّي الخادم الذي تحتاجه فعلًا يميّز بينها، لأنه يفشل حتى يعمل المسار المحدد، لا حتى تبلغ واجهة ما عن نفسها بأنها متصلة.

اعتمد على الخادم، لا على العميل

اختر مضيفًا واحدًا لا يمكن الوصول إليه إلا عبر النفق وانتظره قبل تعيين أي شيء. المقطع أدناه يتصل بمدخل VPN محفوظ في Windows، ويستقصي خادم الملفات، ثم يعيّن القرص.

@echo off
set server=fileserver.corp.example
rasdial "Office VPN" /disconnect
rasdial "Office VPN"
:wait
ping -n 1 -w 1000 %server% >nul || (
  timeout /t 5 /nobreak >nul
  goto wait
)
net use Z: \\%server%\share /persistent:no

الـ ping مسبار جهوزية، لا اختبار أذونات. إذا كانت ICMP مفلترة على شبكتك، فاستقصِ الخدمة التي تستخدمها فعلًا بدلًا من ذلك: net view \\%server% لفحص سريع، أو اختبار TCP قصير على المنفذ 445 في PowerShell. أي منهما يعتمد على الشيء المهم.

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

اجعله قابلًا لإعادة التشغيل ومراعيًا للجلسة

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

افحص قبل أن تعيّن، واحذف المدخل القديم فقط. net use Z: /delete يعيد خطأً عندما يكون الحرف غير مستخدم، وهذا الخطأ آمن للتجاهل بدلًا من أن يكون سببًا للتخلي عن بقية السكربت. أبقِ /persistent:no حتى لا تتحول محاولة فاشلة لاحقًا إلى محاولة إعادة اتصال دائمة.

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

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

سجّل ما يكفي لإثبات أي النصفين كان متأخرًا

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

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

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