لماذا لا يصلح VPN ساعة الحاسوب المحمول المنضم إلى النطاق

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

المسار ليس ساعة

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

هذه الاعتماديات الثلاث مستقلة عن النفق. فإقامة VPN تغيّر إمكانية الوصول، وإمكانية الوصول هي ما يتيح للجهاز إيجاد مصدر للوقت؛ وهي ليست المصدر.

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

حدّد من يملك الوقت في النطاق

عادةً تتبع أعضاء Windows المنضمون إلى النطاق التسلسل الزمني لـ Active Directory بدلًا من استعلام خادم عام في كل مرة. وينتهي هذا التسلسل عند محاكي PDC لجذر الغابة، الذي يُعد مرجعه المصدر الموثوق للمؤسسة.

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

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

اقرأ ما يستخدمه الجهاز فعليًا

يُوثّق أمران للقراءة فقط الحالة الراهنة على جهاز Windows مُدار، ويستحق تسجيلهما قبل التغيير وبعده:

w32tm /query /source
w32tm /query /status
w32tm /query /configuration

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

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

حدّد ما يحدث أثناء التجوال

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

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

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

افصل سياسة الأعضاء عن المرجع

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

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