AD Sites وSubnets: ليش جهازك يختار وحدة تحكم بعيدة، وكيف تراجع الاختيار بدون تغيير الشبكة؟

جهاز في فرع الرياض يتعامل مع DC موجود في موقع آخر، وتسجيل الدخول صار أبطأ من المتوقع. أول تفسير قد يكون «DNS غلط»، لكن اختيار وحدة التحكم يعتمد أيضًا على تعريف المواقع والشبكات ودور الخدمة المطلوبة وحالتها. لو ركزت على اسم الخادم فقط، قد تفوتك طريقة ربط عنوان العميل بالموقع.
بنراجع AD Sites وSubnets بقراءات محددة في مختبر مصرح: عنوان العميل، تعريف شبكته في الدليل، موقعه المتوقع، والوحدة التي رجعت من الاكتشاف. الهدف فهم الاختيار وتوثيقه، وليس إجبار العميل على خادم معين أو تعديل تكلفة روابط المواقع أثناء الفحص.

الموقع في AD يمثل تصميمًا، مب اسم مدينة فقط

يمكن أن تسمي موقعًا Riyadh-Lab وآخر Branch-Lab، لكن الاسم لا يصنع العلاقة تلقائيًا. تعريف الشبكات المرتبطة بكل موقع هو جزء من كيفية تصنيف الأجهزة. موقع باسم الرياض لا يعرف كل عنوان يوجد جغرافيًا في الرياض من تلقاء نفسه، ولا يعني أن كل جهاز يحمل وصف الفرع صار ضمنه.
توثيق Microsoft يوضح أن كائنات Subnet تمثل نطاقات عناوين وتُربط بكائنات المواقع، وأن DC Locator يستخدم معلومات عنوان شبكة العميل في تحديد موقعه. هذه هي نقطة البداية للمراجعة: قارن الشبكة الفعلية مع التعريف الموجود، ثم افهم الوحدة التي اختيرت. لا تبدأ بنقل خادم بين المواقع لأن اسمه يبدو غير مناسب.
في المختبر، خذ CLIENT01 بعنوان تدريبي مثل 10.20.30.25 ضمن شبكة 10.20.30.0/24. المثال لا يمثل شبكة مستخدم حقيقي. إذا كانت الشبكة في الدليل مرتبطة بـBranch-Lab، فهذه معلومة تصميمية تحتاج مقارنتها مع موقع الاختبار المتوقع. لا تخلطها مع اسم OU التي تضم كائن الكمبيوتر.
OU تنظم كائنات الدليل وتدخل في سيناريوهات إدارة وسياسات، بينما Site يرتبط بتصميم مواقع وشبكات واختيار خدمات. نقل كائن الكمبيوتر إلى OU باسم Riyadh لا يغير تلقائيًا موقعه الشبكي. هذه نقطة عملية تمنع معالجة مشكلة اختيار DC بإجراء لا يستهدف الطبقة المناسبة.

اجمع عنوان العميل الفعلي ومسار اتصاله

ابدأ من الجهاز الذي ظهرت عليه المشكلة، لا من جهاز الإدارة. اقرأ عنوان الواجهة المستخدمة وقناعها أو PrefixLength وخادم DNS ومسار الاتصال باللاب. وجود عدة واجهات أو VPN يجعل وصف «الجهاز في الفرع» غير كافٍ؛ قد تكون اتصالاته للدومين من عنوان مختلف عن الذي تتوقعه.
في Windows يمكنك مراجعة Get-NetIPConfiguration لعرض التهيئة الحالية، ثم تحديد الواجهة ذات الصلة بالتجربة. الناتج قد يحتوي أكثر من واجهة؛ لا تختَر أول عنوان وتبني عليه تفسير الموقع. قارنه مع مسار الوصول الذي يستخدمه التطبيق أو اكتشاف الدومين، واطلب توضيحًا من فريق الشبكة عند وجود ترجمة أو وسيط.
لا تجعل عنوانًا في وصف كائن الكمبيوتر دليلًا على عنوان اليوم. الجرد قد يكون قديمًا، وبعض أجهزة المختبر تتغير عناوينها مع تشغيل شبكات افتراضية. اكتب وقت القراءة وحالة VPN أو الشبكة المستخدمة. هذه التفاصيل مهمة عند مقارنة تجربة نجحت في المكتب وفشلت بعد اتصال مختلف.
قبل أي تعديل، احفظ الحالة. تغيير DNS أو فصل واجهة أو تبديل شبكة قد يجعل النتيجة الجديدة تعمل لكنه يخفي سبب السابقة. فحص القراءة يريد تحديد السبب، والمعالجة لها خطة منفصلة. إذا كان المختبر بسيطًا، هذا لا يلغي فائدة حفظ سطرين عن الوضع الأول قبل الانتقال.

