الفصل : 8
الجزء : 1
العنوان : الوصول عن بعد (Remote Access)
إتاحة القدرة للموظفين للوصول عن بُعد إلى موارد الشركة كانت ميزة كبيرة لمعظم الشركات، ولكنها لم تكن بالضرورة مطلبًا. لقد تغيرت هذه العقلية بشكل كبير على مدار السنوات القليلة الماضية، حيث يعمل العديد منا الآن من المنزل بشكل كامل بعد جائحة COVID-19. تتوقع معظم الشركات والموظفين الآن إنجاز عملهم من أي مكان يتواجدون فيه. تُعتبر الهواتف المحمولة جزءًا كبيرًا من هذه المعادلة، لكنها محدودة بسبب حجم الشاشات ونظم التشغيل المقيدة. لتوفير القدرة للعاملين عن بُعد على أداء وظائفهم من المنزل أو المقاهي أو الفنادق، استخدمنا تقليديًا الشبكات الافتراضية الخاصة Virtual Private Networks (VPNs) .
معظم VPNs في الأعمال التجارية اليوم تقدمها منتجات من شركات غير Microsoft. دور Remote Access في Windows Server 2022 هنا لتغيير ذلك. مع العديد من التحسينات التي تم إدخالها على مكونات VPN في Windows Server، أصبح الآن منصة ممكنة وآمنة لتوفير الوصول إلى موارد الشركة من الحواسيب البعيدة. بالإضافة إلى اتصال VPN، لدينا بعض التقنيات الأحدث التي تم تضمينها في Windows Server 2022 والتي تهدف أيضًا إلى توفير الوصول عن بُعد إلى موارد الشركة بطريقة مختلفة عن VPN التقليدية. المواضيع التي سنغطيها في هذا الفصل هي كما يلي:
- VPN التقليدي
- Always On VPN
- DirectAccess
- Remote Access Management Console
- DA، VPN، أو AOVPN أيهما أفضل
- Web Application Proxy
- متطلبات WAP
- أحدث التحسينات في WAP
ال VPN التقليدي
يتضمن VPN التقليدي قيام المستخدمين بالنقر على اتصال VPN الذي يتم تكوينه على أجهزتهم المحلية، ثم يقوم هذا الجهاز بإنشاء اتصال شبكة افتراضية خاصة آمن مع جهاز آخر موجود في مركز بياناتك، وغالبًا ما يكون جدارًا ناريًا.
ومع ذلك، إذا كان جدارك الناري لا يوفر قدرات نقطة نهاية VPN، أو إذا كنت ببساطة تريد حماية حركة مرور VPN بطريقة مختلفة، يمكنك استخدام Windows Server ليكون جهاز إنهاء VPN. لقد ذكرنا بالفعل دور Remote Access، وبالفعل هذا هو دور Windows Server الذي يمكن اختياره وتثبيته على Windows Server جديد. ومع ذلك، قبل القيام بهذه الخطوة، تريد وضع خطة للشبكات مع هذا السيرفر. يمكن لـ VPN server استخدام بطاقة NIC واحدة تكون داخل شبكتك المؤسسية، وفي هذه الحالة، ستحتاج إلى تكوين جدارك الناري لترجمة عناوين الشبكة (NAT) لحركة المرور من عنوان IP عام إلى عنوان IP خاص لـ NIC الداخلي. هذا ضروري لأن عملاء VPN الخاصين بك سوف يقومون بإنشاء اتصالات من الإنترنت إلى هذا VPN server. لكي تكون حركة المرور هذه ناجحة، يجب أن تهبط حركة العميل على السيرفر.
خيار آخر هو توفير بطاقتي NIC على هذا السيرفر. يمكن أن تكون إحداهما بطاقة NIC الداخلية، متصلة بالشبكة الداخلية. يمكن أن تكون البطاقة الثانية هي بطاقة NIC الخارجية أو بطاقة DMZ، ومتصلة وفقًا لذلك. يمكن أن يكون لهذه البطاقة عنوان IP عام خاص بها وتعلق مباشرة على الإنترنت، أو يمكن أن تكون متصلة داخل DMZ مع بعض الحماية حولها، وتُمرر الحركة عبرها هناك. الأسباب التي قد تجعلك تستخدم بطاقتي NIC تتعلق بالأمان بحيث يجلس هذا السيرفر الخاص بـ Windows وحركة المرور الخاصة به خلف بعض طبقات الحماية الخاصة بالجدار الناري. إذا اخترت استخدام بطاقتي NIC، فقد ترغب في الرجوع إلى حديثنا عن تكوين جدول التوجيه الصحيح لـ Windows، حيث ستكون في وضع يسمح لك بتعريف بوابة افتراضية على بطاقة NIC الخارجية ولكن ليس الداخلية، وستكون مطالبًا بتعريف مسارات ثابتة لتوجيه حركة مرور VPN حول شبكتك الداخلية.
خدمة Routing and Remote Access (RRAS)
بمجرد تكوين الشبكات على VPN server الخاص بك، حان الوقت لتثبيت دور Remote Access. جميع مكونات الاتصال المختلفة التي سنناقشها في هذا الفصل موجودة داخل هذا الدور نفسه لـ Remote Access، لذا ستجد أنه عند تثبيت الدور، يُطلب منك بعض التفاصيل الإضافية حول مكونات الدور التي تحاول تمكينها. لأغراض اتصال VPN، وكذلك DirectAccess الذي سنناقشه قريبًا، يكفي تحديد المربع العلوي والمضي قدمًا.
بعد اكتمال تثبيت الدور، ستجد بعض الأدوات الجديدة المتاحة داخل Server Manager. سنتحدث أكثر عن Remote Access Management Console في نهاية هذا الفصل حيث تتفاعل مجموعة الأدوات هذه مع كل من VPN وDirectAccess، ولكن عند العمل على اتصال VPN التقليدي، نريد استخدام الكونسول المسمى Routing and Remote Access.
تكوين VPN داخل RRAS
لا يحدث شيء في الواقع داخل RRAS بشكل افتراضي؛ يمكنك رؤية اسم السيرفر الخاص بك مدرجًا بسهم أحمر بجانبه، مما يشير إلى أنه غير نشط. لبدء معالج التكوين الذي سيأخذنا عبر تكوين VPN، ببساطة انقر بزر الماوس الأيمن على اسم السيرفر الخاص بك واختر Configure and Enable Routing and Remote Access. الخيار الأول الذي نصادفه مهم. هناك بعض الاستخدامات المختلفة لـ RRAS، بما في ذلك توجيه كل من حركة المرور الواردة (VPN) وحركة المرور الصادرة (proxy/NAT). يمكن أيضًا استخدام RRAS كمنصة اتصال من موقع إلى موقع! لأغراضنا اليوم، الخيار العلوي سيكون كافيًا. نحن ذاهبون لتكوين Remote access (dial-up or VPN).
الشاشة التالية واضحة تمامًا، ومضحكة نوعًا ما. هل نقوم بإعداد VPN أم اتصال dial-up؟ لم أقابل أي شخص يستخدم الإنترنت عبر dial-up منذ سنوات عديدة. هذا يشير إلى مدى طول الفترة التي مضت منذ أن قامت Microsoft بأي تحديثات لواجهة ووصلات RRAS.
أعتقد أن عبارة "if it ain’t broke, don’t fix it" تنطبق هنا، لأنه حتى ولو كانت هذه الواجهة تبدو وكأنها جاءت مباشرة من Server 2003، فإن VPN عبر RRAS لا يزال وسيلة اتصال مستقرة وآمنة إذا تم تكوينها بشكل صحيح.
في هذه المرحلة، ستدرك أنه إذا كان لديك فقط بطاقة NIC واحدة مثبتة في VPN server الخاص بك، ستتلقى رسالة حول توقع RRAS وجود اثنتين. من الممكن تكوين VPN أو DirectAccess ببطاقة NIC واحدة، ولكنه ليس الطريقة الافتراضية أو الموصى بها من Microsoft. سيرفر الوصول عن بعد المناسب من Microsoft يحتوي على بطاقتي NIC، مما يفصل حركة المرور القادمة من الإنترنت وحركة المرور التي تتحرك نحو شبكتك الداخلية. هذا هو الغرض من هذا الدور: Routing and Remote Access. بافتراض أن لديك بطاقتي NIC على هذا السيرفر، واحدة متصلة داخليًا وواحدة خارجيًا، ستطلب الشاشة التالية منك تحديد بطاقة NIC التي تواجه الإنترنت.
تخصيص عناوين IP لأجهزة عملاء VPN عن بُعد هو خطوة التكوين التالية لدينا، والخيار الافتراضي هو استخدام DHCP لهذا الغرض. نادرًا ما تريد استخدام DHCP لتوفير عناوين IP لعملاء VPN، لأن شبكتك ستعتقد عندئذ أن هذه الأجهزة البعيدة موجودة داخل شبكتك الداخلية، ويصبح توجيه الحزم إلى هؤلاء العملاء مشكلة. بدلاً من ذلك، يُوصى باختيار الخيار لتحديد نطاق عناوين IP لتخصيصها لأجهزة عملاء VPN، وأن يكون هذا النطاق من شبكة جديدة لا تستخدمها حاليًا داخل شبكتك. في حالتي، شبكتي الداخلية هي 10.10.10.0/24، وسأقوم بتحديد 172.16.1.0/24 كنطاق عناوين IP الخاص بي لـ VPN.
الآن نقوم بتعريف المصادقة لاتصالات VPN. إذا كنت تستخدم سيرفر Windows آخر يعمل بدور Network Policy Server (NPS)، يمكنك توجيه RRAS إلى NPS للحصول على تفاصيل دقيقة حول مصادقة الأجهزة البعيدة. هذا بالتأكيد أمر جيد، وسيمكنك من السماح فقط للمستخدمين الذين ينتمون إلى مجموعة معينة بالاتصال بـ VPN، أو فقط خلال أوقات معينة. يمكنك حتى استخدام NPS لتعزيز اتصالات VPN من خلال طلب MFA عند ربط NPS بمزود MFA.
الVPN عبر RRAS تم تكوينه الآن على سيرفرك!
تأمين VPN الخاص بك
انتظر دقيقة، دعونا نعود إلى حقيقة أن هذه الواجهة لإدارة RRAS تبدو وكأنها تفتقر إلى أي تحديثات على مدار العشرين عامًا الماضية. بينما هذا ليس صحيحًا من الناحية التقنية، هناك العديد من العناصر هنا التي لم يتم تحديثها مع تغير الزمن. ما أشير إليه هنا بشكل أساسي هو البروتوكولات المختلفة التي يستمع لها RRAS، والتي يمكن استخدامها لإنشاء اتصال VPN بين العميل والسيرفر. من المهم فهم ما هي هذه البروتوكولات حتى تتمكن من تقرير أي منها يمكن السماح به، حيث أنها كلها ممكَّنة على السيرفر بشكل افتراضي. سأدرجها هنا بترتيب من الأقوى والأكثر أمانًا، وصولًا إلى "لا تلمس هذا!"
ال IKEv2
أحدث وأقوى وأفضل طريقة على الإطلاق لربط أجهزة العملاء عبر VPN أو AOVPN، IKEv2 هي الطريقة الوحيدة لربط قناة AOVPN الجهازية، والتي سنتحدث عنها في القسم التالي من هذا الفصل. يتطلب IKEv2 إصدار شهادات الأجهزة لأجهزة العملاء من أجل المصادقة. هذا يعني عمومًا أنه إذا كنت تريد أن يتصل العملاء عبر IKEv2، فإن هؤلاء العملاء سيكونون منضمين إلى المجال. من المهم جدًا ملاحظة أن IKEv2 يستخدم منافذ UDP 500 و4500 لإنشاء اتصاله، وهو ما قد يكون عائقًا أحيانًا ويُحجب بواسطة الجدران النارية.
ال SSTP
يستخدم SSTP VPN تدفق SSL للاتصال. بسبب هذا، يتطلب شهادة SSL لتثبيتها على سيرفر Remote Access ولكنه لا يتطلب شهادات الأجهزة على أجهزة العملاء. يستخدم SSTP منفذ TCP 443، لذا يمكنه الاتصال حتى من داخل الشبكات الأكثر تقييدًا حيث قد يفشل IKEv2 (بسبب اعتماد IKEv2 على UDP). يجب أن أقول أن SSTP هو بروتوكول الاتصال المفضل لدي لـ VPN القائم على RRAS لـ Windows، ولكنه يعمل فقط من عملاء Windows. إذا كان لديك متطلبات لتوصيل أجهزة أخرى مثل Mac، iPhone، Android، إلخ، فستحتاج إلى الانتقال إلى L2TP.
لتمكين SSTP VPN بنجاح على سيرفر RRAS الخاص بك، ببساطة قرر على اسم DNS للإشارة إلى عنوان IP العام الخاص بـ RRAS، ثم احصل على شهادة SSL قياسية لهذا الاسم. على سبيل المثال، قد أختار vpn.contoso.com، وأحصل على شهادة SSL لنفس الاسم. قم بتثبيت تلك الشهادة SSL على سيرفر VPN الخاص بك، ثم داخل وحدة التحكم RRAS:
1. انقر بزر الماوس الأيمن على اسم السيرفر الخاص بك، وتوجه إلى الخصائص.
2. قم بزيارة علامة التبويب الأمان.
3. في الأسفل تقريبًا يوجد قسم يسمى SSL Certificate Binding. بمجرد تثبيت شهادة SSL على السيرفر، استخدم القائمة المنسدلة هنا لتحديد شهادتك. هذا يمكّن SSTP VPN للعمل بشكل صحيح عند اتصال العملاء وطلب SSTP.
ال L2TP
يمكن لـ L2TP إنشاء اتصالات VPN باستخدام الشهادات أو مفتاح مشترك مسبق (PSK). إذا كنت توصل فقط عملاء Windows إلى VPN الخاص بك، ابتعد عن هذا وركز على SSTP. إذا كان لديك متطلبات لتوصيل أجهزة غير Windows إلى VPN الخاص بك، فإن استخدام L2TP لإنشاء اتصالات VPN من خلال استخدام PSK هو النهج العام الذي يتم اتخاذه.
ال PPTP
بينما لا يزال خيار تكوين صالح داخل RRAS، ابتعد عن هذا! PPTP لم يعد وسيلة آمنة للنفق، وإذا كنت لا تزال تقوم بتشغيل اتصالات VPN بناءً على PPTP، فعليك أن تعتبر تلك التدفقات المرورية غير مشفرة ونصوص واضحة عبر الإنترنت.
بعد تثبيت RRAS والمشي عبر المعالج لتكوين VPN، لا يزال PPTP ممكنًا افتراضيًا. لحسن الحظ، من السهل تعطيله على سيرفر RRAS الخاص بك:
1. داخل RRAS، انقر بزر الماوس الأيمن على المنافذ واختر الخصائص.
2. اختر WAN Miniport (PPTP).
3. انقر على تكوين...
4. قم بإلغاء تحديد كلا المربعين، مما يعطل PPTP من الاستخدام من قبل عملاء VPN القادمين.
Always On VPN
إعطاء المستخدمين إمكانية الوصول إلى اتصال VPN تقليديًا يعني تزويدهم برابط اتصال شبكة خاص يمكنهم إطلاقه وإدخال بيانات الاعتماد للمرور بالمصادقة للاتصال بشبكة بيئة عملهم ثم التواصل مع موارد الشركة. هذا ما قمنا بتكوينه داخل RRAS. بعد إطلاق VPN، يمكن للمستخدمين فتح بريدهم الإلكتروني، العثور على المستندات، إطلاق تطبيقات خط الأعمال الخاصة بهم، أو العمل بطرق أخرى مشابهة لتواجدهم فعليًا في مكاتبهم. أيضًا، عند الاتصال عبر VPN، يمكن إدارة أجهزة الكمبيوتر المحمول الخاصة بهم، مما يمكن تدفق الاتصال الناجح لأنظمة مثل Group Policy وSystem Center Configuration Manager (SCCM). اتصالات VPN توفر اتصالًا رائعًا بالعودة إلى شبكتك، ولكن (تذكر، نحن نتحدث عن اتصالات VPN التقليدية هنا) تعمل فقط عندما يقوم المستخدم بإطلاقها يدويًا ويطلب منها العمل. في أي وقت لم يتصل المستخدم بـ VPN، فإنه يتصفح الإنترنت بدون اتصال بالعودة إلى مركز بيانات الشركة. هذا يعني أيضًا أن اتصال VPN التقليدي ليس لديه أي شكل من الاتصال على شاشة تسجيل الدخول لـ Windows لأنه، حتى يقوموا بتسجيل الدخول إلى الكمبيوتر والوصول إلى سطح مكتب Windows، لا يمكن للمستخدمين إطلاق نفق VPN هذا. هذا يعني أن أي شيء قد يحاول الحدوث على شاشة تسجيل الدخول، مثل عمليات المصادقة الحية، أو أثناء عملية تسجيل الدخول، مثل معالجة Group Policy أو سكريبتات تسجيل الدخول، لن يعمل عبر VPN التقليدي.
ال AOVPN، كما قد خمنت بالفعل بناءً على الاسم، هي ببساطة فكرة جعل اتصال VPN مستمرًا ومتصلًا تلقائيًا. بعبارة أخرى، في أي وقت يكون لدى المستخدم جهاز الكمبيوتر المحمول خارج جدران المكتب ومتصلاً بالإنترنت، يتم إنشاء نفق VPN بالعودة إلى الشبكة المؤسسية تلقائيًا، بشكل مثالي بدون تدخل من المستخدم في العملية. هذا يمكّن المستخدمين من نسيان VPN تمامًا، حيث يكون دائمًا متصلًا وجاهزًا للاستخدام. يمكنهم تسجيل الدخول إلى أجهزتهم، إطلاق تطبيقاتهم، والبدء في العمل. كما يعني أن وظائف إدارة تكنولوجيا المعلومات مثل سياسات الأمان، التحديثات، وحزم التثبيت يمكن دفعها إلى أجهزة العملاء بنسب أكبر من الوقت، لأننا لم نعد ننتظر المستخدم ليقرر متى يريد الاتصال بالعودة إلى العمل؛ يحدث ذلك تلقائيًا وبشكل دائم تقريبًا.
في الواقع، هناك ثلاث طرق مختلفة يمكن من خلالها تفعيل AOVPN على جهاز العميل، ولا تتضمن أي منها إطلاق المستخدم لاتصال VPN:
- يمكن تكوين AOVPN ليكون دائمًا متصلًا، بمعنى أنه بمجرد توفر الوصول إلى الإنترنت، سيحاول دائمًا الاتصال.
- خيار آخر هو تفعيل التطبيق، مما يعني أنه يمكنك تكوين AOVPN ليطلق نفسه فقط عندما يتم فتح تطبيقات معينة على محطة العمل.
- الخيار الثالث هو التفعيل بناءً على اسم DNS. هذا يستدعي اتصال VPN إلى العمل عندما يتم طلب أسماء DNS معينة، والذي يحدث عمومًا عندما يطلق المستخدمون تطبيقات معينة.
نظرًا لأنك لا تحتاج إلى Always On VPN ليكون متصلًا ويعمل عندما يكون جهاز الكمبيوتر المحمول الخاص بك جالسًا داخل الشبكة المؤسسية، يجب أن نناقش أيضًا حقيقة أن AOVPN ذكي بما فيه الكفاية لإيقاف نفسه عندما يدخل المستخدم من خلال الأبواب الزجاجية. أجهزة الكمبيوتر الممكّنة لـ AOVPN ستقرر تلقائيًا متى تكون داخل الشبكة، وبالتالي تعطيل مكونات VPN، ومتى تكون خارج الشبكة وتحتاج إلى إطلاق اتصال نفق VPN. تُعرف هذه العملية بالكشف عن الشبكة الموثوقة. عند تكوينها بشكل صحيح، تعرف مكونات Always On VPN ما هو لاحقة DNS الداخلية لشركتك، وتراقب إعدادات NIC وملف تعريف الجدار الناري لتحديد ما إذا تم تعيين نفس اللاحقة لتلك المكونات. عندما ترى تطابقًا، تعرف أنك داخل الشبكة ثم تعطل AOVPN.
أنواع أنفاق AOVPN
قبل أن نبدأ في تفاصيل مكونات العميل والخادم المطلوبة لجعل AOVPN يعمل، هناك موضوع أساسي يجب فهمه لاتخاذ قرارات مناسبة حول كيفية استخدام AOVPN في شركتك. هناك نوعان مختلفان تمامًا من أنفاق VPN التي يمكن استخدامها مع Always On VPN: نفق المستخدم (User tunnels) ونفق الجهاز (Device tunnels). كما ستتعلم لاحقًا في هذا الفصل، فإن القدرة على وجود نوعين مختلفين من الأنفاق هي شيء متضمن في AOVPN لجعلها أقرب إلى التكافؤ في الميزات مع DirectAccess، والذي لديه أيضًا هذه العقلية الثنائية الأنفاق. دعونا نأخذ دقيقة ونستكشف الأغراض وراء الأنفاقين.
أنفاق المستخدم (User tunnels)
الطريقة الأكثر شيوعًا لاستخدام AOVPN حتى الآن تتضمن مصادقة نفق المستخدم على مستوى المستخدم. يتم إصدار شهادات المستخدم من PKI داخلي إلى أجهزة الكمبيوتر الخاصة بك، وتستخدم هذه الشهادات كجزء من عملية المصادقة أثناء الاتصال. يحمل نفق المستخدم كل حركة مرور الجهاز والمستخدم، ولكن من المهم جدًا ملاحظة أن نفق المستخدم لا يمكن إنشاؤه بينما الكمبيوتر يجلس على شاشة تسجيل الدخول لأن المصادقة على المستخدم لم تحدث في تلك المرحلة. لذا، سيتم تشغيل نفق المستخدم فقط بمجرد تسجيل دخول المستخدم بنجاح إلى الكمبيوتر. بوجود نفق المستخدم فقط، لن يكون للكمبيوتر اتصال بالشبكة الداخلية للشركة لأغراض الإدارة حتى يسجل شخص ما الدخول إلى الكمبيوتر، وهذا يعني أيضًا أنك ستعتمد على بيانات الاعتماد المخزنة مؤقتًا للمرور عبر مطالبة تسجيل الدخول.
نفق الجهاز (Device tunnels)
تم تصميم نفق الجهاز لملء الفجوات التي يتركها تشغيل نفق المستخدم فقط. يتم مصادقة نفق الجهاز عبر شهادة الجهاز، التي تصدر أيضًا من PKI الداخلي الخاص بك. هذا يعني أن نفق الجهاز يمكن أن ينشأ نفسه حتى قبل مصادقة المستخدم. بعبارة أخرى، يعمل حتى أثناء وجوده على شاشة تسجيل الدخول في Windows. هذا يتيح لأدوات الإدارة مثل Group Policy وSCCM العمل بغض النظر عن إدخال المستخدم، كما يتيح المصادقة في الوقت الفعلي ضد وحدات تحكم المجال، مما يمكن المستخدمين من تسجيل الدخول إلى محطة عمل لم يسجلوا الدخول إليها من قبل. كما يتيح أيضًا إعادة تعيين انتهاء صلاحية كلمة المرور في الوقت الفعلي.
متطلبات نفق الجهاز (Device tunnel requirements)
يمكن لنفق المستخدم العمل مع أي جهاز يعمل بنظام Windows 10، ولكن هناك بعض المتطلبات الصارمة لاستخدام نفق الجهاز. لكي تقوم بنشر نفق الجهاز، تحتاج إلى تلبية المتطلبات التالية:
- يجب أن يكون العميل منضمًا إلى المجال.
- يجب إصدار شهادة الجهاز للعميل.
- يجب أن يكون العميل يعمل بنظام Windows 10 1709 أو أحدث.
- يجب أن يكون العميل يعمل بنظام Windows 10 Enterprise أو Education.
- يمكن أن يكون نفق الجهاز فقط IKEv2. هذا مهم لفهمه لأنه، كما تعلم بالفعل، يستخدم IKEv2 بروتوكول UDP لإنشاء اتصاله. هذا يعني أن أجهزة الكمبيوتر التي تقع خلف جدران الحماية التي تقيد المنافذ قد تكون غير قادرة على إنشاء اتصال نفق الجهاز.
متطلبات عميل AOVPN
من المهم فهم أن جزء "Always On" من Always On VPN هو في الحقيقة وظيفة من جانب العميل. يمكنك استخدام AOVPN على جهاز كمبيوتر عميل للاتصال بأنواع عديدة من البنية التحتية لشبكة VPN في الخلفية. سنتحدث عن ذلك قريبًا، في قسم مكونات خادم AOVPN.
بينما كان إنشاء اتصالات VPN يدوية منتظمة ممكنًا على أنظمة تشغيل عميل Windows لأكثر من 20 عامًا، فإن Always On VPN جديد تمامًا. ستحتاج القوى العاملة لديك إلى تشغيل Windows 10 لجعل هذا يحدث. تحديدًا، سيحتاجون إلى تشغيل على الأقل Windows 10 الإصدار 1607. المتطلبات التالية هي الإصدارات المدعومة:
- Windows 10 1607+
- Windows 10 1709+
- Windows 10 1803+
انتظر لحظة - هذا لا يبدو منطقيًا. لماذا ندرج هذه العناصر الثلاثة بشكل منفصل إذا كانت تشمل بعضها البعض؟ لأنه، بينما تم تقديم Always On VPN رسميًا في Windows 10 1607، فقد تم تحسينه على مر السنين. دعونا ندرجها مرة أخرى، مع ملخص موجز لما تغير على مر السنين:
-لل Windows 10 1607: القدرة الأصلية على تشغيل اتصال VPN تلقائيًا، مما يمكن Always On VPN.
-لل Windows 10 1709: تضمنت التحديثات والتغييرات إضافة أنفاق الجهاز. إذا كنت تنوي تشغيل نفق الجهاز لأغراض إدارة الكمبيوتر (ومعظم المؤسسات ستفعل ذلك)، فعليك اعتبار 1709 كحد أدنى لمتطلبات نظام التشغيل الخاص بك.
-لل Windows 10 1803: تتضمن بعض الإصلاحات الرئيسية التي تم اكتشافها في 1709. في الواقع، هذا يعني أنني لم أر أحدًا ينفذ Always On VPN ما لم يكن يعمل على 1803. لحسن الحظ، تحسنت منصة تحديث Windows 10 كثيرًا، مما يعني أن العديد من الشركات تقوم الآن بتطبيق إصدارات أحدث من Windows 10 بشكل مستمر، و1803 الآن تقريبًا في طي النسيان، حيث تم استبداله منذ فترة طويلة بإصدارات أحدث.
بغض النظر عما إذا كنت تستخدم 1607 أو 1709 أو 1803 أو 1809 أو أي إصدار أحدث وأعظم، فإن SKU المحددة ضمن تلك المنصات لا تهم. حسنًا، بالكاد تهم. يعمل Always On VPN مع Windows 10 Home وPro وEnterprise وجميع النكهات الأخرى. أي أن نفق المستخدم يعمل مع كل تلك الإصدارات.
من المهم بما فيه الكفاية الإشارة إلى مرة أخرى: إذا كنت ترغب في استخدام نفق الجهاز مع Always On VPN، فإن استخدام Windows 10 Enterprise أو Education المنضم إلى المجال هو مطلب ثابت.
الانضمام إلى المجال (Domain-joined)
كما سبق وذكرنا، عند اهتمامك باستخدام نفق الجهاز في AOVPN، يجب أن تكون أجهزة الكمبيوتر العميلة منضمة إلى المجال. ومع ذلك، إذا كنت موافقًا على تشغيل نفق المستخدم فقط للوصول إلى AOVPN، فلا توجد متطلبات للانضمام إلى المجال. لا يزال العملاء بحاجة إلى تشغيل Windows 10 1607 أو أحدث، ولكن يمكن أن يكونوا أي SKU ويمكن أن يكونوا حتى أجهزة منزلية منضمة إلى مجموعات عمل بسيطة؛ لا يلزم المجال.
يتم التأكيد على هذا بشكل خاص في وثائق Microsoft في العديد من الأماكن لأنه يمكن Always On VPN أن يتم استخدامه (بعض الشيء) من قبل جمهور الأجهزة الشخصية (BYOD). بينما هذا مثير للاهتمام، لا أرى أنه سيكون شائعًا أن تسمح الشركات لأجهزة الكمبيوتر الشخصية للموظفين بالاتصال بشبكة VPN الخاصة بها. معظم المنظمات تحاول تلبية احتياجات جمهور BYOD بطريقة صغيرة من خلال توفير الوصول إلى بعض الموارد عبر السحابة، مثل Office 365 للبريد الإلكتروني والمستندات. لكن ربط تلك الأجهزة الشخصية بشبكتك بنفق VPN كامل الطبقة 3؟ لا أعتقد ذلك. هذا هو كابوس مسؤولي الأمن.
نشر الإعدادات (Rolling out the settings)
لنقل أن لديك كل الأجزاء والقطع الجانبية للخادم جاهزة للاتصال بشبكة VPN، وفي الواقع، لقد أثبتت بنجاح أنه يمكنك إنشاء اتصالات VPN تقليدية مرتجلة إلى بنيتك التحتية دون مشاكل. رائع! يبدو أنك جاهز من الجانب الهيكلي. الآن، ما هو الضروري لجعل العملاء يبدأون في إنشاء اتصالات Always On؟
هذا حاليًا مطلب صارم لبعض الشركات. إعداد إعدادات سياسة Always On VPN نفسها ليس صعبًا للغاية؛ تحتاج فقط إلى أن تكون على دراية بالخيارات المختلفة المتاحة، وتقرر أي منها مهم لنشره، وتضع ملف الإعدادات/البرنامج النصي معًا. بينما ليس لدينا مساحة هنا لتغطية جميع تلك الخيارات بالتفصيل، فإن الطريقة لإنشاء تلك الإعدادات عادةً هي بناء اتصال VPN يدوي، تعديله إلى إعدادات الأمان والمصادقة التي تريدها لقوة عملك، ثم تشغيل أداة تصدر تلك التكوينات إلى بعض ملفات الإعدادات. تأتي إعدادات ملف تعريف VPN هذه بصيغة XML وPS1 (نص برمجي PowerShell)، وقد تحتاج إلى واحد أو كلا هذين الملفين لنشر الإعدادات إلى قوة عملك. النقطة التالية هي نقطة انطلاق رائعة للعمل مع هذه التكوينات: [رابط إلى وثائق Microsoft](https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/always-on-vpn/deploy/vpn-deploy-client-vpn-connections).
بمجرد إنشاء ملفات التكوين الخاصة بك، فإنك تواجه مهمة دفع هذا التكوين إلى العملاء. تحتاج بشكل مثالي إلى حل لإدارة الأجهزة المحمولة (MDM) من نوع ما لنشر الإعدادات إلى قوة العمل الخاصة بك. بينما يمكن اعتبار العديد من التقنيات في السوق كحلول MDM، فإن الاثنين اللذين تركز عليهما Microsoft هما SCCM وMicrosoft Intune.
إذا كان لديك SCCM في الموقع، رائع! يمكنك بسهولة تكوين ونشر إعدادات التكوين القائمة على PowerShell إلى أجهزة الكمبيوتر العميلة وتمكينها من Always On VPN.
ربما لا تمتلك SCCM، ولكنك مركز على السحابة ولديك جميع أجهزة الكمبيوتر متصلة بـ Intune. رائع! يمكنك استخدام Intune لنشر إعدادات Always On VPN عبر تكوين XML. أحد فوائد استخدام Intune هو أنه يمكنه إدارة أجهزة الكمبيوتر غير المنضمة إلى النطاق (non-domain-joined)، لذا يمكنك نظريًا تضمين أجهزة الكمبيوتر المنزلية والشخصية للمستخدمين في البنية التحتية المدارة عبر Intune وتكوينها للاتصال.
ال SCCM و Intune رائعان، ولكن ليس الجميع يستخدمهما. هناك خيار ثالث لنشر إعدادات Always On VPN عبر PowerShell scripting. على الرغم من أن هذا هو الخطة باء من Microsoft (يفضلون حقًا نشر Always On VPN عبر حل MDM)، إلا أن PowerShell سيكون الواقع للعديد من عملاء SMB الذين يرغبون في استخدام Always On VPN. العيب الأكبر في استخدام PowerShell لوضع إعدادات Always On VPN هو أن PowerShell يحتاج إلى تشغيل في وضع المسؤول، مما يعني أنه من الصعب أتمتة ذلك لأن المستخدم المسجل الدخول (الذي تحتاج لتكوين اتصال VPN له) يجب أن يكون مسؤولًا محليًا لكي يعمل السكريبت بشكل صحيح.
أتمنى وأنتظر بفارغ الصبر اليوم الذي يعلنون فيه عن قالب Group Policy لنشر إعدادات Always On VPN، ولكن حتى الآن، لا توجد معلومات عما إذا كان ذلك سيكون خيارًا في المستقبل. الجميع لديهم Group Policy؛ ليس الجميع لديهم MDM. ستقرأ بعد قليل أن نشر إعدادات اتصال Microsoft DirectAccess (وهو بديل لـ Always On VPN) يتم عبر Group Policy، مما يسهل فهمه وإدارته بشكل كبير. من وجهة نظري، في وقت كتابة هذا النص، DirectAccess يمتلك ميزة كبيرة على Always On VPN في كيفية التعامل مع نشر الإعدادات على الجانب العميل. ولكن، تأكد من مراجعة Microsoft Docs عبر الإنترنت للحصول على أحدث المعلومات حول هذا الموضوع، حيث يتم تحسين Always On VPN باستمرار ومن المحتمل أن تكون هناك بعض التغييرات القادمة في هذا المجال من التكنولوجيا.
مكونات الخادم لـ Always On VPN
الآن وقد فهمنا ما هو مطلوب على جانب العميل لجعل Always On VPN يعمل، ما هي الأجزاء والقطع اللازمة على جانب الخادم/البنية التحتية للسماح بحدوث هذه الاتصالات؟
من المثير للاهتمام أن المكون Always On في Always On VPN ليس له علاقة بالبنية التحتية للخادم؛ الجزء Always On يتم التعامل معه بالكامل على جانب العميل. لذلك، كل ما نحتاج إلى فعله على جانب الخادم هو التأكد من أننا نستطيع استقبال اتصالات VPN الواردة. إذا كان لديك حاليًا قوة عمل تقوم بعمل اتصالات VPN ناجحة، فهناك احتمال كبير بأن لديك بالفعل البنية التحتية للخادم اللازمة لجلب Always On VPN إلى بيئتك.
خادم الوصول عن بعد (Remote Access server)
من الواضح أنك بحاجة إلى خادم VPN لاستضافة اتصالات VPN، أليس كذلك؟ حسنًا، ليس بوضوح. كما ناقشنا بالفعل، الدور الخاص بخادم Windows الذي يستضيف اتصالات VPN و Always On VPN و DirectAccess يسمى دور Remote Access، ولكن يمكنك في الواقع جعل Always On VPN يعمل بدون Windows Server كخادم الوصول عن بعد. بما أن الجزء Always On هو وظيفة على جانب العميل، فإن هذا يمكن من استضافة البنية التحتية لخادم VPN بواسطة بائعين من أطراف ثالثة. على الرغم من أن ذلك دقيق تقنيًا، إلا أنه ليس ما تتوقعه Microsoft فعليًا، ولا ما أجده في الميدان. في الواقع، نحن المهتمون باستخدام Microsoft Always On VPN سنستخدم Microsoft Windows Server لاستضافة دور Remote Access، الذي سيكون النظام الوارد الذي تتصل به عملاؤنا البعيدون.
يفترض الكثير من الناس تلقائيًا أن Always On VPN مرتبط بـ Windows Server 2019 أو 2022 لأنه تكنولوجيا جديدة نسبيًا، ولكن هذا ليس الحال على الإطلاق. يمكنك استضافة البنية التحتية لـ VPN (دور Remote Access) على Server 2022، Server 2019، Server 2016، أو حتى Server 2012 R2. يعمل بنفس الطريقة على الجانب الخلفي، مما يعطي العملاء مكانًا للوصول باتصالات VPN الخاصة بهم.
إعداد خادم Remote Access للتعامل مع اتصالات Always On VPN هو نفس العملية التي اتبعناها في القسم الأخير من هذا الفصل، تكوين RRAS VPN للاتصالات العميلة اليدوية. نفس بروتوكولات VPN هذه هي التي ستستخدمها عملاؤك الذين يعتمدون على Always On VPN.
البروتوكولين الأكثر استخدامًا بواسطة Always On VPN هما IKEv2 و SSTP. IKEv2 مطلوب لنفق الجهاز الناجح، ولكن إذا لم تكن بحاجة إلى ذلك وكنت تركز على الأنفاق الأكثر مرونة للمستخدمين لـ Always On VPN، فيمكنك الاعتماد على تشغيل SSTP كطريقة نفق احتياطية، والتي تتصل بنجاح من تقريبًا أي اتصال بالإنترنت.
سلطة إصدار الشهادات (CA)
شهادات الجهاز، شهادات المستخدم، شهادات SSL... يا للهول! من الواضح أنك تحتاج إلى أن تكون مألوفًا بالعمل مع نشر الشهادات لاستخدام Always On VPN. هذا أصبح أكثر شيوعًا مع التكنولوجيات الأحدث والأكثر أمانًا من أي نوع. المتطلب الرئيسي هنا هو أنه يجب أن يكون لديك PKI داخل بيئتك على الأقل خادم Windows CA واحد لإصدار الشهادات اللازمة. فيما يلي قائمة بالأماكن التي يمكن أن تُستخدم فيها الشهادات بواسطة بنية Always On VPN:
- **شهادات المستخدم**: هذه هي الشهادات الصادرة للمستخدمين عبر VPN من CA الداخلي، تُستخدم لمصادقة نفق المستخدم.
- **شهادات الجهاز**: هذه هي الشهادات الصادرة لمحطات العمل (معظمها أجهزة الكمبيوتر المحمولة) من CA الداخلي، تُستخدم لمصادقة نفق الجهاز.
- **شهادات SSL**: تُثبت على خادم الوصول عن بعد للتحقق من حركة المرور الواردة لاتصالات SSTP VPN.
- **شهادات الجهاز لـ VPN و NPS**: خادم الوصول عن بعد الخاص بك، بالإضافة إلى خوادم NPS الخاصة بك، تتطلب شهادات الجهاز الصادرة من CA الداخلي.
خادم سياسة الشبكة Network Policy Server (NPS)
ال NPS هو في الأساس طريقة المصادقة لاتصالات VPN. عندما يرد طلب اتصال VPN، يقوم خادم الوصول عن بعد بتسليم طلب المصادقة إلى خادم NPS للتحقق من هوية المستخدم وأيضًا للتحقق من أن المستخدم لديه الأذونات اللازمة لتسجيل الدخول عبر VPN.
الأكثر شيوعًا عند العمل مع اتصالات VPN من Microsoft، نقوم بتكوين NPS بحيث يسمح فقط للمستخدمين الذين هم جزء من مجموعة Active Directory Security محددة. على سبيل المثال، إذا قمت بإنشاء مجموعة تسمى VPN Users ثم وجهت NPS إلى تلك المجموعة، سيسمح فقط للمستخدمين الذين وضعتهم داخل تلك المجموعة بإنشاء اتصالات VPN ناجحة.
ال NPS هو دور آخر لخادم Windows يمكن استضافته على نظامه الخاص أو نشره عبر خوادم متعددة للموثوقية. كما هو الحال مع دور Remote Access، لا يوجد متطلب Server 2022 لـ NPS. يمكنك نشره بسهولة على الإصدارات السابقة من Windows Server بنفس القدر.
تذكر أنه لا يجب تثبيت NPS على نفس الخادم الذي تقوم بتشغيل Remote Access عليه. تحتاج إلى إعداد خادم ثاني لأغراض NPS.
ال DirectAccess
طوال مناقشتنا حول Always On VPN، ذكرت Microsoft DirectAccess عدة مرات. DA هو شكل آخر من الاتصال التلقائي الشبيه بـ VPN، ولكنه يتبع نهجًا مختلفًا مقارنة بـ Always On VPN. بينما يستخدم Always On VPN بروتوكولات VPN المعروفة والمتوقعة ويفعل بعض السحر الذكي لإطلاق هذه الأنفاق التقليدية، فإن أنفاق DirectAccess هي بشكل كبير مملوكة. الأنفاق محمية بواسطة IPsec وهي في الأساس غير قابلة للاختراق ولا يمكن تقليدها. أجد أن فرق الأمان تحب الحماية والتعقيد المحيط بأنفاق DirectAccess لأنها منصة اتصال لا يعرف المهاجمون كيفية التلاعب بها أو تقليدها.
من خلال تجربتي، في هذه المرحلة من اللعبة، Microsoft DirectAccess هو السبب الأكثر شيوعًا لنشر دور Remote Access على مثيل Windows Server. كما ذكرت، فإن أسهل طريقة للتفكير في DA هي التفكير فيه كـ VPN تلقائي. مشابهًا لـ VPN، غرضه هو توصيل أجهزة الكمبيوتر الخاصة بالمستخدمين بشبكة الشركة عندما يكونون خارج المكتب. ولكن على عكس VPN، الطريقة التي يستخدمها الموظفون لجعل هذا الاتصال ممكنًا مختلفة. DirectAccess ليس برنامجًا؛ هو سلسلة من المكونات المدمجة بالفعل في نظام التشغيل Windows، تعمل جنبًا إلى جنب لتوفير الوصول السلس تمامًا للمستخدم. ماذا أعني بالسلس؟ بنفس الطريقة التي يتصل بها Always On VPN دون تفاعل المستخدم، لا يوجد شيء يحتاج المستخدم لفعله لجعل DirectAccess يتصل. يقوم بذلك بنفسه تمامًا. بمجرد أن يحصل الكمبيوتر المحمول المتنقل على اتصال بالإنترنت، سواء كان ذلك اتصال Wi-Fi منزلي، أو الإنترنت العام في مقهى، أو اتصال نقطة ساخنة عبر الهاتف الخلوي، تتشكل أنفاق DirectAccess تلقائيًا باستخدام أي اتصال إنترنت متاح، دون أي مدخلات من المستخدم.
سواء كنت تستخدم Always On VPN أو DirectAccess، عندما يتصل الكمبيوتر تلقائيًا، فإنه يوفر لك الوقت والمال. يتم توفير الوقت لأن المستخدم لم يعد بحاجة لإطلاق اتصال VPN. يتم توفير المال لأن الوقت يساوي المال، ولكن أيضًا لأن وجود اتصال دائم يعني أن التصحيحات وسياسات الأمان وإدارة تلك أجهزة الكمبيوتر البعيدة تحدث دائمًا، حتى عندما يكون المستخدم يعمل عن
بعد. لم تعد بحاجة للانتظار حتى يعود المستخدمون إلى المكتب أو حتى يختاروا إطلاق اتصال VPN يدويًا لدفع الإعدادات والسياسات الجديدة إلى أجهزة الكمبيوتر الخاصة بهم؛ كل ذلك يحدث أينما كانوا، طالما كان لديهم اتصال بالإنترنت. بوضوح، مع ظهور تقنيات وصول عن بعد مختلفة تركز على الاتصال التلقائي للمستخدمين عن بعد، تقوم Microsoft بتمهيد الطريق لقوة عاملة أكثر إنتاجية. لم يكن مصطلح "سهل الاستخدام" و"VPN" قد اجتمعا من قبل، ولكن في أحدث إصدارات أنظمة التشغيل Windows، هذا هو الهدف بالضبط.
في الواقع، DirectAccess موجود منذ إصدار Windows Server 2008 R2، ومع ذلك ألتقي بانتظام بأشخاص لم يسمعوا به من قبل. في الأيام الأولى، كان من الصعب جدًا نشره وجاء مع الكثير من المتطلبات الصعبة، ولكن تغير الكثير على مر السنوات الماضية وDirectAccess الآن أسهل من أي وقت مضى في النشر، وأكثر فائدة من أي وقت مضى ليكون قيد التشغيل في بيئتك.
النهاية
نكون هنا انتهينا من الجزء 1 من الفصل 8 تماما من شهادة MCSA المقدمة من Microsoft الأن نغوص في الأعماق
و لا بد وانت تقرا ان تكون مركز جيدا لكل معلومة ومعك ورقة وقلم , لانك بالتاكيد ستحتاجها
واذا واجهتك اي مشكلة في الفهم او ما شابه , يمكنك على الفور الذهاب الى المجتمع الخاص بنا في Telegram للمناقشة والتواصل معنا من هنا
او اذا واجهتك مشكلة في الموقع او تريد اجابة سريعة يمكنك الذهاب الى اخر صفحة في الموقع ستجد صفحة اتصل بنا موجودة يمكنك ارسالة لنا مشكلتك , وسيتم الرد عليها بسرعة جدا ان شاء الله
ويمكنك الأنضمام الى المجتمع Hidden Lock بالكامل مع جميع قنواته للأستفادة في اخر الأخبار في عالم التقنية وايضا الكتب بالمجان والكورسات والمقالات من خلال الرابط التالي لمجموعة القنوات من هنا
يمكنك ايضا متابعتنا في منصات X او Twitter سابقا , لمشاهدة الاخبار والمقالات السريعة والمهمة من
وفقط كان معكم Sparrow اتمنى ان تدعوا لي وتتذكروني في الخير دوما
