إعداد شهادات SSL ونطاقات داخل الشبكة المحلية

هل سئمت من الدخول إلى الخدمات الموجودة على شبكتك المنزلية أو شبكة عملك الصغيرة، ثم ظهور تحذير أمني من المتصفح مثل هذا؟

يحدث هذا عادةً لأن خادم الويب يستخدم شهادة SSL موقعة ذاتيًا وغير موثوقة، أو لأنه لا يستخدم شهادة SSL أصلًا.

إذا كانت خدمتك تعمل بالفعل عبر HTTPS، فهناك عدة طرق لحل هذه المشكلة.

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

فكل جهاز جديد يحتاج إلى تثبيت الشهادة، وكلما تغيرت الشهادة قد تحتاج إلى تحديثها على جميع الأجهزة مرة أخرى.

لكن ماذا لو كان بإمكانك استخدام شهادة SSL موثوقة ومعترف بها من المتصفحات، وفي الوقت نفسه إعطاء خدماتك المحلية أسماء نطاقات سهلة بدلًا من كتابة عناوين مثل:

192.168.1.100:8080

في كل مرة؟

لحسن الحظ، هذا ممكن.

في هذا الدليل سنقوم بإعداد نظام بسيط يسمح لك باستخدام شهادات SSL حقيقية وأسماء نطاقات سهلة للخدمات التي تعمل داخل شبكتك المحلية فقط.

سنستخدم في هذا المثال:

• NGINX Proxy Manager — واجهة رسومية لإدارة NGINX كـ Reverse Proxy.

• Pi-hole — خادم DNS محلي.

• Dynamic DNS (DDNS) — خدمة توفر اسم نطاق مرتبطًا بعنوان IP الخاص بك.

قد تختلف خطوات الإعداد قليلًا حسب مزود DNS والـ Reverse Proxy الذي تستخدمه، لكن الفكرة الأساسية تبقى نفسها.

لماذا نستخدم Dynamic DNS؟ ولماذا لا نشتري نطاقًا عاديًا؟

هذا سؤال منطقي جدًا.

يمكنك بالتأكيد شراء وتسجيل نطاق خاص بك، ولا توجد مشكلة في ذلك. لكن بالنسبة إلى Home Lab أو شبكة منزلية أو مشروع صغير، يمكن أن يكون Dynamic DNS خيارًا أرخص وأسهل.

يسمح لك Dynamic DNS بربط اسم نطاق أو أكثر بعنوان IP الخاص بمنزلك أو شركتك الصغيرة، مع إبقاء العنوان محدثًا تلقائيًا عندما يتغير.

بدلًا من إدارة سجلات DNS مثل:

• A Records

• CNAME Records

• Aliases

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

بعد ذلك يمكنك إعطاء كل خدمة موجودة على شبكتك اسم نطاق خاصًا بها.

مثلًا:

organizer.mywebsite.example
nextcloud.mywebsite.example
grafana.mywebsite.example

يمكن لجميع هذه النطاقات أن تشير إلى نفس عنوان IP العام، بينما يتولى الـ Reverse Proxy، مثل NGINX أو Caddy أو Traefik، تحديد الخدمة الداخلية التي يجب أن تستقبل الطلب.

مثلًا:

organizer.mywebsite.example  →  192.168.1.100:8080
grafana.mywebsite.example    →  192.168.1.100:3000
nextcloud.mywebsite.example →  192.168.1.100:8081

ما هي عيوب Dynamic DNS؟

هناك بعض القيود.

فعادةً ستكون مقيدًا بأسماء النطاقات التي يوفرها مزود DDNS، مما يعني أنك قد لا تحصل على نطاق بسيط مثل:

mywebsite.com

بل ستحصل غالبًا على نطاق فرعي ضمن أحد النطاقات التي يوفرها المزود، مثل:

mywebsite.example.net

بالنسبة إلى موقع عام على الإنترنت، قد لا يكون هذا الخيار مثاليًا.

لكن بالنسبة إلى Home Lab أو الخدمات التي تعمل داخل الشبكة المحلية فقط، فإن هذا القيد غالبًا ليس مهمًا.

لذلك دعونا نكمل عملية الإعداد.

تسجيل نطاق Wildcard

يمكنك تسجيل اسم نطاق مختلف لكل خدمة موجودة على شبكتك، لكن هناك طريقة أسهل: استخدام Wildcard Domain.

يسمح لك الـ Wildcard بإنشاء عدة نطاقات فرعية تحت نفس النطاق الأساسي.

مثلًا:

*.mywebsite.example

وهذا يسمح لك بإنشاء أسماء مثل:

organizer.mywebsite.example
grafana.mywebsite.example
nextcloud.mywebsite.example

دون الحاجة إلى تسجيل نطاق منفصل لكل خدمة.

في هذا المثال سأستخدم DynDNS. قد تختلف الخطوات قليلًا إذا كنت تستخدم مزود DDNS آخر.

انتقل إلى مزود Dynamic DNS الخاص بك وقم بتسجيل النطاق كالمعتاد، مع التأكد من تفعيل دعم Wildcard.

بعد الانتهاء من ذلك، افتح الـ Reverse Proxy الخاص بك. في هذا المثال سنستخدم NGINX Proxy Manager.

قم بإنشاء Proxy Host جديد وأدخل اسم النطاق الخاص بك.

هل لاحظت الجزء organizer في بداية النطاق؟

هنا تظهر أهمية إعداد Wildcard.

