يبدأ RRAS قبل أن يكون نفق OpenVPN جاهزًا عند الإقلاع

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

كيف تبدو الأعراض عند إقلاع بارد

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

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

الاعتمادية المضافة استنادًا إلى «أنها تعمل بعد إعادة التشغيل» لا تؤجّل العطل نفسه إلا بقدر ما تستغرقه خدمة الشرط المسبق للإبلاغ عن RUNNING. وهي أيضًا تجعل الإقلاع أصعب في الفهم، لأن قيد الترتيب يبدو الآن تفسيرًا. اسأل ما الكائن الذي تضمنه الاعتمادية وهل ذلك الكائن هو ما لم يستطع RRAS رؤيته.

سمِّ المورد، لا الخدمة فقط

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

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

Get-Service | Where-Object Name -match 'vpn|openvpn' | Select-Object Name, Status, StartType

اقرأ سلسلة الاعتمادية قبل أن تضيف إليها

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

Get-Service -Name RemoteAccess | Select-Object Status, StartType
sc.exe qc RemoteAccess
Get-Service -Name RemoteAccess | Select-Object -ExpandProperty DependentServices

سطر DEPENDENCIES من sc.exe qc هو القائمة التي يجب أن تحافظ عليها، لأن sc.exe config RemoteAccess depend= يستبدل القائمة بأكملها بدلًا من الإضافة إليها. إسقاط شرط مسبق غير ذي صلة أثناء إضافة خدمة VPN ينشئ عطلًا ثانيًا يظهر عند إقلاع مختلف، وتشخيصه أصعب بكثير من العطل الأصلي. انسخ القائمة الموجودة إلى سجل التغييرات قبل أن تلمسها.

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

اجعل إعادة التشغيل مشروطة، لا مرتبطة بمؤقّت

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

Get-NetAdapter | Where-Object Status -eq 'Up'
Get-NetRoute -DestinationPrefix 0.0.0.0/0
Get-WinEvent -LogName System -MaxEvents 40 |
  Where-Object ProviderName -eq 'Service Control Manager'

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

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

سجّل الانتقال حتى يفسّر الإقلاع التالي نفسه

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

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