الفصل : 8
الجزء : 2
ا لعنوان : الوصول عن بعد (Remote Access)
الحقيقة حول DirectAccess و IPv6
أحد المتطلبات غير المريحة التي ذكرتها كان الحاجة إلى IPv6 داخل شبكتك. مع الإصدار الأول من DirectAccess، كان هذا مطلبًا مؤسفًا. أقول مؤسفًا لأن، حتى اليوم، تقريبا لا أحد يدير IPv6 داخل شبكاتهم المؤسسية، ناهيك عن سنوات مضت عندما تم إصدار هذه التقنية - العديد من المديرين لم يكونوا يفهمون حتى ما هو IPv6. لحسن الحظ، لم يعد مطلب IPv6 داخل شبكاتك موجودًا. أكرر، فقط في حالة عدم انتباه أحد أو قراءة مستندات TechNet القديمة والمتقادمة - أنت لا تحتاج إلى IPv6 لاستخدام DirectAccess! لقد رأيت العديد من الحالات حيث تم اعتبار DA من قبل شركة، ولكن تم تجاهل المشروع لأنهم قرأوا شيئًا ما على TechNet جعلهم يعتقدون أن IPv6 كان مطلبًا، وقاموا بإلغاء DA كشيء لن يعمل. أنت بالتأكيد لا تحتاج إلى تشغيل IPv6 في شبكتك لجعل DA يعمل، ولكن من المهم أن تفهم كيف يستخدم DA IPv6 لأنك ستبدأ في مواجهة آثار له بمجرد أن تبدأ نشره.
عندما أكون جالسًا في المنزل وأعمل على جهاز الكمبيوتر المحمول الخاص بالشركة، يقوم DA بربطي بالشبكة المؤسسية. شبكتي الداخلية في العمل ليس لديها أي IPv6 يعمل داخلها؛ نحن شبكة IPv4 بالكامل في الوقت الحالي. هذا صحيح لمعظم الشركات اليوم. ومع ذلك، عندما أفتح موجه الأوامر وأقوم بالـ ping إلى أحد الخوادم من جهاز DA المحمول الخاص بي، هذا ما أراه - أعذروني على لقطة الشاشة المنقحة:
ما هذا بحق السماء؟ يبدو كأنه IPv6 بالنسبة لي. هنا يأتي دور IPv6 مع DA. جميع الحركة التي تنتقل عبر جزء الإنترنت من الاتصال، بين جهاز الكمبيوتر المحمول الخاص بي وخادم DA الذي يجلس في مركز البيانات الخاص بي، هي حركة IPv6. شبكتي الداخلية هي IPv4، وخادم DA الخاص بي لديه فقط عناوين IPv4 عليه، ومع ذلك فإن نفق DA يحمل حركتي باستخدام IPv6. هذا هو جوهر كيفية عمل DA ولا يمكن تغييره. يرسل جهاز DA الخاص بك حزم IPv6 المشفرة بواسطة IPsec عبر الإنترنت إلى خادم DA، وعندما يستقبل خادم DA تلك الحزم، يكون لديه القدرة على تحويلها إلى IPv4 من أجل إرسالها إلى خادم الوجهة داخل الشبكة المؤسسية. على سبيل المثال، عندما أفتح Outlook ويحاول الاتصال بخادم Exchange الخاص بي، تتدفق حزم Outlook الخاصة بي عبر نفق DA كـ IPv6. بمجرد أن تصل هذه الحزم إلى خادم DA الخاص بي، يقوم خادم DA بالبحث في DNS الداخلي لمعرفة ما إذا كان خادم Exchange الخاص بي هو IPv4 أو IPv6.
إذا كنت تشغل فعليًا IPv6 داخل الشبكة وكان خادم Exchange متاحًا عبر IPv6، فسيقوم خادم DA ببساطة بإرسال حزم IPv6 إلى خادم Exchange. الاتصال مكتمل! من ناحية أخرى، إذا كنت تشغل IPv4 داخل شبكتك، فسيقوم خادم DA برؤية سجل A واحد فقط في DNS، مما يعني أن خادم Exchange هو IPv4 فقط. سيقوم خادم DA بعد ذلك بتغيير حزمة IPv6 إلى IPv4، ثم إرسالها إلى خادم Exchange. التقنيتان اللتان تتعاملان مع هذا التلاعب بالحزم هما DNS64 وNAT64، والتي ربما قد رأيتها في بعض الوثائق إذا كنت قد قرأت أي شيء عن DA عبر الإنترنت.
الهدف من هذه التقنيات هو تغيير تدفق حزم IPv6 الواردة إلى IPv4 للشبكات التي تحتاج ذلك، وهو الحال تقريبًا لكل الشبكات في الوقت الحالي، وتحويل الحركة العائدة من IPv4 إلى IPv6 حتى تتمكن من العودة إلى جهاز عميل DA عبر نفق IPsec المستند إلى IPv6 الذي يربط عميل DA بخادم DA عبر الإنترنت.
من المهم فهم أن DA يستخدم IPv6 بهذه الطريقة لأن أي سياسات أمنية قد تكون لديك والتي تلغي IPv6 على أجهزة الكمبيوتر العميلة افتراضيًا ستمنع DA من العمل بشكل صحيح في بيئتك. ستحتاج إلى عكس هذه السياسات للسماح للأجهزة العميلة بإرسال حزم IPv6 والحصول على حركتها عبر الإنترنت. ومع ذلك، من المهم أيضًا فهم أنك لا تحتاج إلى أي وجود لـ IPv6 داخل الشبكة المؤسسية لجعل هذا يعمل، حيث يمكن لخادم DA تحويل جميع الحركة إلى IPv4 قبل أن تصل إلى تلك الشبكة الداخلية، ومعظم عمليات تنفيذ DA الفعالة اليوم تعمل بهذه الطريقة تمامًا.
المتطلبات المسبقة لـ DirectAccess
لدى DA الكثير من الأجزاء المتحركة، وهناك العديد من الطرق المختلفة التي يمكنك إعدادها بها. ومع ذلك، ليست كل هذه الطرق أفكارًا جيدة. لذا، في هذا القسم، سنناقش بعض القرارات الكبيرة التي ستحتاج إلى اتخاذها عند تصميم بيئة DA الخاصة بك.
الانضمام إلى النطاق (Domain-joined)
المطلب الكبير الأول هو أن الأنظمة المعنية بـ DA تحتاج إلى الانضمام إلى النطاق. يحتاج خادم DA أو الخوادم الخاصة بك إلى الانضمام إلى النطاق الخاص بك، وجميع أجهزة الكمبيوتر العميلة التي تريد أن تكون متصلة بـ DA تحتاج أيضًا إلى الانضمام إلى نطاق. العضوية في النطاق مطلوبة لأغراض المصادقة، وأيضًا لأن إعدادات عميل DA التي تحتاج إلى تطبيقها على أجهزة الكمبيوتر المحمولة يتم نقلها إلى هذه الأجهزة عبر Group Policy.
أحب دائمًا أن أشير إلى هذا المطلب مبكرًا في عملية التخطيط، لأنه يعني أن المستخدمين الذين يشترون أجهزة الكمبيوتر المحمولة الخاصة بهم من موقع بيع بالتجزئة عادة لن يكونوا قادرين على استخدام DA - إلا إذا كنت على ما يرام مع إضافة أجهزة الكمبيوتر المنزلية إلى نطاقك - ولذلك فإن DA هو تقنية مصممة لإدارة وربط الأصول المؤسسية التي يمكنك إضافتها إلى النطاق. من المهم أيضًا فهم هذا المطلب من منظور الأمان، حيث أن خادم أو خوادم DA الخاصة بك ستواجه عادةً حافة شبكتك. من الشائع أن تجلس بطاقة الشبكة الخارجية على خادم DA داخل DMZ، ولكن يجب أن تكون أيضًا جزءًا من النطاق، وهذا قد لا يكون شيئًا تعتاد على فعله مع الأنظمة في شبكة محيطية.
أنظمة التشغيل العميلة المدعومة
ليست كل أنظمة تشغيل Windows العميلة تحتوي على المكونات اللازمة لجعل اتصال DA يعمل. Enterprise يحتوي عليها، مما يغطي الغالبية العظمى من الشركات الكبرى التي تمتلك أنظمة تشغيل Microsoft، ولكن هذا بالتأكيد لا يشمل الجميع. لا زلت أرى العديد من الشركات الصغيرة تستخدم إصدارات Professional أو حتى Home على أجهزتهم العميلة، وهذه الإصدارات لا تحتوي على مكونات DA. القائمة التالية هي لأنظمة التشغيل التي تدعم DA. خلال تخطيطك، ستحتاج إلى التأكد من أن أجهزة الكمبيوتر المحمولة الخاصة بك تعمل بأحد هذه الأنظمة:
- Windows 11 Enterprise
- Windows 10 Enterprise
- Windows 10 Education
- Windows 8.0 أو 8.1 Enterprise
- Windows 7 Enterprise
- Windows 7 Ultimate
خوادم DirectAccess - بطاقة أو بطاقتين شبكيتين؟
سؤال كبير يحتاج إلى الإجابة حتى قبل تثبيت دور Remote Access على الخادم الجديد هو، كم عدد بطاقات الشبكة المطلوبة على هذا الخادم؟ هناك طريقتان مدعومتان لتنفيذ DA.
وضع بطاقة شبكية واحدة (Single NIC mode)
يمكن تثبيت خادم DA ببطاقة شبكية واحدة فقط. في هذه الحالة، ستقوم عادةً بتوصيل تلك الشبكة مباشرةً بشبكتك الداخلية بحيث يكون لديها وصول إلى جميع الموارد الداخلية التي ستحتاج أجهزة الكمبيوتر العميلة إلى الاتصال بها أثناء جلسات DA للمستخدم. للحصول على حركة المرور من الإنترنت إلى خادم DA الخاص بك، ستحتاج إلى إنشاء NAT من عنوان IP عام إلى أي عنوان IP داخلي قمت بتعيينه لخادم DA.
العديد من مديري الأمان الشبكي لا يحبون هذه الطريقة لأنها تعني إنشاء NAT يجلب الحركة مباشرة إلى الشبكة المؤسسية دون المرور عبر أي نوع من DMZ.
يمكنني أيضًا أن أقول لك من التجربة أن وضع بطاقة شبكية واحدة لا يعمل دائمًا بشكل صحيح. يقوم بعمل جيد لإعداد مختبر اختبار سريع أو إثبات مفهوم، ولكنني رأيت العديد من المشاكل في الميدان مع الأشخاص الذين يحاولون تشغيل بيئات DA الإنتاجية على بطاقة شبكية واحدة. القدرة على استخدام بطاقة شبكة واحدة فقط هي شيء تمت إضافته إلى DA في الإصدارات الأحدث، لذلك لم يكن مصممًا في الأصل للعمل بهذه الطريقة. لذلك، أوصي بشدة أنه من أجل تثبيت DA الإنتاجي، تقوم بالعمل بشكل صحيح واستخدام...
وضع بطاقتين شبكيتين (Dual NICs)
هنا، لدينا بطاقتي شبكة في خادم DA. عادةً ما يتم توصيل بطاقة الشبكة الداخلية مباشرة بالشبكة المؤسسية، ويمكن أن يختلف وضع بطاقة الشبكة الخارجية الفيزيائي حسب المنظمة. سنناقش الإيجابيات والسلبيات لمكان وضع بطاقة الشبكة الخارجية مباشرة بعد هذا القسم من الفصل. يعمل DA بأفضل طريقة في وضع الحافة مع بطاقتين شبكيتين. كما قد تتذكر من وقت سابق في الكتاب، تنفيذ خادم Windows مع بطاقتين شبكيتين يعني أنك ستقوم بتعدد المنافذ لهذا الخادم، وستحتاج إلى إعداد إعدادات الشبكة وفقًا لذلك. مع خادم Remote Access، تكون بطاقة الشبكة الخارجية دائمًا هي التي تستقبل إعدادات البوابة الافتراضية، لذا يجب أن تتأكد من اتباع هذه القاعدة وعدم تكوين بوابة افتراضية على بطاقة الشبكة الداخلية.
الشبكات الوحيدة التي لا تحتاج إلى إدخال المسارات الثابتة هي الشبكات الصغيرة، حيث تكون جميع أجهزتك الداخلية في شبكة فرعية واحدة. إذا كان هذا هو الحال، فلن تحتاج إلى إدخال المسارات الثابتة. ولكن معظم الشبكات الشركات تتوزع على شبكات فرعية متعددة، وفي هذه الحالة، يجب الرجوع إلى الفصل السابع، Networking with Windows Server 2022، حيث ناقشنا تعدد المنازل وكيفية إنشاء تلك المسارات.
أكثر من بطاقة NIC
لا، لا تذهب إلى هناك. إذا كنت معتادًا على تكوين الموجهات أو الجدران النارية، فأنت تعلم أن لديك القدرة على تثبيت العديد من بطاقات NIC المختلفة على الخادم وتوصيلها جميعًا في شبكات فرعية مختلفة. بينما هناك العديد من الأسباب التي تجعل تقسيم الوصول إلى الشبكة بهذه الطريقة على خادم Remote Access قد يكون مفيدًا، إلا أنه لن يعمل بالطريقة التي تريدها. تكوين DA نفسه قادر فقط على إدارة واجهتين شبكيتين مختلفتين. كما ترى في الشكل 8.8، في مسار معالجات الإعداد، سيكون عليك تعريف إحدى بطاقات NIC كـ External، والأخرى كـ Internal. أي بطاقات NIC إضافية موجودة في هذا الخادم لن تُستخدم بواسطة DA، للأسف. ربما يكون هذا شيئًا سيتغير في الإصدارات المستقبلية!
استخدام NAT أم لا؟
الآن بعد أن قررت استخدام بطاقتين NIC في خادم DA الخاص بك، أين نوصّل بطاقة NIC الخارجية؟ هناك مكانان شائعان يمكن توصيل هذه الواجهة الشبكية الخارجية بهما، ولكن بناءً على ما تختاره، يمكن أن تكون نتيجة بيئة DA الخاصة بك مختلفة تمامًا. قبل أن نتحدث عن الموضع الفعلي لبطاقة NIC، أود أن أعرف بعض البروتوكولات التي من المهم فهمها، لأنها تتعلق كثيرًا بالإجابة على هذا السؤال حول موضع بطاقة NIC. عندما يقوم حاسوبك المحمول المتصل بـ DA بإنشاء اتصال مع خادم DA، فإنه سيفعل ذلك باستخدام أحد بروتوكولات الأنفاق الانتقالية IPv6 الثلاثة. هذه البروتوكولات هي 6to4، Teredo، وIP-HTTPS. عندما يتصل عميل DA بأنفاق DA، فإنه سيختار تلقائيًا البروتوكول الأنسب للاستخدام، اعتمادًا على اتصال الإنترنت الحالي للمستخدم.
كل البروتوكولات الثلاثة تؤدي نفس الوظيفة لاتصال DA: مهمتها هي أخذ تدفق الحزم IPv6 القادمة من الحاسوب المحمول وتغليفها داخل IPv4 بحيث يمكن أن تنتقل بنجاح عبر الإنترنت IPv4. عندما تصل الحزم إلى خادم DA، يتم فك تغليفها بحيث يمكن لخادم DA معالجة هذه الحزم IPv6.
ال 6to4
سيحاول عملاء DA الاتصال باستخدام 6to4 فقط عندما يكون للحاسوب المحمول البعيد عنوان IP عام حقيقي على الإنترنت. هذا نادرًا ما يحدث هذه الأيام، مع نقص العناوين المتاحة IPv4 على الإنترنت، وبالتالي فإن 6to4 لا يُستخدم عادةً بواسطة أي حواسيب عميلة DA. في الواقع، يمكن أن يسبب مجموعة من التحديات الخاصة به عندما يتصل المستخدمون باستخدام بطاقات الهاتف الخلوي في حواسيبهم المحمولة، ولذلك فإنها ممارسة شائعة لتعطيل محول 6to4 على حواسيب العملاء كإعداد أفضل لممارسة DA.
ال Teredo
عندما يكون عملاء DA متصلين بالإنترنت باستخدام عنوان IP خاص، مثل خلف موجه منزلي أو موجه Wi-Fi عام، فإنهم سيحاولون الاتصال باستخدام بروتوكول Teredo. يستخدم Teredo تدفق UDP لتغليف حزم DA، وبالتالي، طالما أن اتصال الإنترنت للمستخدم يسمح بالخروج عبر UDP 3544، فإن Teredo سيتصل بشكل عام ويكون البروتوكول الانتقالي المفضل لهذا الاتصال DA.
ال IP-HTTPS
إذا فشل Teredo في الاتصال، مثل في حالة كان المستخدم جالسًا في شبكة تحظر خروج UDP، فإن الاتصال DA سيتراجع لاستخدام IP-HTTPS، والذي يُنطق IP over HTTPS. هذا البروتوكول يغلف الحزم IPv6 داخل رؤوس IPv4، ثم يغلفها داخل رأس HTTP ويشفرها باستخدام TLS/SSL، قبل إرسال الحزمة عبر الإنترنت. هذا يجعل الاتصال DA في الواقع تدفق SSL، تمامًا مثل تصفح موقع ويب HTTPS.
التثبيت على الحافة الحقيقية - على الإنترنت عندما تقوم بتوصيل بطاقة NIC الخارجية في خادم DirectAccess مباشرة بالإنترنت، فإنك تمنح نفسك القدرة على وضع عناوين IP عامة حقيقية على تلك البطاقة. عند القيام بذلك، فإنك تُمكّن جميع بروتوكولات الأنفاق الانتقالية الثلاثة المذكورة أعلاه، بحيث يمكن لأجهزة الكمبيوتر العميلة DirectAccess الاختيار بينها للحصول على أفضل نوع من الاتصال. عند التثبيت باستخدام طريقة الحافة الحقيقية، ستضع ليس فقط واحدًا بل عنواني IP عامين على تلك البطاقة الخارجية. تأكد من أن عناوين IP العامة متتالية لأن هذا هو شرط لتفعيل Teredo. بطاقة NIC لا تحتاج بالضرورة إلى أن تكون موصولة مباشرة بالإنترنت لكي يعمل هذا. بناءً على قدرات جدار الحماية لديك، قد يكون لديك الخيار لإنشاء DMZ مُجسر حيث لا يحدث أي NATing. تحتاج إلى التحقق مع بائع جدار الحماية الخاص بك لمعرفة ما إذا كان هذا الخيار متاحًا لمنظمتك. في هذا السيناريو، لا تزال قادرًا على تكوين عناوين IP عامة حقيقية على البطاقة الخارجية للخادم، ولكن التدفق يمر عبر جدار الحماية أولاً، من أجل حماية وإدارة ذلك التدفق.
تركيب خلف NAT
من الشائع أن ترغب فرق الشبكات في وضع كرت الشبكة الخارجي لخادم DirectAccess خلف جدار ناري، داخل DMZ. وهذا عادة ما يعني إنشاء NAT لجلب هذه الحركة إلى الخادم. بينما هذا ممكن تمامًا ويوفر حماية أفضل لخادم DirectAccess نفسه من الإنترنت، إلا أنه يأتي بعيب كبير. عندما تقوم بتركيب خادم DirectAccess خلف NAT، لن يعمل Teredo. في الواقع، ستتعرف معالجات تكوين DirectAccess عندما يكون لديك عنوان IP خاص على كرت الشبكة الخارجي ولن تقوم حتى بتشغيل Teredo.
عندما لا يكون Teredo متاحًا، ستتصل جميع عملاء DirectAccess باستخدام بروتوكول IP-HTTPS. إذًا، لماذا يهم إذا كان Teredo غير متاح؟ لأن Teredo بروتوكول أكثر كفاءة من IP-HTTPS. عندما يقوم Teredo بنفق الحزم، فإنه ببساطة يضع IPv6 داخل IPv4. تكون حركة مرور DirectAccess مشفرة دائمًا باستخدام IPsec، لذلك لا حاجة لأن يقوم نفق Teredo بأي تشفير إضافي. من ناحية أخرى، عندما يقوم IP-HTTPS بنفق الحزم، فإنه يأخذ حركة مرور IPsec المشفرة مسبقًا ويشفرها مرة ثانية باستخدام SSL. هذا يعني أن جميع الحزم التي تأتي وتذهب تخضع للتشفير المزدوج، مما يزيد من المعالجة ودورات وحدة المعالجة المركزية ويجعل الاتصال أبطأ. كما يخلق حملًا إضافيًا على الأجهزة على خادم DirectAccess نفسه، لأنه يتعامل مع ضعف كمية معالجة التشفير.
تكون هذه المشكلة واضحة بشكل خاص عندما تقوم بتشغيل Windows 7 على أجهزة الكمبيوتر العميلة، حيث سيؤدي معالجة التشفير المزدوج إلى اتصال أبطأ بشكل ملحوظ للمستخدمين. لا يزال DirectAccess يعمل بشكل جيد، ولكن إذا جلست بجانب كمبيوتر محمول متصل بـ Teredo وجانب كمبيوتر محمول متصل بـ IP-HTTPS، ستلاحظ الفرق في السرعة بين الاثنين.
لحسن الحظ، في Windows 8 والإصدارات الأعلى، تم إضافة بعض التدابير المضادة للمساعدة في هذا الفرق في السرعة. تكون أنظمة التشغيل العميلة الأحدث هذه ذكية بما يكفي بحيث يمكنها التفاوض على جزء SSL من نفق IP-HTTPS باستخدام خوارزمية التشفير NULL، مما يعني أن IP-HTTPS لا يقوم بتشفير ثانٍ وأداء IP-HTTPS يصبح مماثلًا لأداء Teredo. ومع ذلك، هذا يعمل فقط لأنظمة التشغيل العميلة الأحدث (Windows 7 سيظل يشفّر مرتين مع IP-HTTPS)، ولا يزال لا يعمل في بعض الحالات. على سبيل المثال، عندما تقوم بتمكين خادم DirectAccess لتوفير الاتصال VPN أيضًا، أو إذا اخترت استخدام نظام كلمة مرور لمرة واحدة (OTP) جنبًا إلى جنب مع DirectAccess، فإن خوارزمية NULL ستتعطل لأنها تشكل خطرًا أمنيًا في هذه الحالات، وبالتالي حتى أجهزة Windows 8 وWindows 10 الخاصة بك ستقوم بتشفير مزدوج عند الاتصال عبر IP-HTTPS. يمكنك أن ترى أنه سيكون من المفيد تمكين Teredo وجعله متاحًا بحيث يمكن لأي أجهزة كمبيوتر يمكنها الاتصال عبر Teredo أن تقوم بذلك.
للتلخيص، يمكنك بالتأكيد تركيب كرت الشبكة الخارجي لخادم DirectAccess خلف NAT، ولكن كن على علم بأن جميع أجهزة الكمبيوتر العميلة لـ DirectAccess ستتصل باستخدام بروتوكول IP-HTTPS، ومن المهم فهم الآثار الجانبية المحتملة لتطبيقها بهذه الطريقة.
خادم موقع الشبكة
هذا المكون الرئيسي في بنية DirectAccess هو شيء لا يوجد حتى على خادم DirectAccess نفسه، أو على الأقل لا ينبغي أن يكون إذا كنت تقوم بإعداد الأشياء بشكل صحيح. خادم موقع الشبكة (NLS) هو ببساطة موقع ويب يعمل داخل الشبكة الداخلية للشركة. هذا الموقع لا يحتاج إلى أن يكون متاحًا للوصول من الإنترنت؛ في الواقع، يجب ألا يكون كذلك.
يتم استخدام NLS كجزء من آلية الكشف عن الداخل/الخارج على أجهزة الكمبيوتر العميلة DirectAccess، على غرار الطريقة التي يعمل بها Trusted Network Detection لـ Always On VPN. في كل مرة يحصل جهاز عميل DirectAccess على اتصال بالشبكة، يبدأ في البحث عن موقع NLS. إذا كان يمكنه رؤية الموقع، فإنه يعرف أنك داخل الشبكة الداخلية للشركة، ولا يكون DirectAccess مطلوبًا، لذلك يغلق نفسه. ومع ذلك، إذا لم يتمكن جهاز الكمبيوتر العميل من الوصول إلى موقع NLS، فهذا يعني أنك خارج الشبكة الداخلية، وستبدأ مكونات DirectAccess في تشغيل نفسها.
يتحقق هذا المتطلب بسهولة؛ كل ما تحتاجه هو تشغيل جهاز افتراضي وتثبيت IIS عليه لاستضافة هذا الموقع الجديد، أو يمكنك حتى إضافة موقع ويب جديد إلى خادم ويب موجود في شبكتك. هناك شيئين فقط يجب الانتباه إليهما عند إعداد موقع NLS. الأول هو أنه يجب أن يكون موقع HTTPS، لذلك يتطلب شهادة SSL. سنناقش الشهادات المستخدمة في DirectAccess، بما في ذلك هذه الشهادة، في القسم التالي من هذا الفصل. بالإضافة إلى التأكد من أن الموقع يمكن الوصول إليه عبر HTTPS، يجب عليك أيضًا التأكد من أن اسم DNS الذي تستخدمه للاتصال بهذا الموقع فريد.
تريد القيام بذلك لأن أي اسم تختاره لموقع NLS، لن يكون قابلًا للحل عندما تكون أجهزة الكمبيوتر العميلة خارج الشبكة الداخلية. هذا مصمم عمدًا لأنك بالطبع لا تريد أن تتمكن أجهزة عميل DirectAccess من الوصول بنجاح إلى موقع NLS عندما تعمل عن بعد، لأن ذلك سيعطل اتصال DirectAccess الخاص بها.
السبب في إشارتي إلى اسم DNS الفريد هو أنني غالبًا ما أرى مدراء DirectAccess الجدد يستخدمون موقع ويب داخلي موجود كـ NLS الخاص بهم. على سبيل المثال، إذا كان لديك https://intranet يعمل كموقع SharePoint، يمكنك ببساطة استخدامه في تكوين DirectAccess كتعريف لخادم NLS. ومع ذلك، بمجرد إعداد ذلك بهذه الطريقة، ستدرك بسرعة أنه لا يمكن لأي شخص يعمل عن بعد الوصول إلى موقع https://intranet. هذا مصمم عمدًا، لأن بيئة DirectAccess الآن تعتبر موقع الإنترانت الخاص بك خادم NLS، ولا يمكنك حله أثناء التنقل. الحل لهذه المشكلة؟ تأكد من اختيار اسم DNS جديد لاستخدامه لموقع NLS. شيء مثل https://nls.contoso.local مناسب.
الجزء الأهم بشأن NLS الذي أريد التأكيد عليه هو أنه يجب عليك تمامًا تنفيذ هذا الموقع على خادم في شبكتك وليس على خادم DirectAccess نفسه. عند تشغيل معالجات تكوين DirectAccess، ستلاحظ على الشاشة حيث نحدد NLS أنه يوصى بنشره على خادم ويب بعيد، ولكنه يوفر لك أيضًا الخيار لاستضافة موقع NLS مباشرة على خادم DirectAccess نفسه. لا تفعل ذلك! هناك العديد من الأشياء التي يمكن أن تسوء عند استضافة NLS على خادم DirectAccess. تشغيل NLS على خادم DirectAccess يقيد أيضًا إمكانيات DirectAccess المستقبلية، لأن بعض تكوينات DirectAccess المتقدمة تتطلب إزالة NLS من خادم DirectAccess على أي حال، لذلك قد تفعلها بشكل صحيح في المرة الأولى التي تقوم بإعدادها. تغيير موقع NLS بعد تشغيل DirectAccess في الإنتاج يمكن أن يكون صعبًا جدًا وغالبًا ما ينتهي بشكل سيء. لقد ساعدت العديد من الشركات في نقل موقع NLS بعد أن أدركت أنها لا يمكنها استضافة NLS على خادم DirectAccess إذا وعندما ترغب في إضافة خادم DirectAccess ثانٍ للنمو أو التكرار. فيما يلي لقطة شاشة للقسم في معالج تكوين DirectAccess حيث تختار موقع NLS. تأكد من الالتزام بالمربع العلوي!
الشهادات المستخدمة مع DirectAccess
بصرف النظر عن قراءة وعدم فهم كيفية استخدام DirectAccess لـ IPv6، ها هو أكبر "توقف" للمسؤولين المهتمين بتجربة DirectAccess. بمجرد أن تبدأ في قراءة كيفية عمل DirectAccess، ستدرك بسرعة أن الشهادات مطلوبة في أماكن مختلفة قليلة. بينما تتطلب VPNs عمومًا أيضًا استخدام الشهادات، إلا أنه من الصعب التمييز بين الشهادات التي تحتاج إلى الذهاب إلى أين عند الخوض في وثائق Microsoft DirectAccess، لذا يوضح هذا القسم أي لبس موجود حول شهادات DirectAccess. إنه حقًا ليس معقدًا، بمجرد أن تعرف ما يحتاج وما لا يحتاج إلى القيام به.
المتطلب الأساسي هو أن يكون لديك خادم CA Windows في شبكتك. حجم تنفيذ PKI الخاص بك ليس مهمًا جدًا لـ DirectAccess. نحن ببساطة نحتاج إلى القدرة على إصدار الشهادات لخادم DirectAccess والعملاء. هناك ثلاثة أماكن فقط حيث يتم استخدام الشهادات في DirectAccess، واثنان منهما هما شهادات SSL.
شهادة SSL على خادم الويب NLS
كما ذكرنا سابقًا، يحتاج موقع NLS الخاص بك إلى تشغيل HTTPS. هذا يعني أنك ستحتاج إلى شهادة SSL لتثبيتها على الخادم الذي يستضيف موقع NLS الخاص بك. بافتراض أن لديك خادم CA داخلي، يمكن بسهولة الحصول على هذه الشهادة من ذلك CA الداخلي، لذلك لا توجد تكاليف مرتبطة بهذه الشهادة. لا تحتاج إلى شراء واحدة من CA العامة، لأن هذه الشهادة ستتم فقط الوصول إليها والتحقق منها من أجهزة الكمبيوتر المرتبطة بالنطاق، عملاء DirectAccess. نظرًا لأن أجهزة الكمبيوتر المرتبطة بالنطاق تثق تلقائيًا بخوادم CA في شبكتك، يمكن ببساطة إصدار هذه الشهادة من CA الداخلي، وستقوم بالضبط بما نحتاجه لأغراض DirectAccess.
شهادة SSL على خادم DirectAccess
تُطلب أيضًا شهادة SSL لتثبيتها على خادم DirectAccess نفسه، ولكن يجب شراء هذه الشهادة من CA العام. السبب في أنك تحتاج إلى شراء شهادة SSL من طرف ثالث هو أن عملاء DirectAccess يمكن أن يكونوا أي مكان في العالم، بما في ذلك أماكن حيث لم ينضموا إلى النطاق بعد، لذلك لن يكون لديهم بعد قائمة CA الموثوقة لخادمك الداخلي.
اسم DNS على هذه الشهادة يجب أن يتطابق مع اسم DNS العمومي الذي ستستخدمه للاتصال بخادم DirectAccess. على سبيل المثال، إذا كان عنوان IP العمومي لخادم DirectAccess الخاص بك هو 131.107.0.1 وكان لديك سجل DNS عمومي يشير إلى directaccess.contoso.com يتوجه إلى ذلك العنوان، فإن هذه الشهادة يجب أن تُصدر إلى directaccess.contoso.com.
شهادات الأجهزة على خادم DA وجميع عملاء DA
الجزء الأخير والأكثر تعقيدًا من لغز شهادات DA هو شهادات الأجهزة. بمجرد معرفة ما هو مطلوب، يصبح الأمر ليس صعبًا على الإطلاق. نحن ببساطة نحتاج إلى تثبيت شهادة كمبيوتر أو جهاز على خادم DA، وكذلك على كل جهاز من أجهزة عملاء DA. تُستخدم هذه الشهادة كجزء من عملية المصادقة لأنفاق IPsec. إنها جزء كبير من الطريقة التي يتأكد بها DA من أنك فعلاً من تدعي أنك عندما يحدث اتصال DA بجهازك.
أفضل طريقة لإصدار هذه الشهادات للأجهزة هي تسجيل الدخول إلى خادم CA الخاص بك وإنشاء نموذج شهادة جديد مكرر من النموذج المدمج المسمى "Computer". عند إعداد نموذج الشهادة الجديد، تأكد فقط من أنه يفي بالمعايير التالية:
- يجب أن يتطابق الاسم العام (Common Name) للشهادة مع الاسم الكامل المؤهل (FQDN) للكمبيوتر.
- يجب أن يساوي اسم البديل الموضوع (Subject Alternative Name أو SAN) للشهادة اسم DNS للكمبيوتر.
- يجب أن تخدم الشهادة الأغراض المقصودة (Enhanced Key Usage) لكل من مصادقة العميل (Client Authentication) ومصادقة الخادم (Server Authentication).
أود أن أشير هنا، على الرغم من أنني لا أريد ذلك حقًا، أن إصدار هذه الشهادات ليس ضروريًا تمامًا لجعل DA يعمل. إذا كنت تستخدم Windows 8 أو أعلى على جانب العميل، فمن الممكن تشغيل DA بدون شهادات الأجهزة. يمكن لأجهزة الكمبيوتر العميلة التي تعمل بدون شهادات الأجهزة استخدام شيء يسمى وكيل Kerberos (Kerberos Proxy) لمصادقة الكمبيوتر عند بناء أنفاق IPsec، لكنني أوصي بشدة بالالتزام بالشهادات. استخدام الشهادات كجزء من عملية المصادقة يجعل الاتصال أكثر استقرارًا وأكثر أمانًا. بالإضافة إلى ذلك، كما هو الحال مع وضع NLS، إذا كنت ترغب في تنفيذ أي وظائف متقدمة مع DA، مثل توازن الحمل أو الموقع المتعدد، أو حتى إذا كنت ترغب ببساطة في جعل بعض أجهزة Windows 7 تتصل من خلال DA، فستكون ملزمًا بإصدار الشهادات على أي حال. لذا، اتبع أفضل الممارسات من البداية وأصدر هذه الشهادات قبل أن تبدأ حتى في اختبار DA.
لا تستخدم معالج بدء التشغيل (GSW)!
بعد اتخاذ قرارات التصميم اللازمة وتنفيذ المتطلبات المسبقة التي تحدثنا عنها حتى الآن، حان الوقت أخيرًا لتثبيت دور الوصول عن بعد (Remote Access) على خادم DA الجديد! بعد الانتهاء من تثبيت الدور، ستظهر لك رسالة تخبرك بأن هناك حاجة إلى تكوين إضافي لاستخدام هذا الدور. إذا اتبعت العلامة الصفراء داخل Server Manager، فإن الخيار الوحيد الذي ستجده هو فتح معالج بدء التشغيل (Getting Started Wizard). آه! هذا ليس ما تريد النقر عليه:
لا تفعل ذلك!
مكانك لتكوينات DA هو وحدة إدارة الوصول عن بعد (Remote Access Management Console)، والمتاحة من داخل قائمة الأدوات (Tools) في Server Manager الآن بعد أن تم تثبيت دور الوصول عن بعد. قم بتشغيلها، والآن ستظهر لك خيار:
لا تنقر على "Run the Getting Started Wizard"! تم تصميم GSW كطريقة مختصرة لتنفيذ DA، مصممة فقط لتشغيل DA بأسرع ما يمكن، ربما لإثبات المفهوم السريع. تحت أي ظرف من الظروف يجب أن تثق في GSW لبيئة DA الإنتاجية الخاصة بك، لأنه في محاولة لجعل التكوين سريعًا وسهلاً، يتم اتخاذ العديد من قرارات التكوين نيابة عنك والتي ليست أفضل الممارسات.
تريد التأكد من النقر على "Run the Remote Access Setup Wizard" عندما يُطلب منك ذلك لأول مرة في وحدة التحكم؛ سيؤدي ذلك إلى استدعاء مجموعة كاملة من شاشات تكوين DA. يتكون إعداد DA من سلسلة من أربع خطوات مختلفة، كل منها يحتوي على مجموعة من الشاشات التي ستتنقل خلالها لاختيار خيارات التكوين المناسبة. هناك قدر كبير من التفاصيل على هذه الشاشات حول ما يعنيه كل منها وما هي خياراتك، لذلك لا تخف من الغوص فيها وإعدادها بالطريقة الصحيحة. إذا كنت قد قمت بالفعل بتكوين DA واستخدمت معالج بدء التشغيل، فقد يكون DA يعمل لديك، لكنه لن يعمل بكفاءة أو أمان كما يمكنه. فيما يلي قائمة سريعة بالأسباب التي تجعل معالج بدء التشغيل ليس في مصلحتك. هذه هي الأشياء التي يفعلها والتي تتعارض مباشرة مع تثبيت DA الأفضل ممارسة، مع تعليقات مصاحبة من قبلي:
- يقوم GSW باستضافة موقع NLS على خادم DA—سيء
- يطبق GSW إعدادات GPO للعميل DA على جميع أجهزة الدومين—فكرة سيئة للغاية
- يستخدم GSW شهادات موقعة ذاتيًا—لا من مستوى الأمان 101
- يقوم GSW بتعطيل Teredo تلقائيًا—غير فعال
- لا يرشدك GSW خلال أي من الخيارات المتقدمة لـ DA، ربما لأن الطريقة التي يعد بها كل شيء تبطل قدرتك على استخدام الوظائف المتقدمة—ممل
النهاية
نكون هنا انتهينا من الجزء 2 من الفصل 8 تماما من شهادة MCSA المقدمة من Microsoft الأن نغوص في الأعماق
و لا بد وانت تقرا ان تكون مركز جيدا لكل معلومة ومعك ورقة وقلم , لانك بالتاكيد ستحتاجها
واذا واجهتك اي مشكلة في الفهم او ما شابه , يمكنك على الفور الذهاب الى المجتمع الخاص بنا في Telegram للمناقشة والتواصل معنا من هنا
او اذا واجهتك مشكلة في الموقع او تريد اجابة سريعة يمكنك الذهاب الى اخر صفحة في الموقع ستجد صفحة اتصل بنا موجودة يمكنك ارسالة لنا مشكلتك , وسيتم الرد عليها بسرعة جدا ان شاء الله
ويمكنك الأنضمام الى المجتمع Hidden Lock بالكامل مع جميع قنواته للأستفادة في اخر الأخبار في عالم التقنية وايضا الكتب بالمجان والكورسات والمقالات من خلال الرابط التالي لمجموعة القنوات من هنا
يمكنك ايضا متابعتنا في منصات X او Twitter سابقا , لمشاهدة الاخبار والمقالات السريعة والمهمة من
وفقط كان معكم Sparrow اتمنى ان تدعوا لي وتتذكروني في الخير دوما
