عزل لاب Active Directory: الفرق بين NAT وHost-only وInternal بدون خلط

تشغل اللاب، وتلاحظ أن جهاز ويندوز التدريبي أخذ عنوانًا من شبكة البيت. أول سؤال هنا ما هو هل وصل الإنترنت؛ السؤال: هل الجهاز موجود في الشبكة اللي خططت لها أصلًا؟ إذا بنيت دومين للتجارب، تحتاج تعرف أين تصل اتصالاته، ومن يستطيع الوصول إليه، وكيف تفحص ذلك بدون تجربة عشوائية على أجهزة خارج اللاب.
اختيار شبكة افتراضية خطوة من تصميم بيئة التعلم، وليس خيارًا تضغطه حتى تنجح أداة. أسماء NAT وHost-only وInternal وPrivate متشابهة في الشروحات، لكنها ما تعني الشيء نفسه في كل منصة. بنفصل المعاني الأساسية، ثم نبني طريقة مراجعة بسيطة لجهازك المضيف والضيوف. الهدف لاب مفهوم الحدود تستطيع إعادة استخدامه، لا شبكة كبيرة يصعب عليك معرفة مصدر كل مشكلة فيها.

حدد من يحتاج يكلم من قبل فتح الإعدادات

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

معاني VirtualBox: افهم الحدود العامة

في VirtualBox، Internal Networking تتيح شبكة بين أجهزة افتراضية محددة، بدون اتصال مباشر للتطبيقات على المضيف أو الشبكة الخارجية عبر هذا الوضع. Host-only تضيف المضيف إلى العلاقة مع الضيوف، بدون توصيل مباشر بالشبكة الفيزيائية من هذا الوضع نفسه. هذه خلاصة للوظيفة، وليست مراجعة لكل إعداد إضافي في جهازك.
NAT يسمح للضيف بالاتصال للخارج باستخدام شبكة المضيف، بينما NAT Network يدعم أيضًا اتصال الأجهزة المشتركة في شبكة NAT المحددة. Bridged يربط الضيف بالشبكة عبر واجهة فيزيائية للمضيف. اختلاف هذه الأوضاع مهم للاب دومين، ولا يكفي أن تختار أي واحد يحمل كلمة Network.
وش نحتاج نستنتج؟ إذا هدفك الأساسي حصر التجربة بين الضيوف، راجع الوضع الذي يحقق هذه العلاقة في منصتك. وإذا احتجت المضيف، راجع كيف أضفته. وإذا احتجت الخارج، اعترف أن هذا وصول للخارج، ولا تصف اللاب بأنه منفصل تمامًا لمجرد أن عناوينه خاصة.
هذه المعاني لا تغني عن مراجعة بقية الواجهات والإعدادات. جهاز فيه واجهة Internal وواجهة أخرى للخارج يحتاج تقييمًا لكليهما. كذلك إضافة توجيه أو مشاركة اتصال يمكن أن تغير الحدود المقصودة. لا تستخدم اسم وضع واجهة واحدة كدليل شامل على عزل جهاز متعدد الواجهات. راجع الواقع كله قبل أن تبدأ نشاطًا يفترض وجود فصل معين.

في Hyper-V أسماء ثانية لنفس السؤال التصميمي

Hyper-V يميز بين External وInternal وPrivate Virtual Switch. External يرتبط بواجهة شبكة فيزيائية. Internal يتيح علاقة بين المضيف والضيوف على ذلك المحول. Private يتيح علاقة بين الضيوف على المضيف دون علاقة شبكية للمضيف عبر ذلك المحول. هذه المعاني موثقة في صفحة Microsoft الخاصة بتخطيط الشبكات.
لاحظ الفرق في الكلمات: Internal في Hyper-V يشمل المضيف، بينما Internal Networking في VirtualBox لا يحمل هذا المعنى نفسه. نقل اسم الخيار من فيديو منصة إلى أخرى بدون قراءة الوظيفة سبب شائع للخلط. قارن من يستطيع الاتصال بمن، لا فقط الترجمة العربية للكلمة.
NAT في Hyper-V ترتيب يعتمد على شبكة ومحول داخلي وإعدادات إضافية، وليس معنى تلقائيًا لكل Internal Switch. وجود اسم Internal لا يخبرك وحده هل أضيفت ترجمة عناوين أو مسارات أخرى في المضيف. يحتاج ذلك مراجعة تصميمك وإعداداتك، خصوصًا إذا كانت البيئة مستخدمة لتجارب سابقة.
إذا انتقلت بين المنصتين، أعد كتابة حدود اللاب بالكلمات التي تصف العلاقة. اكتب الضيوف فقط أو الضيوف والمضيف أو اتصال بالخارج، ثم طابقها مع خيار منصتك. هذه الخطوة الصغيرة تقلل سوء الفهم، وتخليك تشرح تصميمك لزميل يستخدم منصة مختلفة بدون أن يتحول النقاش إلى خلاف على اسم خيار في الواجهة.

NAT مو مرادف للعزل الكامل

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

واجهة ثانية قد تغير الصورة كلها