اقرأ تعريف Subnet ثم اربطه بالموقع

في جهاز إدارة RSAT مصرح، أمر مثل Get-ADReplicationSubnet -Identity '10.20.30.0/24' -Server dc01.lab.test -Properties Site | Select-Object Name,Site,DistinguishedName يقرأ كائن شبكة التدريب المحدد. الهدف معرفة هل يوجد التعريف المقصود وأي موقع يرتبط به، وليس إنشاء تعريف جديد.
إذا لم يجد الأمر الكائن، لا تستنتج أن عنوان العميل لا يطابق أي شبكة في الدليل. قد تكون هناك شبكة أوسع أو تعريفات أخرى تحتاج مراجعة مناسبة. البحث باسم Prefix بعينه يجيب عن ذلك الكائن، ولا يراجع كل احتمالات المطابقة. اطلب قائمة محدودة من صاحب الدليل وفق نطاق الشبكات التي تخص المشروع.
انتبه لحساب النطاق. عنوان 10.20.30.25 ليس اسم شبكة /24، وتعريف Prefix خاطئ قد يضم عناوين أكثر أو أقل مما تقصده. لا تستخدم نص عنوان جهاز مع قناع محفوظ ثم تعتبره تصميمًا صحيحًا. راجع الشبكة والنطاق والموقع مع الجرد المعتمد قبل الحكم.
إذا توجد تعريفات متداخلة في البيئة، لا تختصر التفسير إلى «هناك أكثر من Subnet إذن خطأ». تحتاج مراجعة قواعد المطابقة والتصميم الحالي والقراءة الفعلية مع الفريق المختص. السطر المهم في التقرير هو الرابط الذي ثبتت علاقته بالعميل، والسبب الذي يجعل الموقع مختلفًا عن الحاجة، لا مجرد كثرة التعريفات.

ما الذي اختاره DC Locator من هذه الجلسة؟

يمكن أن تقرأ اكتشاف وحدة تحكم في مختبرك بأمر nltest /dsgetdc:lab.test، وتسجل الوحدة ومعلومات الموقع المعروضة. هذا طلب اكتشاف له سياقه وقد يتأثر بمعلومات مخزنة. لا تعمم اسمًا رجع في هذه اللحظة على كل التطبيقات وكل الاتصالات طوال اليوم.
مرجع DC Locator يشرح استخدام DNS ومعلومات الموقع، مع تخزين معلومات الوحدة لتجنب اكتشاف متكرر. لهذا لا تتوقع أن كل طلب متتابع يعطي اختيارًا جديدًا. كذلك لا تمسح بيانات أو تجبر إعادة الاكتشاف أثناء فحص إنتاج بلا معرفة الأثر؛ اختر اختبارًا مخططًا إذا كانت الحاجة مقارنة حالة جديدة.
إذا كان تطبيقك يحدد DC صراحة، فقد لا يعتمد على نفس الاكتشاف الذي تقيسه. راجع إعداد التطبيق دون نسخ أسراره، واسأل هل الخادم المكتوب ثابت أو نتيجة اكتشاف. استعلام nltest الناجح لا يثبت أن تطبيقًا بإعداد ثابت سيغير وجهته تلقائيًا.
في ورقة العمل ضع عمودًا للموقع المتوقع وفق التصميم، وعمودًا لما ظهر في قراءة الاكتشاف، وعمودًا للوجهة الفعلية للتطبيق إن كانت معروفة. لا تدمج الثلاثة في اسم واحد. هذه المقارنة تساعدك تعرف هل المشكلة تصنيف العميل أو توفر الخدمة أو اختيار التطبيق، بدل التركيز على أي خادم بعيد ظهر في لقطة.

راجع الخدمة المطلوبة، مو أقرب خادم من ناحية الاسم