يمكنك استبدال organizer بأي اسم فريد للخدمة التي تريد تشغيلها.

مثلًا:

organizer.mywebsite.example
grafana.mywebsite.example
nextcloud.mywebsite.example

ويمكن لكل اسم منها أن يشير إلى خدمة مختلفة داخل الشبكة.

مثلًا:

organizer.mywebsite.example → 192.168.1.100:8080
grafana.mywebsite.example   → 192.168.1.100:3000

في هذه المرحلة، قم بتوجيه النطاق إلى عنوان IP المحلي والمنفذ الصحيحين.

قد تلاحظ أيضًا وجود خيار يشير إلى أن الخدمة متاحة للعامة. لا تقلق، سنقوم بتقييد الوصول إلى الشبكة المحلية بعد قليل.

الحصول على شهادة SSL موثوقة

بعد إعداد النطاق في NGINX Proxy Manager، نحتاج إلى الحصول على شهادة SSL.

انتقل إلى قسم SSL واختر Request a New Certificate.

ستحتاج عادةً إلى إدخال عنوان بريد إلكتروني لاستخدامه مع Let's Encrypt.

النقطة المهمة هنا هي طريقة التحقق من ملكية النطاق.

بحسب مزود DDNS وطريقة التحقق التي يدعمها، قد لا تتمكن من استخدام DNS Challenge. وفي هذه الحالة، ستحتاج إلى استخدام طريقة تحقق أخرى يدعمها إعدادك.

إذا لم تتمكن من الحصول على شهادة Wildcard من خلال مزودك، فقد تحتاج إلى طلب شهادة منفصلة لكل اسم نطاق، مثل:

organizer.mywebsite.example
grafana.mywebsite.example
nextcloud.mywebsite.example

بعد إصدار الشهادة بنجاح، سيتعرف المتصفح عليها كشهادة موثوقة بدلًا من عرض تحذير الشهادة الموقعة ذاتيًا.

تقييد الوصول إلى الشبكة المحلية

هناك خطوة مهمة أخرى.

إذا كانت هذه الخدمات مصممة للعمل داخل الشبكة المحلية فقط، فيجب التأكد من أن الطلبات القادمة من الإنترنت العام يتم حظرها.

يمكن تحقيق ذلك من خلال إنشاء Access Control List (ACL) تسمح بالطلبات القادمة من الشبكة المحلية وتمنع الطلبات القادمة من خارجها.

على سبيل المثال، إذا كانت شبكتك المحلية تستخدم:

192.168.1.0/24

يمكنك إعداد الـ Reverse Proxy للسماح للأجهزة الموجودة ضمن هذه الشبكة ومنع بقية الأجهزة.

تختلف طريقة الإعداد حسب الـ Reverse Proxy المستخدم.

في NGINX Proxy Manager، يمكنك إعداد ذلك من خلال الواجهة الرسومية.

بعد إنشاء Access List، قم بربطها بالـ Proxy Host المناسب.

بهذه الطريقة تحصل على طبقة حماية إضافية وتضمن أن الخدمة لا يمكن الوصول إليها إلا من داخل شبكتك المحلية.

ربط النطاق بسجلات DNS المحلية

تبقى خطوة أخيرة: Local DNS.

تذكر أن هذه الخدمات مصممة للعمل داخل الشبكة المحلية فقط.

لذلك لا يوجد سبب لجعل جهازك يحل:

organizer.mywebsite.example

إلى عنوان IP العام، ثم يرسل الاتصال إلى الإنترنت قبل أن يعود مرة أخرى إلى شبكتك المحلية.

بدلًا من ذلك، يمكننا إعداد خادم DNS المحلي ليقوم بتوجيه اسم النطاق مباشرةً إلى عنوان IP الداخلي للـ Reverse Proxy.

في هذا المثال سنستخدم Pi-hole.

وبحسب الشبكة التي تستخدمها، يمكنك أيضًا إعداد Local DNS باستخدام:

• الراوتر المنزلي.

• OPNsense.

• pfSense.

• خادم DNS مخصص.

• أي خدمة DNS محلية أخرى تعمل على الخادم الخاص بك.

افتح قسم Local DNS في Pi-hole وأنشئ سجل DNS للنطاق الخاص بك.

مثلًا:

organizer.mywebsite.example → 192.168.1.100

يجب أن يكون عنوان IP هو عنوان الـ Reverse Proxy.

وهذا مهم لأننا نريد أن تصل جميع الطلبات الخاصة بهذا النطاق إلى الـ Reverse Proxy أولًا، ثم يقوم NGINX Proxy Manager بتحديد الخدمة الداخلية التي يجب أن تتعامل مع الطلب.

وهكذا انتهينا.

بدلًا من الوصول إلى الخدمة باستخدام:

http://192.168.1.100:8080

يمكنك الآن استخدام:

https://organizer.mywebsite.example

سيبقى الاتصال داخل شبكتك المحلية، وسيقوم الـ Reverse Proxy بتوجيه الطلب إلى الخدمة الصحيحة، بينما سيرى المتصفح شهادة SSL موثوقة بدلًا من تحذير الأمان المعتاد.

وبذلك تحصل على:

أسماء نطاقات سهلة + HTTPS موثوق + Reverse Proxy + وصول محصور داخل الشبكة المحلية.

والأهم من ذلك أنك لن تحتاج بعد الآن إلى حفظ مجموعة من عناوين IP وأرقام المنافذ في كل مرة تريد فيها الوصول إلى إحدى خدماتك المستضافة داخل الشبكة.