أبقِ VPN على Windows متصلاً: شغّل rasdial عند حدث قطع الاتصال

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

لماذا يكون المؤقّت مشغّلاً خاطئاً

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

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

زوج الأحداث، وأيّهما يجب كتمه

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

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

Get-WinEvent -LogName Application -MaxEvents 5 -FilterXPath "*[System[Provider[@Name='RasClient'] and EventID=20226]]" | Select-Object -First 1 -ExpandProperty ToXml

يعرض XML أسماء Data الدقيقة في ذلك السجل. ErrorCode هو التهجئة المعتادة، والسجل الذي يستخدم شيئاً آخر يحتاج إلى استبدال ذلك الاسم في المرشّح أدناه.

<QueryList><Query Id="0" Path="Application"><Select Path="Application">*[System[Provider[@Name='RasClient'] and (EventID=20226 or EventID=20227)]] and (EventData[Data[@Name='ErrorCode'] != '631'] or System[EventID=20227])</Select></Query></QueryList>

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

Get-WinEvent -LogName Application -MaxEvents 40 -FilterXPath "*[System[Provider[@Name='RasClient'] and (EventID=20226 or EventID=20227)]] and (EventData[Data[@Name='ErrorCode'] != '631'] or System[EventID=20227])" | Select-Object TimeCreated,Id,Message

المشغّل الذي يطابق بصمت لا شيء يبدو تماماً كمهمة تعمل وتفشل. كلاهما يظهر كـ «الأتمتة لا تعمل»، ولا يقول أيّهما أي نصف ينقص. افحص مخرجات الاستعلام أولاً، لأنها تفصل الحالتين في خطوة واحدة.

يفشل الطلب لأن لا أحد هناك ليكتب كلمة المرور

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

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

rasdial
rasdial "Office VPN"
(Start-Process rasdial -ArgumentList '"Office VPN"' -Wait -PassThru -NoNewWindow).ExitCode

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

اقرأ رمز الخروج بدلاً من النافذة

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

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

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

أثبت مسار الاستعادة

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

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