تراجع الواجهة الأولى وتجدها في شبكة مغلقة بين الضيوف، فتظن أن الموضوع انتهى. لكن واجهة ثانية مرتبطة بالخارج قد تعطي الجهاز طريقًا آخر. قبل كل تجربة مهمة، راجع عدد الواجهات ومواقعها، وليس الواجهة التي استخدمتها في آخر شرح فقط. بعض صور الأجهزة تأتي بإعدادات جاهزة تحتاج فهمًا قبل التشغيل.
في جهاز ويندوز التدريبي، قراءة جدول المسارات تساعدك تفهم الخيارات المتاحة للنظام:
Get-NetRoute -AddressFamily IPv4 | Select-Object DestinationPrefix,NextHop,InterfaceIndex,RouteMetric
الأمر يعرض مسارات IPv4، ولا يختبر كل حدود الشبكة ولا يراجع IPv6. استخدمه دليلًا ضمن المراجعة، وليس شهادة فصل كاملة. إذا ظهرت وجهات أو واجهات ما تعرف سببها، ارجع إلى تصميم اللاب وإعدادات المنصة.
سجل أي واجهة تستخدم للتجربة وأي واجهة موجودة لمهمة تجهيز مؤقتة. لا تغير المسارات لأنك تريد أن تشتغل أداة بدون فهم أثر التغيير. راجع الحاجة أولًا، ثم اتبع إجراء منصتك الرسمي في بيئة تملكها، واحتفظ بوصف الحالة قبل التعديل وبعده إذا كان التعديل مطلوبًا.
النقطة المهمة أن جهازًا متعدد الواجهات يحتاج متابعة أكثر من جهاز بعلاقة واحدة واضحة. هذا ليس سببًا لمنع تعدد الواجهات دائمًا؛ أحيانًا تحتاجه لتجربة محددة. لكنه سبب لتوثيق كل علاقة وإعادة التحقق بعد نقل الصورة أو استرجاع حالة قديمة. ما كان صحيحًا أمس لا يثبت أن الإعدادات الحالية مطابقة له بدون مراجعة.

مراجعة المحول والمضيف غير مراجعة الضيف

الضيف يعرف الواجهات والمسارات التي قدمت له، بينما المنصة الافتراضية تعرف أين تتصل واجهاته. لذلك مراجعة داخل الضيف فقط قد لا تكفي لفهم حدود اللاب. احتفظ بوصف من جهة المنصة ووصف من جهة النظام الضيف، ثم قارن هل يرويان القصة نفسها.
على مضيف Hyper-V تملكه وتملك صلاحية القراءة المناسبة له، يمكن عرض المحولات الموجودة:
Get-VMSwitch | Select-Object Name,SwitchType
هذا الأمر يعرض نوع المحول، لكنه لا يمثل كل إعدادات التوجيه وNAT في المضيف. لا تكتب أن اللاب معزول بالكامل اعتمادًا على الاسم والنوع وحدهما. الهدف أن تتأكد أولًا من أن المحول المقصود موجود بالنوع الذي خططت له.
في VirtualBox راجع إعدادات الشبكة لكل جهاز، وعدد الواجهات، والوضع والاسم المرتبط بكل واحدة. ما نحتاج تغييرًا لمجرد المراجعة. إذا وجدت اسمين متشابهين، سجل الاسم كاملًا حتى لا تقارن جهازين على شبكتين مختلفتين وتظن أنهما مشتركان في نفس الشبكة.
فكر أيضًا في أثر تعديل محول مشترك. التغيير قد يمس أكثر من جهاز، وليس الجهاز الذي كنت تشخصه فقط. قبل أي تعديل مشروع في لابك، اعرف من يتصل بالمحول، وما التجارب التي تعتمد عليه. وصف التغيير يساعدك تفهم لماذا ظهرت مشكلة في جهاز آخر بعد أن ظننت أنك أصلحت اتصال جهاز واحد.

سيناريو: الإنترنت يعمل، لكن الدومين ما ينلقى

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

سيناريو: نقلت اللاب لجهاز جديد وتغيرت النتائج

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

لا تخلط حدود الشبكة بقنوات نقل الملفات

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

اختبار قبول اللاب قبل أول تجربة تقنية

ضع اختبار قبول صغيرًا: كل جهاز في الشبكة المقصودة، وكل واجهة لها سبب واضح، وأسماء خدمات اللاب تحل كما توقعت، والاتصالات المطلوبة بين أجهزته تنجح، والوصول الإضافي موثق إن كان موجودًا. لا تجمع علامات نجاح شكلية؛ اربط كل تحقق بمتطلب مكتوب في التصميم.
بعد أي تغيير مهم، أعد الجزء المتأثر من الاختبار. إذا غيرت اسم شبكة افتراضية، راجع الأجهزة التي ترتبط بها. وإذا أضفت واجهة، راجع المسارات والوجهات المطلوبة. لا يلزم تكرار كل تجارب الدومين بعد تغيير بسيط، لكن يلزم تفهم ما الذي يمكن أن يكون تغير نتيجة له.
خزن وصف اللاب بجانب ملاحظات التعلم: المنصة والنسخة، وأسماء الشبكات، وأدوار الأجهزة، وطريقة التجهيز، وحدود الاستخدام. هذه المعلومات تفسر نتائج الأدوات لاحقًا. بدونها، ممكن تقضي وقتًا في مشكلة Kerberos أو LDAP بينما السبب الفعلي أن الجهاز انتقل إلى شبكة مختلفة قبل بداية التجربة.
المراجع الرسمية للمعاني وطرق المراجعة:
https://docs.oracle.com/en/virtualization/virtualbox/7.2/user/networkingdetails.html
https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/plan/plan-hyper-v-networking-in-windows-server
https://learn.microsoft.com/en-us/powershell/module/hyper-v/get-vmswitch
https://learn.microsoft.com/en-us/powershell/module/nettcpip/get-netroute
اللاب المريح مو اللي يوصل لكل مكان. هو اللي تعرف حدوده، وتفهم لماذا كل اتصال فيه موجود، وتقدر ترجع لنفس الحالة لما تحتاج تعيد تجربة أو تفسر نتيجة اختلفت عن المتوقع.