قد يحتاج الطلب KDC أو Global Catalog أو وحدة قابلة للكتابة وفق وظيفة محددة. إذا كان موقع العميل يحتوي وحدة لا تحقق الحاجة أو غير متاحة، قد يكون الاختيار من موقع آخر له تفسير مشروع. لا تعتبر أي انتقال خارج الموقع دليلًا أن تصميم Sites غلط.
في قراءة إدارة مناسبة، Get-ADDomainController -Identity dc01.lab.test يعرض كائن الوحدة وخصائصها الأساسية، ويمكن اختيار الحقول ذات الصلة مثل HostName,Site,IsGlobalCatalog,IsReadOnly. هذه بيانات دور وتصميم، وليست فحصًا حيًا لكل خدمة. تحتاج مقارنة الحالة التشغيلية عندما يتوقف السؤال عليها.
خلنا نفترض أن تطبيق دليل يبحث في GC بينما الطلب الآخر يحتاج وظيفة مختلفة. المقارنة بينهما قد تعرض وجهات مختلفة دون أن تكون متناقضة. أول سؤال هو ما الخدمة التي طلبها كل مسار، وهل اعتمد اكتشافًا أم وجهة صريحة. لا تختَر وحدة لأن زمن ping إليها أقل ثم تقول إنها المناسبة لكل شيء.
النقطة المهمة أن «قريب» في تصميم AD ليس مجرد أقصر زمن ظهر لك في تجربة واحدة. الموقع والتوفر ومتطلبات الطلب وتصميم الروابط تدخل في الصورة. لا تحول قياسًا لحظيًا إلى قرار تغيير مواقع، لكن استخدمه كإشارة تساعد الفريق يراجع سبب اختلاف النتيجة عن التصميم المتوقع.

Site Link يمثل علاقة تصميم، وليس خط مرور الحزم

قد ترى رابطًا بين موقعين في AD Sites and Services وتتخيل أن كل حزمة من الفرع تمر في خط مشابه تمامًا. وثائق مفاهيم التكرار تميز هذا التصميم عن المسار الفيزيائي الفعلي للشبكة. لذلك لا تستخدم أسماء روابط المواقع كبديل عن مراجعة التوجيه والاتصال الحقيقيين.
إذا كان الربط المنطقي يقول إن موقعين متصلان، لكن الاتصال الفعلي لا يسمح بالتدفق المطلوب، يحتاج الفريق مراجعة اتساق التصميم والشبكة. وإذا الشبكة تصل سريعًا لكن تعريف العميل مرتبط بموقع غير مقصود، تكون هناك مسألة تصنيف مختلفة. هاتان مشكلتان يمكن أن تظهران بنفس شكوى «الدومين بطيء».
لا تغيّر Cost أو Schedule أثناء فحص محدود لأنك تريد وحدة أخرى في النتيجة. هذه إعدادات لها أثر على علاقات أوسع، وقد تعالج عرضًا وتخلق مشكلة في مكان آخر. حدد الاختلاف المثبت ثم اقترح مراجعة يملكها فريق الدليل بالتعاون مع الشبكة.
في مختبر تدريب، تستطيع دراسة التصميم الموجود أو بناء مثال جديد وفق تعليماته، لكن سمِّ الفرضيات بوضوح. لا تنسب جدولًا زمنيًا أو تكلفة مثالية لكل البيئات. قيمة التمرين أن تشرح كيف تؤثر المعلومات المرتبطة، وأن تعرف ما الذي تحتاج قياسه قبل أي تغيير.

سيناريو: VPN أعطى العميل شبكة غير معرفة

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

بطء تسجيل الدخول ليس كله اختيار DC

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

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

الدليل المطلوب للتوصية وإعادة الفحص

التوصية المفيدة تسمي شبكة العميل التي ثبتت، وتعريف Subnet المقروء، والموقع المتوقع وفق تصميم معتمد، والوحدة التي ظهرت من القراءة المحددة. أضف الوقت ونقطة التنفيذ والخدمة المطلوبة. بهذا يقدر الفريق يراجع الرابط بدل تلقي عبارة «خلوه يختار DC أقرب» بلا دليل.
إذا كان الفرق متوقعًا بسبب توفر خدمة أو تصميم فرع، سجله كمعلومة لا كثغرة. وإذا ثبت تعريف غير مناسب، حدد أثره الذي قسته أو ما يحتاج تقييمًا. لا تطلب تغييرًا واسعًا لكل المواقع لأن جهاز تدريب واحد أعطى نتيجة مختلفة، ولا تكتب ضمانًا بأن تصحيح Subnet يعالج كل تطبيق.
إعادة الفحص تشمل قراءة التصميم الحالي، وقراءة اختيار مناسبة بعد التغيير وفق الخطة، وتجربة الوظيفة ذات الصلة. إذا كانت البيانات مخزنة أو التغيير لم يصل إلى المصدر، راجع ذلك كطبقة مستقلة مع الفريق. لا تكرر تعديل التعريف كي تجبر النتيجة الفورية.
المراجع: DC Locator https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/dc-locator وتصميم Sites وSubnets https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/creating-a-site-design وGet-ADReplicationSubnet https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-adreplicationsubnet وGet-ADDomainController https://learn.microsoft.com/en-us/powershell/module/activedirectory/get-addomaincontroller ومفاهيم التكرار https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/replication/active-directory-replication-concepts . اقرأ العلاقة بين العميل والموقع والخدمة، ثم اختر الاستنتاج الذي تدعمه البيانات.