الفصل : 8
الجزء : 3
العنوان : الوصول عن بعد (Remote Access)
وحدة إدارة الوصول عن بعد (Remote Access Management Console)
أنت في طريقك نحو إعطاء المستخدمين إمكانيات الوصول عن بعد على هذا الخادم الجديد. كما هو الحال مع العديد من أجهزة الشبكات، بمجرد أن تنشئ جميع التكوينات على خادم الوصول عن بعد، من الشائع جدًا أن يقوم المسؤولون بالابتعاد وتركه يعمل. لا توجد حاجة للكثير من الصيانة الجارية أو التغييرات على هذا التكوين بمجرد أن يعمل بشكل جيد. ومع ذلك، فإن وحدة إدارة الوصول عن بعد (Remote Access Management Console) في Windows Server 2022 ليست مفيدة فقط لتكوين أجزاء وأجزاء الوصول عن بعد ولكن أيضًا للرصد والإبلاغ.
عند العمل مع DA، هذا هو منزلك لكل شيء تقريبًا: التكوين، الإدارة، المراقبة، واستكشاف الأخطاء وإصلاحها. على جانب VPN/AOVPN من مجموعة أدوات الوصول عن بعد، ستقوم باتخاذ العديد من قرارات تكوين VPN داخل RRAS، لكن وحدة إدارة الوصول عن بعد هي المكان الذي تذهب إليه عند التحقق من مراقبة الخادم، مراقبة اتصال العميل، وإحصائيات التقارير. سواء كنت تستخدم DA، VPN، أو مزيج من الاثنين، فإن وحدة إدارة الوصول عن بعد هي أداة تحتاج إلى الشعور بالراحة معها.
لنلقي نظرة داخل هذه الوحدة حتى تكون على دراية بالشاشات المختلفة التي ستتعامل معها:
التكوين
شاشة التكوين واضحة إلى حد ما؛ هنا تقوم بإنشاء تكوين الوصول عن بُعد الأساسي الخاص بك، وهنا تقوم بتحديث أي إعدادات في المستقبل. كما ترى في الشكل 8.12، يمكنك تكوين DirectAccess وVPN، وحتى Web Application Proxy (WAP)، مباشرة من وحدة إدارة الوصول عن بُعد.
لا تتبع مثالي مع هذه اللقطة. لقد قمت بتثبيت جزء DirectAccess/VPN من دور الوصول عن بُعد بجانب جزء WAP من نفس الدور، لكن لا يُنصح بتشغيل كل من DA/VPN وWAP معًا على نفس الخادم. لقد قمت بذلك فقط لأغراض إنشاء لقطات شاشة في مختبر الاختبار الخاص بي.
ليس هناك الكثير لتكوينه فيما يتعلق بـ VPN؛ لديك فقط شاشة واحدة من الخيارات حيث تحدد أنواع عناوين IP التي تُعطى لعملاء VPN الذين يتصلون، وكيفية التعامل مع مصادقة VPN. ليس من الواضح على الفور أين توجد هذه الشاشة، لذا أردت أن أشير إليها. داخل قسم تكوين DirectAccess وVPN، إذا قمت بالنقر على Edit... تحت الخطوة 2، سيؤدي ذلك إلى تشغيل المعالج المصغر للخطوة 2. الشاشة الأخيرة في هذا المعالج المصغر تُسمى تكوين VPN. هذه هي الشاشة حيث يمكنك تكوين هذه العناوين وإعدادات المصادقة لاتصالات VPN الخاصة بك. بقية مهام تكوين VPN الخاصة بك ستكون ضمن وحدة تكوين VPN التقليدية، التي تُسمى RRAS. ومع ذلك، يتم تكوين كل شيء عن اتصالات DA من داخل وحدة إدارة الوصول عن بُعد ومن خلال تلك المعالجات المصغرة الأربعة:
اللوحة الرئيسية
توفر لك لوحة التحكم عن بُعد رؤية عامة على مستوى 30,000 قدم لحالة خادم الوصول عن بُعد. يمكنك عرض حالة سريعة للمكونات التي تعمل على الخادم، وما إذا كانت التغييرات الأخيرة في التكوين قد تم تطبيقها أم لا، وبعض الأرقام الموجزة في الأسفل حول عدد اتصالات DA وVPN الجارية:
حالة العمليات
إذا كنت ترغب في التعمق أكثر في ما يحدث على جانب الخادم من الاتصالات، فإن هذا هو ما تدور حوله صفحة حالة العمليات. هنا، يمكنك رؤية المزيد من التفاصيل حول كل مكون يعمل تحت السطح لجعل اتصالات DA وVPN تحدث. إذا كان هناك أي مشكلة في أي منها، يمكنك النقر على المكون المحدد للحصول على مزيد من المعلومات. على سبيل المثال، كاختبار، قمت بإيقاف تشغيل خادم NLS في شبكتي المختبرية، ويمكنني الآن رؤية صفحة حالة العمليات حيث يتم تمييز NLS بخطأ:
حالة العملاء البعيدين
الشاشة التالية هي شاشة حالة العملاء البعيدين. كما هو مذكور، هذه هي الشاشة حيث يمكننا مراقبة أجهزة الكمبيوتر العميلة المتصلة. ستُظهر لنا هنا كل من اتصالات DA وVPN. سنكون قادرين على رؤية أسماء الكمبيوترات، أسماء المستخدمين، وحتى الموارد التي يستخدمونها أثناء اتصالاتهم. يمكن تصفية المعلومات على هذه الشاشة ببساطة عن طريق وضع أي معيار في شريط البحث في أعلى النافذة.
من المهم ملاحظة أن شاشة حالة العملاء البعيدين تُظهر فقط الاتصالات النشطة الحالية. لا يتم تخزين أي معلومات تاريخية هنا.
التقارير
نعم، لقد خمنتها: هذه هي النافذة التي تحتاج لزيارتها إذا كنت تريد رؤية معلومات الوصول عن بُعد التاريخية. هذه الشاشة تشبه تقريبًا شاشة حالة العملاء البعيدين، باستثناء أنك لديك القدرة على إنشاء تقارير للمعلومات التاريخية المستخرجة من نطاقات تاريخية من اختيارك. بمجرد عرض البيانات، لديك نفس إمكانيات البحث والتصفية التي كانت لديك في شاشة حالة العملاء البعيدين.
يتم تعطيل التقارير افتراضيًا، ولكنك تحتاج ببساطة إلى الانتقال إلى صفحة التقارير والنقر على "Configure Accounting". بمجرد تمكين ذلك، سيتم تقديمك بخيارات لتخزين المعلومات التاريخية. يمكنك اختيار تخزين البيانات في WID المحلي أو على خادم RADIUS بعيد. لديك أيضًا خيارات هنا لطول مدة تخزين بيانات السجل وآلية يمكن استخدامها لمسح البيانات القديمة.
المهام
الجزء الأخير في وحدة إدارة الوصول عن بُعد الذي أريد أن أشير إليه هو شريط المهام على الجانب الأيمن من شاشتك. تتغير الإجراءات والخيارات المعروضة في شريط المهام هذا حسب الجزء من الوحدة الذي تتنقل خلاله. تأكد من مراقبة هذا الجانب من شاشتك لإعداد بعض الوظائف المتقدمة الأخرى. تتضمن بعض الأمثلة على المهام المتاحة إنشاء تقارير الاستخدام، وتحديث الشاشة، وتمكين أو تعطيل VPNs، وتكوين توازن الحمل الشبكي أو تكوينات المواقع المتعددة إذا كنت تقوم بتشغيل خوادم وصول عن بُعد متعددة.
ال DA، VPN، أو AOVPN؟ أيهما أفضل؟
كانت VPNs موجودة منذ فترة طويلة، مما يجعلها فكرة مألوفة لأي شخص يعمل في تكنولوجيا المعلومات. يقدم Always On VPN بالتأكيد نصيبه من القدرات الجديدة، ولكن تحت السطح، ما يفعله AOVPN هو إطلاق اتصال VPN تقليدي، لذا فإن تدفق الاتصال مشابه لما عرفناه دائمًا. في هذا الفصل، ناقشنا أيضًا الكثير عن DA لتوضيح هذا البديل لتوصيل عملائك البعيدين بمركز البيانات تلقائيًا. الآن بعد أن تعرف أن هناك منصتين رائعتين للاتصال مدمجتين في Windows Server 2022 لتمكين القوى العاملة المتنقلة لديك، أيهما أفضل؟
لا تحتاج للاختيار! يمكنك تشغيل كلتا التقنيتين جنبًا إلى جنب، حتى على نفس خادم الوصول عن بُعد. كل تقنية لها مزاياها وعيوبها، والطرق التي تستخدم بها كل منهما، أو كلاهما، ستعتمد على العديد من المتغيرات. يجب أن تأخذ في الاعتبار المستخدمين، أجهزة الكمبيوتر العميلة الخاصة بك، واحتياجات مؤسستك الفردية في عملية اتخاذ القرار. دعنا نناقش بعض الاختلافات بين DA وVPNs حتى تتمكن من اتخاذ قرارات ذكية حول منصات الاتصال التي تتناسب مع مؤسستك.
مرتبط بالنطاق أم لا؟
أحد أكبر المتطلبات لجهاز الكمبيوتر العميل لـ DA هو أنه يجب أن يكون مرتبطًا بالنطاق. بينما يبدو هذا المتطلب في حد ذاته ليس كبيرًا، إلا أنه يحمل بعض الدلالات. الثقة بجهاز الكمبيوتر بما يكفي للانضمام إلى النطاق من المرجح أن تعني أن الكمبيوتر المحمول مملوك للشركة. كما يعني على الأرجح أن هذا الكمبيوتر المحمول تم بناؤه وتجهيزه في البداية من قبل فريق تكنولوجيا المعلومات. الشركات التي تتعود على السماح للموظفين بشراء أجهزة الكمبيوتر الخاصة بهم لاستخدامها لأغراض العمل قد لا تجد أن DA يناسب هذا النموذج بشكل جيد. DA ليس مثاليًا أيضًا في الحالات التي يستخدم فيها الموظفون أجهزة الكمبيوتر المنزلية الخاصة بهم للاتصال بالعمل عن بُعد.
في هذه الأنواع من الحالات، مثل الكمبيوترات المنزلية والشخصية، قد يكون VPN أفضل لتلك المهمة. يمكنك الاتصال بـ VPN (بما في ذلك Always On VPN) من جهاز Windows غير مرتبط بالنطاق، ويمكنك حتى إنشاء اتصالات VPN (اتصالات يدوية) من العديد من الأجهزة غير التابعة لـ Microsoft. iOS، Android، Windows phones، وMac - جميع هذه المنصات لديها عميل VPN مدمج يمكن استخدامه للاتصال بمستمع VPN على خادم الوصول عن بُعد في Windows Server 2022. إذا كانت الحل الوحيد للوصول عن بُعد هو DA، فلن تكون قادرًا على توفير منصة اتصال للأجهزة غير المرتبطة بالنطاق.
تذكر أنه، بينما يعتبر Always On VPN أكثر مرونة من DA في هذا الصدد، إذا كنت تنوي استخدام نفق جهاز AOVPN، فسيتعين على الأجهزة الخاصة بك أن تكون مرتبطة بالنطاق.
التشغيل التلقائي أو اليدوي
هناك طرق متعددة للنظر إلى هذا الموضوع. عند مناقشة ما إذا كان DA أو VPN تقليدي أفضل، فإن DA هو الفائز الواضح. لا أحد يرغب في جعل المستخدمين يفتحون اتصالًا ويطلقونه يدويًا لإنشاء اتصال VPN عندما تكون هناك منصة تلقائية متاحة للاستخدام.
ومع ذلك، يجلب Always On VPN الاتصال التلقائي والسلس إلى عالم VPN. AOVPN شبه سلس مثل DA في هذا الصدد. أقول شبه لأن، في وقت الكتابة، من الصعب جدًا جعل نفق الجهاز يعمل بشكل جيد. هذا يعني أن معظم الشركات التي تقوم بنشر AOVPN تستخدم فقط نفق المستخدم. في سيناريو نفق المستخدم، يتصل VPN تلقائيًا، ولكن ليس حتى يمر المستخدم بشاشة تسجيل الدخول. هذا يعني في هذه الحالات أن DA لا يزال يحمل ميزة على AOVPN لأن DA يتصل بسلاسة عند شاشة تسجيل الدخول. هذا يمكن من إعادة تعيين كلمات المرور والمستخدمين الجدد في النطاق تسجيل الدخول إلى الأجهزة المتصلة بـ DA. آمل أن تمكن التحسينات المستقبلية من وجود أنفاق أجهزة AOVPN وأنفاق المستخدمين معًا بطريقة مستقرة، مما سيمنح اتصالاً حقيقيًا دائمًا لأجهزة AOVPN.
البرامج مقابل المدمجة
أنا من محبي Ikea. إنهم يقومون بعمل رائع في توفير منتجات عالية الجودة بتكلفة منخفضة، وبطريقة ما يعبئون هذه المنتجات داخل صناديق صغيرة جدًا. بعد أن تدفع ثمن المنتج، تفتح الصندوق، تجمعه، ثم تختبره للتأكد من أنه يعمل - إنه رائع. إذا كنت لا ترى إلى أين يتجه هذا، سأعطيك تلميحًا: إنها تشبيه لـ VPN التقليدية من طرف
ثالث، حيث تقوم عادةً بدفع ثمن منتج VPN من بائع، وتفتح الصندوق، وتنفيذه بتكلفة إضافية، ثم تختبر المنتج. قد يتعطل هذا البرنامج بعد ذلك ويحتاج إلى إعادة التثبيت أو التكوين، وبالتأكيد سيأتي مع تحديثات برامج تحتاج إلى إتمامها في المستقبل. صيانة، صيانة، صيانة.
ربما شاهدت الكثير من برامج تحسين المنازل مؤخرًا، لكنني معجب بالمنازل التي تحتوي على مدمجات. المدمجات هي أساسًا أثاث دائم في المنزل، مدمج في الجدران، الزوايا، أو أي مكان يحدث أن يكون. يضيف قيمة، ويتكامل مع المنزل بشكل أفضل بكثير من الأثاث الذي تم تجميعه بشكل منفصل ثم تم وضعه ضد الجدار في الزاوية.
DA وAlways On VPN مثل المدمجات. إنهم يعيشون داخل نظام التشغيل. لا يوجد برامج للتثبيت، لا برامج للتحديث، ولا برامج لإعادة التثبيت عندما يتعطل. كل ما يحتاجه DA وAOVPN موجود بالفعل في Windows اليوم؛ أنت فقط لا تستخدمه. أوه، وهو مجاني! حسنًا، مدمج في تكلفة ترخيص Windows الخاص بك على أي حال. لا توجد تراخيص مستخدم CAL، ولا تكاليف ترخيص مستمرة متعلقة بتنفيذ واحدة من حلول الوصول عن بُعد من Microsoft.
إذا كان لديك قوة عاملة تتكون من أجهزة Windows 10 و11، فإن Microsoft DirectAccess أو Microsoft Always On VPN هما الفائزان الواضحان عند مقارنتهما بأي حل اتصال VPN من طرف ثالث.
مشاكل كلمة المرور وتسجيل الدخول مع VPNs التقليدية
إذا كنت قد عملت من قبل في مكتب المساعدة لشركة تستخدم VPN، فأنت تعرف ما أتحدث عنه. هناك سلسلة من مكالمات الدعم الشائعة التي تحدث في عالم VPN المتعلقة بكلمات المرور. في بعض الأحيان، ينسى المستخدم كلمة المرور الخاصة به. ربما انتهت صلاحية كلمة المرور وتحتاج إلى التغيير - آه! VPN لا يتعامل مع هذا السيناريو بشكل جيد أيضًا. أو ربما قام الموظف بتغيير كلمة المرور المنتهية صلاحيتها على سطح المكتب الخاص به قبل مغادرته للعمل لهذا اليوم، ولكنه الآن يحاول تسجيل الدخول عن بُعد من جهاز الكمبيوتر المحمول الخاص به ولا يعمل.
ما هو الحل لمشاكل كلمة المرور مع VPN؟ إعادة تعيين كلمة مرور المستخدم في Active Directory، ثم طلب من المستخدم الحضور إلى المكتب لكي يقوم الكمبيوتر المحمول بمزامنة جديدة مع النطاق والاعتراف بكلمة المرور الجديدة. نعم، هذا النوع من المكالمات الهاتفية لا يزال يحدث كل يوم. هذا أمر مؤسف، لكنه مشكلة حقيقية محتملة مع VPNs القديمة.
الأخبار السارة هي أن حلول الوصول عن بُعد من Microsoft الجديدة لا تواجه هذه الأنواع من المشاكل! نظرًا لأن DirectAccess (DA) و Always On VPN (AOVPN) جزء من نظام التشغيل، فإن لديهما القدرة على الاتصال في أي وقت يكون فيه Windows متصلًا بالإنترنت. يشمل هذا شاشة تسجيل الدخول! حتى إذا كنت جالسًا على شاشة تسجيل الدخول أو القفل، والنظام ينتظر مني إدخال اسم المستخدم وكلمة المرور، طالما أن لدي اتصال بالإنترنت، فإن لدي أيضًا نفق DA أو نفق جهاز Always On VPN. هذا يعني أنني يمكنني القيام بمهام إدارة كلمات المرور بنشاط. إذا انتهت صلاحية كلمة المرور الخاصة بي وأحتاج إلى تحديثها، فسيعمل ذلك. إذا نسيت كلمة المرور الخاصة بي ولا أستطيع الدخول إلى جهاز الكمبيوتر المحمول الخاص بي، يمكنني الاتصال بمكتب المساعدة وطلب منهم إعادة تعيين كلمة المرور. يمكنني بعد ذلك تسجيل الدخول فورًا إلى جهاز DA أو AOVPN الخاص بي باستخدام كلمة المرور الجديدة، من منزلي.
وظيفة رائعة أخرى يمكن أن تحققها هذه السلاسة هي القدرة على تسجيل الدخول باستخدام حسابات مستخدمين جديدة. هل سبق لك أن سجلت الدخول إلى جهاز الكمبيوتر المحمول الخاص بك كحساب مستخدم مختلف من أجل اختبار شيء ما؟ نعم، يمكن ذلك عبر DA و AOVPN أيضًا. على سبيل المثال، أنا جالس في المنزل وأحتاج إلى مساعدة أحد موظفي المبيعات في حل مشكلة في أذونات الملفات. أشك في أن المشكلة تتعلق بحساب المستخدم الخاص بهم، لذا أريد تسجيل الدخول إلى جهاز الكمبيوتر المحمول الخاص بي كأنني هم لاختبار ذلك. المشكلة هي أن حساب المستخدم الخاص بهم لم يقم بتسجيل الدخول إلى جهاز الكمبيوتر المحمول الخاص بي من قبل. مع VPN، ليس هناك فرصة؛ لن يعمل هذا. مع DA، قطعة من الكعكة! ببساطة أسجل الخروج، وأدخل اسم المستخدم وكلمة المرور الخاصين بهم، وهنا. أنا مسجل الدخول، بينما لا أزال جالسًا في المنزل بملابس النوم.
من المهم ملاحظة أنه يمكنك تشغيل كل من اتصالات DA و VPN على نفس خادم الوصول عن بُعد في Windows Server 2022. يتيح لك ذلك استضافة العملاء الذين يتصلون عبر DA، وعبر AOVPN، وأيضًا عبر اتصالات VPN التقليدية إذا كان لديك أجهزة غير Windows تحتاج إلى الاتصال. إذا كانت أي من هذه التقنيات الاتصال تحتوي على ميزات يمكنك الاستفادة منها، فاستخدمها جميعًا!
الجدران النارية المقيدة للمنافذ
أحد المكالمات الشائعة المتعلقة بـ VPN إلى مكتب المساعدة كان دائمًا هو أن VPN لا يتصل من هذا الفندق. لسوء الحظ، معظم البروتوكولات التي تستخدمها VPN للاتصال ليست صديقة للجدران النارية. من المحتمل أن جهاز التوجيه الخاص بك في المنزل يسمح بجميع حركة المرور الخارجة، لذا من اتصال الإنترنت المنزلي الخاص بك، كل شيء على ما يرام عند الاتصال باستخدام بروتوكول VPN. ولكن خذ هذا الكمبيوتر المحمول ونقله إلى مقهى عام، أو فندق، أو مطار، وفجأة يفشل VPN في الاتصال، مع وجود خطأ غريب. عادة ما يكون هذا ناتجًا عن أن اتصال الإنترنت العام يمر عبر جدار ناري يقيد المنافذ. تقوم هذه الجدران النارية بتقييد الوصول الخارجي، وغالبًا ما تحجب أشياء مثل ICMP و UDP، مما يمكن أن يتداخل مع اتصالات VPN. في الحالات الأكثر شدة، قد تسمح هذه الجدران النارية فقط بمنفذين خارجيين: TCP 80 للـ HTTP و TCP 443 لحركة مرور مواقع HTTPS. ثم تقوم بحجب كل شيء آخر.
في حالة أنك تجلس خلف جدار ناري مقيد للمنافذ، كيف تتعامل تقنيات الوصول عن بُعد الجديدة هذه مع الاتصال؟
تم تصميم DA للتعامل مع هذا السيناريو من البداية. تذكر تلك البروتوكولات الثلاثة المختلفة التي يمكن أن يستخدمها DA للاتصال؟ الخيار البديل يسمى IP-HTTPS، وهو يمرر حركة المرور الخاصة به داخل TCP 443. لذا، حتى عند الجلوس خلف أكثر الجدران النارية صرامة، سيتصل DA تلقائيًا ودون تردد.
عادةً ما يتم نشر Always On VPN (كما ينبغي) مع مراعاة أفضل الممارسات، والتي تشمل تفضيل IKEv2 كبروتوكول الاتصال VPN. في الواقع، بعض الشركات تقوم بنشر AOVPN باستخدام IKEv2 فقط. بالنسبة لهؤلاء الأشخاص، سيكون جدار ناري مقيد للمنافذ ضارًا لاتصال VPN الخاص بالمستخدم، حيث يستخدم IKEv2 منافذ UDP للاتصال. لن يعمل. لذا، نأمل أن تكون النقطة الأساسية التي تأخذها من هذا هي أنه عند إعداد AOVPN، تأكد من اتخاذ الخطوات اللازمة لتمكين اتصال SSTP VPN كطريقة بديلة. يتدفق SSTP داخل TCP 443، مما يمكنه من الاتصال حتى من خلال الجدران النارية الصارمة.
في الواقع، عملت مؤخرًا على هذا السيناريو بالضبط مع شخص كان يحاول اتخاذ قرار بشأن ما إذا كان يريد إعداد DA أو Always On VPN لأجهزته البعيدة. كانت هذه شركة تدير أجهزة كمبيوتر للعديد من المستشفيات ومكاتب الأطباء، ولم يكن لديهم روابط WAN لتلك المكاتب. كانت المكاتب تحتوي على اتصال بالإنترنت، لذا كنا بحاجة إلى القدرة على الحفاظ على اتصال هذه الأجهزة تلقائيًا مع مركز البيانات الرئيسي في جميع الأوقات. حتى الآن في السيناريو، يمكن أن يناسب أي من DA أو Always On VPN الفاتورة. ثم، خلال الاختبارات، اكتشفنا أن العديد من شبكات المستشفيات تقيد الوصول إلى الإنترنت الخارجي. الطريقة الوحيدة التي يمكن أن يتصل بها DA كانت عبر IP-HTTPS، والطريقة الوحيدة التي يمكن أن يتصل بها AOVPN كانت عبر SSTP. ليست مشكلة، أليس كذلك؟ إلا أنها كانت مشكلة. ترى، يتم التعامل مع هذه المحطات العمل البعيدة غالبًا كمحطات كشك، حيث يمكن للعشرات من الموظفين المختلفين الحضور في أي لحظة وتسجيل الدخول إليها. في كثير من الأحيان، يعني ذلك أن المستخدمين الذين لم يسجلوا الدخول إلى هذه الأجهزة من قبل يقومون بتسجيل الدخول إليها، لذا لا توجد بيانات اعتماد مخزنة مؤقتًا على تلك الأجهزة.
إذا لم تكن قد اكتشفت الأمر بالفعل، لم يكن لدينا خيار سوى استخدام DA في هذا السيناريو. يتصل DA دائمًا عند شاشة تسجيل الدخول، حتى عند استخدام طريقة IP-HTTPS البديلة. ومع ذلك، يمكن أن يستخدم Always On VPN فقط IKEv2 عند شاشة تسجيل الدخول، لأن نفق الجهاز يتطلب IKEv2. يستخدم هذا UDP وكان محجوبًا من قبل الجدار الناري، لذا كانت الطريقة الوحيدة التي يمكن أن يتصل بها AOVPN هي استخدام SSTP، لكن هذا لم يكن متاحًا حتى يمكن إطلاق نفق المستخدم، والذي كان فقط بعد أن قام المستخدم بتسجيل الدخول إلى الجهاز. كان هذا مثالًا واقعيًا مثيرًا للاهتمام للغاية ساعد في تسليط الضوء على عملية اتخاذ القرار التي قد تحتاج إلى اتخاذها لبيئاتك الخاصة.
الفصل اليدوي
إذا لم تكن مقتنعًا بالفعل بأن VPN التقليدية القديمة أصبحت شيئًا من الماضي، دعنا نلقي نقطة أخرى عليك. عند استخدام VPNs التي تتطلب من المستخدم تشغيل الاتصال يدويًا، فإنك تعتمد على المستخدم نفسه للحفاظ على إدارة هذا الجهاز وتحديثه وتحديثه. بالطبع، قد تكون لديك أنظمة تلقائية تقوم بهذه الأشياء من أجلك، مثل WSUS و SCCM و Group Policy. لكن عندما يكون الكمبيوتر المحمول خارجًا ويتجول بعيدًا عن الشبكة المحلية (LAN)، لا يمكن لأنظمة الإدارة تلك القيام بمهامها إلا عندما يقرر المستخدم إنشاء اتصال VPN. من الممكن جدًا أن يقضي الكمبيوتر المحمول أسابيع خارج الشبكة تمامًا، ويتصل بعشرات النقاط الساخنة غير الآمنة بينما يتجول هذا الموظف حول الكاريبي على متن سفينة سياحية.
بعد أسابيع من الاحتفال وNetflix، يقومون بعد ذلك بالاتصال مرة أخرى بالشبكة المحلية أو عبر VPN للقيام ببعض العمل، ولم تكن تعلم، أن هذا الجهاز كان غير متصل لفترة طويلة بحيث قد التقط جميع أنواع البرامج الإبداعية الجديدة التي يجب عليك الآن التعامل معها.
ليس الأمر كذلك مع أدوات الوصول عن بُعد من Microsoft! توفير خيار الاتصال التلقائي مثل Always On VPN أو DA يعني أن الكمبيوتر المحمول كان سيكون متصلًا ويتلقى جميع سياسات الأمان والتحديثات الخاصة به خلال تلك العطلة بأكملها.
في الواقع، لكي تأخذها خطوة أخرى، على جهاز متصل بـ DA، لا يمكن للمستخدم تعطيل أنفاق DA الخاصة به حتى لو أراد ذلك. لديك القدرة على تزويدهم بزر Disconnect، ولكن ذلك فقط يخدع الاتصال من وجهة نظر المستخدم ليشعر بأنه DA غير متصل. في الواقع، لا تزال أنفاق IPsec تتدفق في الخلفية، مما يسمح دائمًا بمهام الإدارة بالحدوث.
قدرات التوازن التلقائي
باختصار، DA هو الفائز هنا. يحتوي Console إدارة الوصول عن بُعد في Windows Server 2022 على قدرات مدمجة لتكوين وإدارة مجموعات من خوادم DA. يمكنك تكديس عدة خوادم DA فوق بعضها البعض، وربطها معًا في مجموعات متوازنة الحمولة، وتوفير التكرار والمرونة مباشرة من داخل الكونسول، دون الحاجة إلى أجهزة إضافية أو اعتبارات توازن الأحمال التقليدية. يمكنك حتى تكوين شيء يسمى DirectAccess Multisite، حيث يمكنك تكوين خوادم DA التي تقع في مواقع جغرافية مختلفة معًا في مجموعات، مما يوفر المرونة بين المواقع. تقارن هذا بقدرات التوازن اليدوي التي ستحتاج إلى توفيرها باستخدام VPNs التقليدية، ويصبح من السهل جدًا رؤية السبب في أن DirectAccess فاز هنا.
توزيع تكوينات العميل
النظر الأساسي الأخير الذي يجب أن تأخذه بعين الاعتبار عند اتخاذ قرار بشأن الاتجاه الذي تريد الذهاب إليه للوصول عن بُعد هو الطريقة التي يتم بها دفع إعدادات الجانب العميل إلى أجهزة الكمبيوتر الخاصة بهم:
- **الطرف الثالث VPN**: لقد ناقشنا بالفعل الجوانب السلبية للتعامل مع تطبيقات البرمجيات لموردي VPN الطرف الثالث. إذا كان بإمكانك استخدام شيء مدمج في نظام تشغيل Windows بدلاً من ذلك، فهذا يبدو كخيار بديهي.
-ال **Always On VPN**: الطريقة الموصى بها لنشر إعدادات AOVPN إلى أجهزة الكمبيوتر العميلة هي من خلال استخدام حل MDM، أي SCCM أو Intune. إذا كان لديك أحد هذه الأنظمة، فإن نشر إعدادات AOVPN إلى قوة العمل الخاصة بك يكون سهلًا. إذا لم يكن لديك أحد هذه الأنظمة، فلا يزال ممكنًا، لكنه ليس عملية بسيطة.
-ال **DirectAccess**: أعتقد أن نهج DA في توزيع إعدادات العميل هو الأسهل للعمل معه والأكثر مرونة. يجب أن تضع في اعتبارك أن DA مخصص فقط لأنظمة الانضمام إلى النطاق. بالنظر إلى أنه يمكنك توقع انضمام جميع العملاء إلى النطاق، يمكنك الوصول إلى توزيع إعدادات الاتصال DA عبر Group Policy، والتي توجد داخل أي بنية تحتية مدفوعة من Microsoft. آمل حقًا أن نرى خيار توزيع Group Policy يضاف في المستقبل لنشر إعدادات Always On VPN. إذا تم تقديم هذه القدرة، فأنا واثق تمامًا من أنها ستصبح الطريقة الأكثر شيوعًا لنشر إعدادات AOVPN على الفور.
لتلخيص هذا الموضوع بأكمله، عند مقارنة DA ضد VPN التقليدية التي يتم إطلاقها يدويًا، يحتل DA المركز الأول بشكل نظيف. لا يوجد حقًا مقارنة. الآن بعد أن أصبح لدينا Always On VPN تحت تصرفنا، أصبحت الفوائد الواحدة على الأخرى (DA أو AOVPN) غير واضحة. كلاهما يحقق الكثير من نفس الأشياء، ولكن بطرق مختلفة. العوامل الرئيسية التي تقرر للعملاء حتى الآن تبدو أنها قدرات نشر الجانب العميل، سواء كان لديهم حل MDM أم لا، ومدى أهمية اتصال نفق الجهاز لهم. هدف Microsoft هو أن يكون لـ AOVPN التكافؤ الوظيفي مع DA، وهو يقترب من ذلك. يحتوي Always On VPN أيضًا على بعض ميزات المصادقة المتقدمة التي لا يحتوي عليها DA، مثل التكامل مع Windows Hello for Business أو Azure MFA.
ال Web Application Proxy
ال DA وVPN هما تقنيتان رائعتان للوصول عن بُعد، والجمع بين الاثنين معًا يمكن أن يوفر حلاً كاملاً للوصول عن بُعد لمؤسستك، دون الحاجة إلى دفع ثمن أو العمل مع حل طرف ثالث. والأفضل من ذلك، في Windows Server 2022، هناك عنصر آخر من دور الوصول عن بُعد المتاح للاستخدام. هذه القطعة الثالثة من قصة الوصول عن بُعد هي Web Application Proxy. هذه في الأساس آلية proxy عكسية، تمنحك القدرة على أخذ بعض تطبيقات HTTP وHTTPS التي تستضيفها داخل شبكتك المؤسسية ونشرها بشكل آمن على الإنترنت. أي شخص عمل مع تقنيات Microsoft في مساحة الشبكات المحيطية على مدار العقد الماضي سيتعرف على منتج يسمى Forefront Unified Access Gateway (UAG)، الذي حقق وظائف مشابهة. كان UAG حلاً شاملاً لـ SSL VPN، تم تصميمه أيضًا لنشر التطبيقات الداخلية على الإنترنت عبر SSL. كان أكثر قوة بكثير من مجرد proxy عكسي بسيط، بما في ذلك مكونات مثل المصادقة المسبقة، SSTP VPN، وRDS gateway؛ حتى DA نفسه يمكن تشغيله عبر UAG.
إذا كان جميع عمالك المتنقلين لديهم إمكانية إطلاق إما DA أو VPN، فمن المحتمل أنك لا تحتاج إلى WAP. ومع ذلك، مع نمو العقلية السحابية، من الشائع جدًا أن يتوقع المستخدمون أنه يمكنهم فتح متصفح الويب من أي جهاز كمبيوتر، في أي مكان، والوصول إلى بعض تطبيقاتهم. يتم الآن توفير الوصول إلى المستندات غالبًا من خلال خدمات الويب مثل SharePoint. يمكن الوصول إلى البريد الإلكتروني عن بُعد، من أي جهاز كمبيوتر، عن طريق الوصول إلى Outlook Web Access. هذا سهل للغاية عند استخدام الخدمات السحابية مثل Azure وMicrosoft 365، لكن الكثيرين لا يدركون أن هذا يمكن أن يكون صحيحًا أيضًا بالنسبة لخدمات Exchange وSharePoint الموجودة في الموقع.
الكثير من التطبيقات والكثير من البيانات يمكن الوصول إليها فقط من خلال متصفح الويب، وهذا يمكن الموظفين من الوصول إلى هذه البيانات دون الحاجة إلى إنشاء نفق مؤسسي كامل مثل VPN. إذن ما هو الاستخدام الواقعي لـ WAP؟ أجهزة الكمبيوتر المنزلية التي لا تريدها أن تكون متصلة بشبكة VPN. بهذه الطريقة، لا تحتاج إلى القلق كثيرًا بشأن صحة وحالة أجهزة الكمبيوتر المنزلية أو المملوكة للمستخدم، حيث أن التفاعل الوحيد الذي لديهم مع شركتك هو من خلال متصفح الويب. هذا يحد من الاحتمالية لنشاط ضار للدخول إلى شبكتك من هذه الأجهزة. كما ترى، فإن التكنولوجيا مثل WAP لديها بالتأكيد مكان في سوق الوصول عن بُعد.
لدي آمال أنه مع مرور الوقت، سيتم تحسين WAP وتطويره ليصبح بديلاً حقيقيًا لـ UAG. كان UAG يعمل على Windows Server 2008 R2 وتم إيقافه رسميًا كمنتج من Microsoft. أقرب حل تملكه Microsoft الآن إلى UAG هو دور WAP. لم يكن شاملاً بعد، لكنهم يعملون على تحسينه. حاليًا، WAP مفيد لنشر الوصول إلى تطبيقات الويب البسيطة. يمكنك أيضًا نشر الوصول إلى العملاء الأثرياء الذين يستخدمون مصادقة HTTP الأساسية، مثل Exchange ActiveSync، على الرغم من أن المصادقة الأساسية أصبحت مؤخرًا على القائمة السوداء من قبل فرق الأمن، لذلك لا أرى أن هذا يتم استخدامه كثيرًا. يتضمن أيضًا القدرة على نشر البيانات للعملاء الذين يستخدمون MSOFBA، مثل عندما يحاول المستخدمون سحب البيانات المؤسسية من تطبيقات Word أو Excel الخاصة بهم التي تعمل على الكمبيوتر المحلي.
يمكن استخدام WAP لنشر الوصول عن بُعد إلى أشياء مثل بيئات Exchange وSharePoint. هذه ليست شيئًا صغيرًا، حيث أن هذه تقنيات يستخدمها الجميع تقريبًا، لذلك يمكن أن يكون مفيدًا بالتأكيد لشركتك تنفيذ WAP لنشر الوصول الآمن إلى هذه الموارد؛ إنه بالتأكيد أفضل من NATing مباشرة إلى خادم Exchange الخاص بك.
ال WAP كـ AD FS Proxy
طريقة أخرى مفيدة يمكنك من خلالها استخدام خادم WAP هي عند إعداد Active Directory Federation Services (AD FS) في شبكتك (هذا هو الاستخدام الأكثر شيوعًا لـ WAP حاليًا). AD FS هي تكنولوجيا مصممة لتمكين تسجيل الدخول الموحد للمستخدمين والاتحاد مع الشركات الأخرى، وبالتالي يتضمن أخذ حركة المرور القادمة من الإنترنت إلى شبكتك الداخلية. في الماضي، كان هناك مكون دور Windows Server يرافق AD FS، يسمى AD FS Proxy. في أحدث إصدارات AD FS، لم يعد هذا الدور المنفصل موجودًا وتم استبداله بمكون WAP من دور الوصول عن بُعد. هذا يوحد حل الوصول عن بُعد بشكل أفضل، ويجلب حركة المرور الواردة لـ AD FS من خلال خادم الوصول عن بُعد الرسمي، بدلاً من الحاجة إلى خادم AD FS Proxy منفصل. أي شخص ينفذ AD FS المواجهة للخارج في بيئته سيجد نفسه على الأرجح مضطرًا لنشر WAP في مرحلة ما.
متطلبات WAP
للأسف، تأتي القدرة على الاستفادة من Web Application Proxy مع متطلب غير مريح إلى حد ما: يجب أن يكون لديك AD FS مثبت في بيئتك لتتمكن من استخدامه، حتى لاختباره، لأن تكوين WAP يتم تخزينه داخل AD FS.
لا يتم تخزين أي من معلومات تكوين WAP على خادم الوصول عن بُعد نفسه، مما يجعل خادمًا خفيف الوزن يمكن تحريكه أو تغييره أو إضافته بسهولة. الجانب السلبي لهذا هو أنك يجب أن يكون لديك AD FS يعمل في بيئتك حتى يتمكن WAP من الحصول على مكان لتخزين معلومات التكوين تلك.
في حين أن التكامل الوثيق مع AD FS يعني أن لدينا خيارات مصادقة أفضل، ويمكن للمستخدمين الاستفادة من تسجيل الدخول الموحد لـ AD FS لتطبيقاتهم التي يتم نشرها من خلال WAP، فقد ثبت حتى الآن أن هذا يشكل عائقًا أمام التنفيذ للشركات الصغيرة. العديد من الناس لم يقوموا بتشغيل AD FS بعد، وإذا كان السبب الوحيد الذي ينظرون إليه لتنفيذ AD FS هو حتى يتمكنوا من استخدام WAP لنشر بعض تطبيقات الويب على الإنترنت، فقد لا يختارون الاستثمار في الوقت والجهد فقط لجعل ذلك يحدث.
شيء يجب أن تضعه في اعتبارك إذا كنت مهتمًا باستخدام WAP ومن ثم تنظر إلى متطلب AD FS هو أن AD FS يمكن بالتأكيد استخدامه لأغراض أخرى. في الواقع، أحد استخداماته الأكثر شيوعًا في الوقت الحاضر هو التكامل مع Office 365. إذا كنت تخطط لدمج Office 365 في بيئتك، AD FS هو أداة رائعة يمكن أن تعزز قدرات المصادقة لذلك المرور.
التحسينات الأخيرة لـ WAP
تم تقديم WAP في Server 2012 R2 وحصل على العديد من التحسينات عند إصدار Windows Server 2016. لم تكن هناك تعديلات كبيرة منذ ذلك الحين، لكنه لا يزال من المهم الإشارة إلى الفوائد الأخيرة التي تم إدخالها في هذه الميزة لإظهار أنها لا تزال تتعلم أشياء جديدة. التالية هي بعض التحسينات التي تم إجراؤها إذا لم تنظر إلى WAP منذ نسخته الأولى.
المصادقة المسبقة لـ HTTP Basic
هناك طريقتان مختلفتان يمكن للمستخدمين من خلالهما المصادقة على التطبيقات التي يتم نشرها بواسطة WAP: المصادقة المسبقة أو المصادقة بالتمرير. عند نشر تطبيق مع المصادقة المسبقة، فهذا يعني أن المستخدمين سيحتاجون إلى المرور بواجهة AD FS للمصادقة على أنفسهم قبل السماح لهم بالدخول إلى تطبيق الويب نفسه.
في نظري، المصادقة المسبقة هي مكون حرج لأي proxy عكسي ويجب أن أكون عالقًا بين الصخور والمكان الصعب لنشر تطبيق خارجيًا لا يتطلب المصادقة المسبقة. ومع ذلك، الخيار الثاني هو القيام بالمصادقة بالتمرير، ويفعل ذلك بالضبط. عند نشر الوصول إلى تطبيق واختيار المصادقة بالتمرير، كل ما يفعله WAP هو نقل الحزم من الإنترنت إلى خادم التطبيق، في شكل proxy عكسي حقيقي. يمكن للمستخدمين الوصول إلى تطبيق الويب دون مصادقة، لذلك من الناحية النظرية، يمكن لأي شخص على الإنترنت الوصول إلى واجهة تطبيقك. من هناك، من المحتمل أن يتطلب التطبيق نفسه أن يصادق المستخدم، ولكن لا يوجد حماية الرجل في المنتصف تحدث؛ هذا التطبيق الويب متاح للجمهور لعرضه. كما ترى، لا أوصي باتخاذ هذا الطريق.
نحن نعلم بالفعل أن WAP يمكنه المصادقة المسبقة على تطبيقات الويب، ولكن النسخة الأصلية لم تتمكن من القيام بأي نوع من المصادقة المسبقة على تطبيقات HTTP Basic، مثل عندما تريد شركة نشر الوصول إلى Exchange ActiveSync.
هذا العجز يترك ActiveSync مكشوفًا قليلاً للعالم الخارجي ويشكل خطرًا أمنيًا. لحسن الحظ، تغير هذا في Windows Server 2016 – يمكنك الآن المصادقة المسبقة على تدفقات المرور التي تستخدم HTTP Basic.
إعادة توجيه HTTP إلى HTTPS
المستخدمون لا يحبون الخروج عن طريقهم أو إضاعة الوقت بتذكر أنهم يحتاجون إلى إدخال HTTPS:// أمام عنوان URL عند وصولهم إلى التطبيقات. يفضلون تذكر email.contoso.com فقط. كان عدم قدرة WAP على إعادة توجيه HTTP إلى HTTPS مزعجًا وعائقًا أمام التبني، ولكن هذا قد تغير منذ ذلك الحين. يتضمن الآن WAP القدرة على التعامل مع إعادة توجيه HTTP إلى HTTPS، مما يعني أن المستخدمين لا يحتاجون إلى كتابة HTTPS في شريط عنوان المتصفح الخاص بهم بعد الآن؛ يمكنهم ببساطة كتابة اسم DNS للموقع وترك WAP يتعامل مع الترجمات.
نشر نطاقات Wildcard
الإصدارات المبكرة من WAP لم تلعب جيدًا مع بعض بيئات SharePoint، بسبب القيود في طريقة تعامل WAP مع أسماء النطاقات. يمكن أن يتضمن URL الخارجي المستخدم لنشر تطبيق من خلال WAP الآن معرف wildcard، مما يمكّن الإصدارات الأحدث من SharePoint في الموقع من النشر بنجاح على الإنترنت عبر WAP.
توجيه عناوين IP الخاصة بالعملاء إلى التطبيقات
في عالم الـ proxy العكسي وSSL VPN، نواجه أحيانًا تطبيقات تتطلب معرفة عنوان IP المحلي للعميل. في حين أن هذا المتطلب لا يحدث في كثير من الأحيان وعادة ما يكون مقصورًا على ما نسميه التطبيقات القديمة، إلا أنه يحدث بالفعل. عندما يحتاج خادم التطبيق الخلفي إلى معرفة عنوان IP الخاص بالعميل، يقدم هذا تحديًا كبيرًا مع حلول الـ proxy العكسي. عندما يتدفق مرور المستخدم عبر WAP أو أي proxy عكسي آخر، فإنه يشبه NAT، حيث تتغير معلومات عنوان IP المصدر في هذه الحزم. لا يستطيع خادم التطبيق الخلفي تحديد عنوان IP الخاص بالعميل، وتحدث المشاكل. الآن، يمكن لـ WAP نقل عنوان IP الخاص بالعميل إلى خادم التطبيق الخلفي، مما يخفف من هذه المشكلة.
نشر تطبيقات Remote Desktop Gateway
أحد العناصر التي كان UAG يستخدم بشكل شائع من أجلها هو نشر الوصول إلى Remote Desktop Services. كان UAG في الأساس بوابة سطح مكتب بعيدية، مما يتيح لك القدرة على نشر الوصول إلى خوادم RDSH، اتصالات RDP الفردية إلى أجهزة الكمبيوتر المكتبية، مثل في تنفيذ VDI، وحتى الوصول إلى تطبيقات RemoteApp. للأسف، لا يمكن لـ WAP القيام بأي من هذا، حتى في النسخة الجديدة، ولكن حقيقة أنهم أضافوا بعض الوظائف هنا تعني أن الحركة في الاتجاه الصحيح تحدث.
ما تم تحسينه فيما يتعلق بـ WAP وRemote Desktop هو أنه يمكنك الآن استخدام WAP لنشر الوصول إلى خادم Remote Desktop Gateway نفسه. تقليديًا، يجلس Remote Desktop Gateway على حافة الشبكة ويصل المستخدمين الخارجيين إلى خوادم سطح المكتب البعيد الداخلية أو RemoteApps. وضع WAP أمام Remote Desktop Gateway يسمح بمصادقة مسبقة أقوى لخدمات سطح المكتب البعيد ويخلق فصلًا أكبر بين الشبكات الداخلية والخارجية.
أصابع يدي كلها متشابكة على أمل أن نستمر في رؤية تحسينات في هذا المجال وأن يتم توسيع WAP لمعالجة حركة المرور مثل Remote Desktop بشكل أصلي، دون الحاجة حتى إلى Remote Desktop Gateway في المزيج.
تحسين وحدة التحكم الإدارية
كانت النسخة الأصلية من WAP داخل Windows Server 2012 R2 تُخدم بشكل أفضل باستخدام PowerShell لتنفيذها. لا يزال بإمكانك بالتأكيد استخدام PowerShell لإنشاء قواعد النشر الخاصة بك إذا اخترت ذلك، ولكن تم تحسين وحدة التحكم في إدارة الوصول عن بُعد من حيث صلتها بـ WAP. قبل أن تتمكن من العثور على WAP في وحدة التحكم في إدارة الوصول عن بُعد، تحتاج إلى التأكد من أن المربع المناسب تم تحديده أثناء تثبيت دور الوصول عن بُعد. إذا لم تقم بتحديد Web Application Proxy عند تثبيت ذلك الدور لأول مرة، فأعد زيارة وظيفة إضافة/إزالة الأدوار داخل Server Manager لإضافة WAP إلى هذا الخادم.
ملاحظة: على الرغم من أن WAP هو جزء من نفس دور Remote Access الذي يحتوي على DA وVPN، فإنه لا يُوصى بتشغيل WAP بجانب DA وVPN على نفس الخادم. كما تعلم بالفعل، يمكنك تشغيل اتصالات DA وVPN معًا في نفس الوقت على خادم Remote Access واحد. ولكن بمجرد الانتقال إلى WAP، يجب أن يكون هذا مكونًا مستقلاً. لا تشغل WAP على خادم DA/VPN، ولا تشغل DA/VPN على خادم WAP.
الآن بعد أن أضفنا Web Application Proxy إلى الخادم الخاص بنا، يمكنك فتح Remote Access Management Console ورؤية WAP مدرجًا داخل قسم Configuration. من هنا، يمكنك تشغيل Web Application Proxy Configuration Wizard وبدء تحديد خادم AD FS والشهادات التي تخطط لاستخدامها والمعايير الأخرى المطلوبة للدور.
ملخص
تتطلب طبيعة العالم اليوم أن تمكن معظم الشركات موظفيها من العمل من أي مكان. أصبح العمل من المنزل أمرًا عاديًا على مدار السنوات القليلة الماضية؛ مع وجود جائحة عالمية، شهدنا زيادات هائلة في نسبة الموظفين الذين يعملون خارج مبنى المكتب. تحتاج الشركات إلى طريقة آمنة ومستقرة وفعالة لتوفير الوصول إلى البيانات والتطبيقات الخاصة بالشركة لهؤلاء العمال المتنقلين. تم تصميم دور Remote Access في Windows Server 2022 لتحقيق ذلك بالضبط. مع وجود ثلاث طرق مختلفة لتوفير الوصول عن بعد إلى موارد الشركة، لم تكن أقسام تكنولوجيا المعلومات تتمتع بكمية كبيرة من التكنولوجيا المتاحة للوصول عن بعد في متناول يدها، وكلها مدمجة في نظام التشغيل Windows الذي يمتلكونه بالفعل. إذا كنت لا تزال تدعم نظام VPN تابع لجهة خارجية أو نظام VPN قديم، يجب عليك استكشاف القدرات الجديدة المتاحة هنا واكتشاف كم يمكن أن توفر لشركتك.
ال DA وAlways On VPN هما خيارات اتصال مثيرة للإعجاب وجذابة بشكل خاص—طريقة جديدة للنظر إلى الوصول عن بعد. الاتصال التلقائي يعني أن أجهزتك يتم تحديثها باستمرار لأنها دائمًا متصلة بخوادم الإدارة الخاصة بك. يمكنك تحسين إنتاجية المستخدم وأمان الشبكة في نفس الوقت. هذان الأمران عادة ما يكونان متناقضين في عالم تكنولوجيا المعلومات، ولكن مع حزمة الوصول عن بعد من Microsoft، يعملان بتناغم معًا.
بعد ذلك، سنلقي نظرة على بعض الوظائف الأمنية المدمجة في نظام التشغيل Windows Server 2022، وبعض الطرق التي يمكن بها تعزيز أمان الخوادم لتوفير أمان أفضل مما هو موجود في النسخة الأساسية.
النهاية
نكون هنا انتهينا من الفصل 8 تماما من شهادة MCSA المقدمة من Microsoft الأن نغوص في الأعماق
و لا بد وانت تقرا ان تكون مركز جيدا لكل معلومة ومعك ورقة وقلم , لانك بالتاكيد ستحتاجها
واذا واجهتك اي مشكلة في الفهم او ما شابه , يمكنك على الفور الذهاب الى المجتمع الخاص بنا في Telegram للمناقشة والتواصل معنا من هنا
او اذا واجهتك مشكلة في الموقع او تريد اجابة سريعة يمكنك الذهاب الى اخر صفحة في الموقع ستجد صفحة اتصل بنا موجودة يمكنك ارسالة لنا مشكلتك , وسيتم الرد عليها بسرعة جدا ان شاء الله
ويمكنك الأنضمام الى المجتمع Hidden Lock بالكامل مع جميع قنواته للأستفادة في اخر الأخبار في عالم التقنية وايضا الكتب بالمجان والكورسات والمقالات من خلال الرابط التالي لمجموعة القنوات من هنا
يمكنك ايضا متابعتنا في منصات X او Twitter سابقا , لمشاهدة الاخبار والمقالات السريعة والمهمة من
وفقط كان معكم Sparrow اتمنى ان تدعوا لي وتتذكروني في الخير دوما
