Wi-Fi للمؤسسات بحساب لكل موظف مع FreeRADIUS

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

هذه المشكلة لها حل معروف في المؤسسات منذ سنوات: بدل كلمة مرور واحدة للجميع، يدخل كل موظف بحسابه الخاص، وتسأل نقطة الوصول سيرفراً مركزياً عن كل محاولة دخول، فإذا غادر موظف عطلت حسابه وحده. وهذا ما يسمى WPA2-Enterprise أو WPA3-Enterprise، ويقوم على معيار 802.1X وسيرفر RADIUS. وفي دليل تقسيم الشبكة شرحنا الـ VLAN وفكرة فصل الأجهزة، وفي هذا المقال سوف نبني سيرفر RADIUS حقيقياً بأداة FreeRADIUS، ونختبر الدخول الكامل بأداة eapol_test التي تحاكي الجهاز ونقطة الوصول معاً، فنرى كل رسالة تمر بينها، ونرى كيف يضع السيرفر كل موظف في الـ VLAN الخاصة بدوره، وكيف تعطلت الشبكة كلها في المختبر بسبب شهادة منتهية.

دليلتقسيم الشبكة Network Segmentation بال VLAN وال VPCلماذا تصل كاميرا مخترقة إلى قاعدة بياناتك، وكيف تمنع ذلك بتقسيم الشبكة إلى مناطق لا يمر بينها إلا ما تسمح به.دليلبوابة الدخول Captive Portal: شبكة الضيوف برمز تحققكيف تعمل بوابة الدخول في شبكة Wi-Fi الضيوف، وكيف تختار طريقة التحقق والأدوات المناسبة لمقهى أو فندق أو شركة.دليلMikroTik في الواقع: سيناريوهات عملية للبيت والمكتبكيف تبني على RouterOS ما تحتاجه فعلاً في البيت والمكتب، من شبكة ضيوف معزولة إلى الوصول الآمن من الخارج عبر WireGuard.

وسوف نناقش في هذا المقال ما يلي:

• الفرق بين WPA2/3-Personal وWPA2/3-Enterprise، ولماذا لا تكفي كلمة المرور المشتركة لأي مؤسسة.
• كيف يعمل 802.1X: الأدوار الثلاثة، وبروتوكول EAP، ولماذا لا تعرف نقطة الوصول كلمات المرور.
• طريقتا الدخول الأشهر: PEAP بكلمة مرور داخل نفق، وEAP-TLS بشهادة على الجهاز.
• بناء FreeRADIUS في Docker: العملاء Clients والمستخدمون والشهادات.
• اختبار الدخول بـ eapol_test دون أي جهاز Wi-Fi، وقراءة المخرج سطراً سطراً.
• أربع عقبات حقيقية واجهناها في المختبر وكيف حللناها، منها شهادة منتهية أوقفت الدخول للجميع.
• الـ VLAN الديناميكية: شبكة Wi-Fi واحدة، وكل موظف في شبكته.
• تجربة «ماذا لو» نقطة وصول مزيفة، ولماذا يحميك إعداد واحد على الجهاز.
• الموارد والبديل التجاري، والجانب السعودي في ضوابط الهيئة الوطنية للأمن السيبراني، وقائمة تحقق.

كلمة مرور واحدة أم حساب لكل موظف؟

في وضع WPA2-Personal أو WPA3-Personal، وهو الوضع الذي تجده في كل راوتر منزلي، كل من يعرف كلمة المرور يدخل، والراوتر لا يعرف من أنت، وإنما يعرف فقط أنك تعرف السر المشترك Pre-Shared Key. وهذا ممتاز للمنزل، ولكنه في المؤسسة يسبب ثلاث مشكلات لا حل لها داخل هذا الوضع نفسه، والصورة التالية تجمعها:

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

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

وقد يتساءل البعض: أليس WPA3-Personal أحسن بكثير من WPA2؟ نعم، فهو يستبدل طريقة المصافحة القديمة بطريقة SAE التي تقاوم تخمين كلمة المرور من الحركة الملتقطة، وهذا موضوع المقال القادم في أمن الشبكات اللاسلكية. ولكنه يبقى كلمة مرور مشتركة، فلا يحل مشكلة الموظف الذي غادر ولا مشكلة المساءلة. فالسؤال ليس WPA2 أم WPA3، وإنما Personal أم Enterprise، ولكل منهما WPA2 وWPA3.

كيف يعمل 802.1X من الداخل؟

معيار IEEE 802.1X هو التحكم في الدخول على منفذ الشبكة Port-Based Network Access Control، وقد صمم أصلاً لمنافذ الشبكة السلكية في الشركات، ثم صار أساس Wi-Fi للمؤسسات. وفكرته أن المنفذ، سواء كان منفذاً في سويتش أو اتصالاً لاسلكياً، يبقى مغلقاً أمام أي حركة إلا رسائل التحقق، حتى يقول السيرفر نعم. وفي هذا المعيار ثلاثة أدوار، والصورة التالية تبينها مع الرسائل التي قسناها في المختبر لدخول واحد:

• الجهاز Supplicant: لابتوب الموظف أو جواله، وفيه برنامج يعرف كيف يقدم الهوية، وهو جزء من نظام التشغيل في Windows وmacOS وAndroid وiOS، وفي Linux هو wpa_supplicant.
• نقطة الوصول Authenticator: وهي لا تعرف كلمات المرور ولا تتحقق من أي شيء، وإنما تأخذ رسائل التحقق من الجهاز على الهواء بإطار يسمى EAPOL، وتغلفها في رسائل RADIUS وترسلها إلى السيرفر على الشبكة السلكية، ثم تعيد الردود إلى الجهاز.
• سيرفر المصادقة Authentication Server: وهو سيرفر RADIUS، الذي يملك الحسابات أو يسأل عنها دليلاً مثل Active Directory، ويقرر.

والرسائل التي تمر بين هذه الأدوار تتبع بروتوكول EAP، واختصاره Extensible Authentication Protocol، الموصوف في RFC 3748. وكلمة Extensible هنا هي المفتاح، فـ EAP ليس طريقة تحقق، بل إطار يحمل طرق تحقق مختلفة، يتفق عليها الجهاز والسيرفر في بداية الحوار. ونقطة الوصول لا يهمها أي طريقة اختاروا، فهي تمرر الرسائل كما هي، وهذا ما يجعلك تغير طريقة الدخول في المؤسسة كلها بتغيير إعداد السيرفر والأجهزة، دون أن تلمس نقاط الوصول. أما RADIUS نفسه فبروتوكول أقدم موصوف في RFC 2865، ويعمل على UDP على المنفذ 1812، وبين نقطة الوصول والسيرفر سر مشترك Shared Secret يوقع الرسائل، وهو ليس كلمة مرور الموظفين، وإنما ثقة بين جهازين.

ولاحظ في الصورة عدد الرسائل: دخول واحد بطريقة PEAP احتاج في المختبر إحدى عشرة رسالة Access-Request من نقطة الوصول، وعشر رسائل Access-Challenge من السيرفر، ثم Access-Accept واحدة. والسبب أن بناء نفق TLS يحتاج تبادل الشهادة على عدة أجزاء، لأن رسالة EAP الواحدة محدودة الحجم، ثم يأتي التحقق من كلمة المرور داخل النفق. وهذا يعني أن RADIUS يجب أن يكون قريباً وسريعاً، فإذا كان كل رد يأخذ نصف ثانية عبر شبكة بعيدة، صار الدخول عشر ثوان، والأجهزة قد تستسلم قبل ذلك. وقد قسنا زمن الذهاب والعودة لكل رسالة في المختبر فكان بين 0.01 و0.05 ثانية على شبكة محلية.

طريقتا الدخول: PEAP أم EAP-TLS؟

من بين طرق EAP الكثيرة، تستخدم أغلب المؤسسات واحدة من اثنتين، والصورة التالية تقارن بينهما كما جربناهما:

الأولى PEAP، واسمها Protected EAP، وفكرتها أن السيرفر يقدم شهادته أولاً، فيبني الجهاز معه نفق TLS مشفراً مثل الذي يبنيه المتصفح مع موقع HTTPS، ثم داخل هذا النفق يقدم الجهاز اسم المستخدم وكلمة المرور بطريقة MSCHAPv2. وخارج النفق لا يظهر إلا هوية عامة مثل anonymous، فلا يرى من يلتقط الحركة حتى اسم الموظف. ونقطة قوتها أنها تعمل بالحسابات الموجودة عندك، فلا تحتاج شهادة لكل جهاز. ونقطة ضعفها الخطيرة أن كل حمايتها معلقة على أن يتحقق الجهاز من شهادة السيرفر، فإذا لم يفعل، سلم كلمة مروره لأي سيرفر يقدم أي شهادة، ومن هنا جاءت هجمات نقطة الوصول المزيفة Evil Twin التي سوف نجربها لاحقاً.

والثانية EAP-TLS، الموصوفة في RFC 5216، وفيها لا توجد كلمة مرور إطلاقاً: الطرفان يقدمان شهادتيهما، السيرفر يثبت أنه السيرفر، والجهاز يثبت أنه جهاز مسجل لدى المؤسسة. ونقطة قوتها أنه لا يوجد شيء يسرق بالتخمين أو بالتصيد، فلا كلمة مرور، وكل جهاز له هوية تلغيها وحدها. ونقطة ضعفها التشغيل: تحتاج جهة إصدار شهادات CA، وطريقة لتوزيع الشهادة على كل جهاز وتجديدها، وهذا عملياً يحتاج أداة إدارة أجهزة MDM. ولذلك تبدأ أغلب المؤسسات الصغيرة بـ PEAP، وتنتقل إلى EAP-TLS للأجهزة التي تديرها، وتبقي PEAP للبقية.

وماذا يضيف WPA3-Enterprise؟

إذا كان التحقق في Enterprise يحدث بين الجهاز وRADIUS، فما الفرق بين WPA2-Enterprise وWPA3-Enterprise؟ الجواب أن طرق التحقق نفسها لا تتغير، فـ PEAP وEAP-TLS وسيرفر FreeRADIUS الذي بنيناه تعمل مع الاثنين، والفرق في حماية الاتصال اللاسلكي حول هذا التحقق. وأهم ما في هذا الفرق إطارات الإدارة المحمية Protected Management Frames واختصارها PMF، وهي الرسائل التي تدير الاتصال نفسه مثل رسالة قطع الاتصال. ففي الشبكات القديمة كانت هذه الرسائل غير محمية، فيستطيع أي جهاز قريب أن يرسل رسالة قطع اتصال مزورة باسم نقطة الوصول، فينقطع الموظف ويعيد الاتصال، وهذه طريقة معروفة لدفع الأجهزة نحو نقطة وصول أخرى. ومع PMF تصبح هذه الرسائل موقعة، فلا يقبل الجهاز رسالة قطع اتصال لا تحمل التوقيع الصحيح. وتقول صفحة الأمان في Wi-Fi Alliance إن PMF مطلوب في كل الأجهزة الحديثة الحاصلة على الشهادة، وإن WPA3-Enterprise يتيح بروتوكولات أمان أعلى درجة للشبكات التي تحمل بيانات حساسة.

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

المختبر: FreeRADIUS وeapol_test

بنينا المختبر من حاويتين على شبكة Docker خاصة: الأولى سيرفر RADIUS من الـ Image الرسمية freeradius/freeradius-server:3.2.10-alpine، والثانية تمثل الجهاز ونقطة الوصول معاً، وفيها أداة eapol_test. وFreeRADIUS هو أشهر سيرفر RADIUS مفتوح المصدر، ورخصته GPL-2.0، وآخر إصدار في الفرع المستقر هو 3.2.10 الصادر في 3 يونيو 2026، وتوثيقه في موقع المشروع. أما eapol_test فهي أداة من مشروع wpa_supplicant تفعل شيئاً ذكياً: تتصرف كجهاز يريد الدخول وكنقطة وصول في الوقت نفسه، فترسل رسائل EAP مغلفة في RADIUS إلى السيرفر مباشرة، وتخبرك هل نجح الدخول، دون أن تحتاج أي جهاز Wi-Fi حقيقي.

نقطة الوصول عميل للسيرفر

أول ما يحتاجه السيرفر أن يعرف من يحق له أن يسأله، فنقطة الوصول بالنسبة لـ RADIUS عميل Client، ولكل عميل عنوان وسر مشترك. أضفنا في ملف clients.conf عميلاً يمثل نقاط الوصول في شبكة المختبر:

client lab-ap {
	ipaddr = 192.168.0.0/16
	secret = ap-shared-secret-2026
	shortname = lab-ap
	nas_type = other
}

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

وهذا ليس كلاماً نظرياً في مختبرنا، فقد رأينا أثر الإصلاح بأعيننا: رسالة Access-Accept التي سنعرضها بعد قليل تبدأ بالصفة 80، وهي Message-Authenticator، قبل أي صفة أخرى. وفي إعداد FreeRADIUS 3.2.10 نفسه وجدنا السطر require_message_authenticator = yes في ملف radiusd.conf افتراضياً، أي أن السيرفر يرفض الطلبات التي لا تحمل هذه الصفة. والدرس العملي في المتجر أن تحدث سيرفر RADIUS إلى إصدار يحمل الإصلاح، وأن تحدث برامج نقاط الوصول أيضاً، فإذا كانت نقطة وصول قديمة لا ترسل الصفة فسيرفضها السيرفر الحديث، وهذا أفضل من أن يقبلها وهي مكشوفة. ولا تقم بإيقاف هذا الشرط لتشغيل جهاز قديم، والسبب أنه الحماية الأساسية من هذه الثغرة، والأفضل أن تضع الجهاز القديم في شبكته المعزولة كما سنذكر في خطة الانتقال.

الموظفون ورقم الـ VLAN

في المؤسسة الحقيقية يسأل FreeRADIUS دليل المستخدمين Active Directory أو LDAP، أما في المختبر فوضعنا مستخدمين في ملف mods-config/files/authorize، مع رقم الـ VLAN لكل واحد:

ahmad   Cleartext-Password := "CoffeePass#2026"
        Tunnel-Type = VLAN,
        Tunnel-Medium-Type = IEEE-802,
        Tunnel-Private-Group-Id = "20"

sara    Cleartext-Password := "GuestPass#2026"
        Tunnel-Type = VLAN,
        Tunnel-Medium-Type = IEEE-802,
        Tunnel-Private-Group-Id = "30"

السطر الأول لكل مستخدم شرط التحقق، والأسطر الثلاثة بعده ما يضيفه السيرفر إلى رد القبول، وهي الصفات الثلاث التي يحددها RFC 3580 لإخبار نقطة الوصول بالـ VLAN: نوع النفق VLAN، والوسط IEEE-802، ثم رقم الـ VLAN نفسه. فأحمد الموظف يذهب إلى VLAN 20 شبكة الموظفين، وسارة الضيفة إلى VLAN 30 شبكة الضيوف.

وغيرنا في ملف mods-available/eap الطريقة الافتراضية من md5 إلى peap، والسبب أن EAP-MD5 لا يبني أي نفق ولا يولد مفاتيح تشفير، فلا يصلح لـ Wi-Fi إطلاقاً، وهو موجود لأسباب تاريخية فقط.

أربع عقبات حقيقية في الطريق

لم يعمل المختبر من أول مرة، والعقبات التي واجهناها هي نفسها التي سوف تواجهها في أي تثبيت، فنذكرها بترتيب ظهورها وكيف حللناها.

الأولى: السيرفر يتجاهل نقطة الوصول. أرسلت eapol_test طلبها مرة بعد مرة ولم يأت رد، حتى انتهت المهلة. وسجل السيرفر في وضع التصحيح radiusd -X كان صريحاً:

Ignoring request to auth address * port 1812 bound to server default from unknown client 192.168.96.3 port 59145 proto udp

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

الثانية: الإعداد الذي عدلناه ليس الإعداد الذي يقرؤه السيرفر. بعد تصحيح النطاق بقي السيرفر يقول «عميل غير معروف». والسبب أن الإعداد في هذه الـ Image يقع فعلاً في /opt/etc/raddb، و/etc/raddb مجرد رابط إليه، فلما نسخنا إعدادنا إلى المسار الثاني ظن السيرفر أنه لم يتغير شيء. وفي التجربة نفسها رفض السيرفر أن يعمل لأن ملف الإعداد قابل للكتابة من أي مستخدم، وهو فحص أمان في FreeRADIUS:

Configuration file /opt/etc/raddb/clients.conf is globally writable.  Refusing to start due to insecure configuration.

والسيرفر محق، فمن يستطيع تعديل قائمة العملاء أو كلمات المرور يستطيع أن يفتح الشبكة لنفسه، لذلك احفظ إعداد RADIUS بصلاحية لا تسمح بالكتابة إلا لـ root، ولا تشاركه في مجلد مفتوح.

الثالثة: أداة الاختبار نفسها. نسخة eapol_test في حزمة التوزيعة توقفت برسالة تأكيد Assertion في كل تشغيل، وعند قراءة الكود وجدنا أن الرسالة تعني «عنوان IP غير صالح»، أي أن الأداة لا تقبل اسم السيرفر وإنما عنوانه الرقمي فقط. فبنيناها من الكود الرسمي للإصدار 2.12، واحتجنا إزالة خيار -Werror من ملف البناء لأن المترجم الحديث يحول بعض التحذيرات إلى أخطاء، ثم مررنا عنوان السيرفر رقماً.

الرابعة، وأهمها: شهادة منتهية. بعد أن وصلت الرسائل، بدأ نفق TLS، ثم فشل الدخول، وفي مخرج eapol_test السبب:

            Not Before: Jun  8 13:02:11 2026 GMT
            Not After : Aug  7 13:02:11 2026 GMT
TLS: Certificate verification failed, error 10 (certificate has expired) depth 1
CTRL-EVENT-EAP-TLS-CERT-ERROR reason=4 depth=1 ... err='certificate has expired'

الشهادات التجريبية التي تأتي مع الـ Image صالحة ستين يوماً فقط من يوم بنائها، وانتهت في 7 أغسطس 2026، فرفضها الجهاز وأرسل تنبيه TLS قاتلاً رقمه 45، ومعناه «الشهادة منتهية». وتخيل هذا في المتجر: في صباح يوم ما تنتهي شهادة سيرفر RADIUS، فيرفض كل لابتوب وكل جوال وكل جهاز دفع الدخول في اللحظة نفسها، في الفروع الثلاثة. وانتهاء شهادة سيرفر RADIUS سبب معروف لتوقف شبكات Wi-Fi المؤسسية، لأن الشهادة تعمل بصمت لسنة أو سنتين حتى ينساها الجميع. والحل الذي اتبعناه هو الصحيح للإنتاج أيضاً: جهة إصدار CA خاصة بالمؤسسة، وشهادة سيرفر منها:

openssl req -x509 -newkey rsa:3072 -nodes -keyout ca.key -out ca.pem -days 1095 \
  -subj "/O=Coffee Store Lab/CN=Coffee Store RADIUS CA" \
  -addext "basicConstraints=critical,CA:TRUE" -addext "keyUsage=critical,keyCertSign,cRLSign"
openssl req -newkey rsa:3072 -nodes -keyout server.key -out server.csr \
  -subj "/O=Coffee Store Lab/CN=radius.example.com"
printf "basicConstraints=CA:FALSE\nkeyUsage=critical,digitalSignature,keyEncipherment\nextendedKeyUsage=serverAuth\nsubjectAltName=DNS:radius.example.com\n" > ext.cnf
openssl x509 -req -in server.csr -CA ca.pem -CAkey ca.key -CAcreateserial -out server.crt -days 365 -extfile ext.cnf

subject=O=Coffee Store Lab, CN=radius.example.com
issuer=O=Coffee Store Lab, CN=Coffee Store RADIUS CA
notBefore=Oct 26 12:59:07 2026 GMT
notAfter=Oct 26 12:59:07 2027 GMT
X509v3 Extended Key Usage: TLS Web Server Authentication
X509v3 Subject Alternative Name: DNS:radius.example.com

في الإعداد أعلاه لاحظ التالي: جهة الإصدار صالحة ثلاث سنوات، وشهادة السيرفر سنة واحدة، والسبب أنك تريد تجديد شهادة السيرفر بانتظام دون أن تضطر لتوزيع CA جديدة على كل الأجهزة، فالأجهزة تثق بالـ CA، وكل شهادة سيرفر جديدة منها مقبولة تلقائياً. والخاصية extendedKeyUsage=serverAuth مطلوبة، فبعض الأنظمة مثل Windows ترفض شهادة سيرفر RADIUS بدونها. والاسم في subjectAltName هو الاسم الذي سوف يتحقق منه كل جهاز، وسنرى بعد قليل لماذا هو أهم سطر في الإعداد كله. ثم ضع في التقويم تذكيراً قبل انتهاء الشهادة بشهر، أو أضف فحصاً في أداة المراقبة يقرأ تاريخ انتهائها.

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

الاختبار: دخول ناجح ودخول مرفوض

ملف الإعداد لـ eapol_test هو نفسه صيغة إعداد wpa_supplicant على أي جهاز Linux، وهذا ما يجعله مثالاً حقيقياً لما يضبطه الجهاز:

network={
    key_mgmt=WPA-EAP
    eap=PEAP
    identity="ahmad"
    anonymous_identity="anonymous"
    password="CoffeePass#2026"
    phase2="auth=MSCHAPV2"
    ca_cert="/ed/pki/ca.pem"
    domain_suffix_match="radius.example.com"
}

في الإعداد أعلاه لاحظ أن الهوية الحقيقية ahmad لا تخرج إلا داخل النفق، وخارجه تظهر anonymous، وأن الجهاز يعرف شهادة الـ CA التي يثق بها، والاسم الذي يجب أن يحمله السيرفر. ثم شغلنا الاختبار ثلاث مرات، لأحمد بكلمة مروره، ولأحمد بكلمة مرور خاطئة، ولسارة:

eapol_test -c peap-ahmad.conf -a 192.168.96.2 -p 1812 -s ap-shared-secret-2026 -r 0

===== ahmad =====
CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected
CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
MPPE keys OK: 1  mismatch: 0
SUCCESS
===== wrong password =====
CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected
CTRL-EVENT-EAP-FAILURE EAP authentication failed
MPPE keys OK: 0  mismatch: 1
FAILURE
===== sara =====
CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected
CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
MPPE keys OK: 1  mismatch: 0
SUCCESS

في المخرج أعلاه لاحظ التالي: الطريقة 25 هي رقم PEAP في سجل طرق EAP، واختارها الطرفان بعد أن رفض الجهاز اقتراح السيرفر الأول. والسطر MPPE keys OK: 1 هو الأهم بعد النجاح، فهو يعني أن مفتاح التشفير الذي حسبه الجهاز يطابق المفتاح الذي أرسله السيرفر إلى نقطة الوصول، وهذا المفتاح هو الذي تبدأ به نقطة الوصول تشفير الحركة لهذا الجهاز وحده. فإذا رأيت نجاحاً مع mismatch: 1 فهناك خلل في تمرير المفاتيح، والجهاز سيدخل ثم لا يستطيع أن يتواصل. أما كلمة المرور الخاطئة فرد عليها السيرفر برسالة Access-Reject، ورأينا في سجله أنه أخر الرد ثانية كاملة عمداً، وهذا تأخير الرفض reject_delay الذي يبطئ من يحاول تخمين كلمات المرور.

الـ VLAN الديناميكية: شبكة واحدة وأدوار مختلفة

نجح الدخول، ولكن الرد في البداية لم يحمل رقم الـ VLAN. وعندما فتحنا رسالة Access-Accept وجدنا فيها مفاتيح التشفير فقط، والسبب مهم: في PEAP يحدث التحقق الحقيقي داخل النفق في جزء من السيرفر اسمه inner-tunnel، والرد الذي يحمل الـ VLAN يولد هناك، ولا ينتقل إلى الرد الخارجي الذي تراه نقطة الوصول إلا إذا طلبت ذلك. وفي FreeRADIUS 3.2 الطريقة الموثقة في ملف sites-enabled/inner-tunnel نفسه أن تغير الشرط if (0) في قسم post-auth إلى if (1)، فينسخ الرد الداخلي إلى الجلسة الخارجية. وبعد التغيير صار الرد كما يلي:

RADIUS message: code=2 (Access-Accept) identifier=10 length=193
   Attribute 64 (Tunnel-Type) length=6
      Value: 0000000d
   Attribute 65 (Tunnel-Medium-Type) length=6
      Value: 00000006
   Attribute 81 (Tunnel-Private-Group-Id) length=4
      Value: 3230

اقرأ هذه القيم كما تقرؤها نقطة الوصول: الصفة 64 قيمتها 13 بالسداسي 0d وتعني VLAN، والصفة 65 قيمتها 6 وتعني IEEE-802، والصفة 81 قيمتها 3230 وهي الحرفان "2" و"0" بترميز ASCII، أي الرقم 20. ولسارة كانت القيمة 3330، أي 30. والصورة التالية تبين ما يحدث بعد ذلك:

هذه هي القيمة الكبرى لـ Enterprise في المتجر: لا تحتاج ثلاث شبكات Wi-Fi بثلاثة أسماء، فاسم واحد يكفي، والسيرفر يضع الكاشير في شبكة نقاط البيع، والمدير في شبكة الإدارة، وأي حساب ضيف في شبكة لا ترى إلا الإنترنت. ونقطة الوصول تأخذ الرقم من الرد وتضع الجهاز في الـ VLAN المطابقة، بشرط أن تكون هذه الـ VLAN معرفة على السويتش والجدار الناري، وقد شرحنا تعريفها والقواعد بينها في دليل MikroTik في الواقع. ولاحظ أن الرد كبر من 177 بايتاً إلى 193 بايتاً بعد إضافة الصفات الثلاث، وهذا فرق تراه في السجل لتتأكد أن الـ VLAN تصل فعلاً.

ماذا لو ظهرت نقطة وصول مزيفة؟

الخطر الأشهر على PEAP نقطة وصول تحمل اسم شبكة المتجر نفسه Evil Twin ومعها سيرفر RADIUS بشهادة غير شهادتك. فإذا لم يتحقق جهاز الموظف من شهادة السيرفر، بنى النفق مع السيرفر الخطأ وأرسل إليه إجابة MSCHAPv2 التي يمكن أن تكشف كلمة مرور ضعيفة. والحماية كلها في سطرين في إعداد الجهاز: شهادة الـ CA التي يثق بها، والاسم الذي يجب أن يحمله السيرفر. ولنرى ما يحدث عندما يجد الجهاز سيرفراً يحمل اسماً غير الذي ينتظره، غيرنا الاسم المتوقع في إعداد الجهاز:

TLS: Domain suffix match 'radius.coffeestore.example' not found
CTRL-EVENT-EAP-TLS-CERT-ERROR reason=9 depth=0 subject='/O=Coffee Store Lab/CN=radius.example.com' err='Domain suffix mismatch'
CTRL-EVENT-EAP-FAILURE EAP authentication failed

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

والمشكلة في الواقع أن كثيراً من الأجهزة تسأل المستخدم عند أول اتصال: «هل تثق بهذه الشهادة؟»، والمستخدم يضغط نعم دون أن يقرأ، فيكون قد قبل أي شهادة. لذلك لا تترك الإعداد للمستخدم، بل وزعه من أداة إدارة الأجهزة MDM في ملف تعريف Profile يحمل الـ CA والاسم، أو من Group Policy في بيئة Windows، فيتصل الجهاز ولا يسأل أحداً. وإذا لم تكن عندك أداة إدارة، فهذا من أقوى الأسباب للانتقال إلى EAP-TLS، لأن الجهاز الذي يدخل بشهادة لا يملك كلمة مرور يمكن أن يسلمها لأحد.

الدخول بشهادة: EAP-TLS

أصدرنا من جهة الإصدار نفسها شهادة لجهاز اسمه laptop01، بخاصية clientAuth هذه المرة، وضبطنا الجهاز لـ EAP-TLS:

network={
    key_mgmt=WPA-EAP
    eap=TLS
    identity="laptop01.example.com"
    ca_cert="/ed/pki/ca.pem"
    client_cert="/ed/pki/laptop01.crt"
    private_key="/ed/pki/laptop01.key"
    domain_suffix_match="radius.example.com"
}

CTRL-EVENT-EAP-METHOD EAP vendor 0 method 13 (TLS) selected
CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
SUCCESS
# in the server log:
(44) eap_tls:   TLS-Client-Cert-Common-Name = "laptop01.example.com"
(45) Sent Access-Accept Id 7 from 192.168.96.2:1812 to 192.168.96.3:40454 length 188

الطريقة 13 هي EAP-TLS، ولم يحتج السيرفر أي إعداد إضافي، لأنه يقبل أي شهادة جهاز موقعة من الـ CA التي يثق بها، وسجل اسم الجهاز من شهادته. ولاحظ أننا لم نكتب أي كلمة مرور في أي مكان. ولكن انتبه إلى ما يعنيه «أي شهادة من الـ CA»: إذا فقد لابتوب وفيه شهادته، فإن الشهادة تبقى صالحة حتى تلغيها، لذلك يحتاج EAP-TLS في الإنتاج قائمة إلغاء CRL أو فحص OCSP يعرف منه السيرفر الشهادات الملغاة، وهذا جزء من تشغيل جهة الإصدار الذي ذكرناه في نقاط الضعف.

من أين يعرف السيرفر الموظفين؟

في المختبر وضعنا الموظفين في ملف نصي، وهذا لا يناسب متجراً يضيف ويحذف موظفين كل شهر، فالمكان الطبيعي للحسابات هو دليل المستخدمين الذي تديره المؤسسة أصلاً: Active Directory في بيئات Windows، أو دليل LDAP، أو مزود هوية مثل الذي شرحناه في دليل إدارة الهوية والوصول. والفائدة أن الموظف الذي يعطل حسابه في الدليل يفقد الوصول إلى Wi-Fi تلقائياً في اللحظة نفسها، دون أن يتذكر أحد أن يعدل ملف RADIUS.

ولكن هنا قيد تقني يفاجئ كثيرين: طريقة MSCHAPv2 داخل PEAP لا تقبل إلا نوعين من تخزين كلمات المرور، النص الصريح أو هاش NT الخاص بـ Windows، ولا تعمل مع كلمات المرور المحفوظة بهاش MD5 أو SHA1 أو crypt، كما يبين جدول التوافق الذي نشره مؤلف FreeRADIUS نفسه. والسبب في طريقة MSCHAPv2: السيرفر لا يستقبل كلمة المرور، وإنما إجابة على سؤال محسوبة من هاش NT، فيحتاج أن يحسب الإجابة نفسها، وهذا مستحيل إذا كان يملك هاشاً من نوع آخر. ولهذا:

• مع Active Directory: يعمل PEAP جيداً، لأن الدليل يملك هاش NT، والطريقة المعتادة أن ينضم سيرفر FreeRADIUS إلى النطاق بـ Samba ويسأله عبر أداة ntlm_auth.
• مع LDAP يحفظ كلمات المرور بهاش آخر: لا يعمل PEAP-MSCHAPv2، فإما أن تستخدم طريقة EAP-TTLS مع PAP التي ترسل كلمة المرور نفسها داخل النفق ليتحقق منها السيرفر أمام LDAP، وإما أن تنتقل إلى EAP-TLS بالشهادات.
• مع EAP-TLS: لا يحتاج السيرفر كلمات المرور إطلاقاً، ويكفيه أن يسأل الدليل إن كان صاحب الشهادة ما زال موظفاً فعالاً، وهذا سبب إضافي لكونه الخيار الأنظف على المدى الطويل.

وهذا القرار يجب أن يتخذ قبل أن توزع الإعداد على الأجهزة، لأن تغيير طريقة الدخول بعد ذلك يعني إعادة الإعداد على كل جهاز.

من دخل ومتى؟ سجل الجلسات Accounting

تذكر المشكلة التي بدأت بها القصة: جهاز غريب على شبكة الفرع الثاني ولا يعرف أحد صاحبه. هنا يقدم RADIUS جزءاً ثانياً لا يقل أهمية عن التحقق، وهو المحاسبة Accounting الموصوفة في RFC 2866، وتعمل على المنفذ 1813. فنقطة الوصول ترسل إلى السيرفر رسالة عند بداية كل جلسة وعند نهايتها، وبشكل دوري أثناءها، وفيها اسم المستخدم وعنوان جهازه ونقطة الوصول التي اتصل بها والمدة وحجم البيانات. فيصبح عندك سجل يقول: أحمد اتصل من الفرع الأول بجهاز عنوانه كذا من الساعة الثامنة إلى الثالثة. ولو كان هذا السجل موجوداً في المتجر، لعرف المدير اسم صاحب الجهاز الغريب في دقيقة.

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

خطة الانتقال في المتجر

لا تنقل الفروع الثلاثة إلى Enterprise في ليلة واحدة، فأي خطأ في الشهادة أو في الـ VLAN سيوقف الدفع في كل الفروع. والطريقة الأسلم أن تتدرج:

1. المختبر أولاً: كما فعلنا، سيرفر RADIUS واختبار بـ eapol_test لكل طريقة دخول ولكل دور، حتى ترى القبول والرفض والـ VLAN بعينك قبل أي نقطة وصول.
2. شبكة جديدة بجانب القديمة: أضف اسم شبكة Enterprise جديداً في فرع واحد، واترك الشبكة القديمة تعمل، وانقل إليها أجهزة الإدارة أولاً، فهي الأقل حساسية للتوقف.
3. توزيع الإعداد مركزياً: ملف تعريف يحمل الـ CA واسم السيرفر لكل جهاز، حتى لا يضغط أي موظف «أثق» على شهادة لا يعرفها.
4. أجهزة الدفع آخراً وبعناية: بعض أجهزة الدفع والطابعات وأجهزة إنترنت الأشياء لا تدعم 802.1X أصلاً، وهذه تحتاج شبكة منفصلة خاصة بها بكلمة مرور قوية في VLAN معزولة، بدل أن تبقى السبب في إبقاء الشبكة كلها مشتركة.
5. إيقاف الشبكة القديمة: بعد أن ينتقل الجميع، أوقف الشبكة المشتركة وغير كلمة مرورها، فهي التي يعرفها الموظف الذي غادر.

ولاحظ في الخطوة الرابعة أن Enterprise ليس حلاً لكل جهاز، فالأجهزة البسيطة التي لا تفهم 802.1X تبقى على Personal، ولكن في شبكة معزولة لا ترى إلا ما تحتاجه، وهذا هو المبدأ نفسه الذي تطلبه الضوابط: لا يتصل اللاسلكي بالشبكة الداخلية إلا بعد دراسة المخاطر ومعالجتها.

الموارد والبديل التجاري

FreeRADIUS خفيف بشكل لافت: استهلك في المختبر 8.9 MiB من الذاكرة، وحجم الـ Image نحو 73 MB، وأي سيرفر صغير أو جهاز افتراضي بنواة واحدة يكفي متجراً بثلاثة فروع ومئات الأجهزة، لأن العمل الثقيل الوحيد هو بناء نفق TLS عند كل دخول، وهو جزء من الثانية. والأهم من القوة هو التوفر: إذا توقف سيرفر RADIUS لا يدخل أحد، لذلك ضع سيرفرين وأضف الاثنين في إعداد نقاط الوصول، فإذا لم يرد الأول سألت الثاني. ولا تنس أن الأجهزة تعيد التحقق دورياً وكلما تنقل الموظف بين نقاط الوصول في الفرع، فعدد عمليات الدخول في اليوم أكبر بكثير من عدد الموظفين، ولكنه يبقى حملاً صغيراً على سيرفر بهذا الحجم.

أما البدائل التجارية فأشهرها Cisco ISE وAruba ClearPass للمؤسسات الكبيرة، وخدمات RADIUS السحابية مثل JumpCloud. وقد راجعنا صفحة أسعار JumpCloud بتاريخ 26 أكتوبر 2026 فوجدنا أن الباقات التي تشمل Cloud RADIUS تطلب التواصل مع المبيعات ولا تعرض سعراً، وCisco ISE وAruba ClearPass يباعان عبر الموزعين بلا سعر منشور. ونقطة قوة هذه الحلول أنها تأتي بواجهة إدارة وتكامل جاهز مع أدوات إدارة الأجهزة وفحص حالة الجهاز قبل قبوله، ونقطة ضعفها التكلفة والاعتماد على المورد. وFreeRADIUS بلا تكلفة رخصة، ولكن إدارته بملفات إعداد تحتاج شخصاً يفهمها، وهذا ما حاولنا أن نقدمه في هذا المقال.

الجانب السعودي

تنص الضوابط الأساسية للأمن السيبراني ECC من الهيئة الوطنية للأمن السيبراني، في الضابط 2-5-3-4 ضمن متطلبات إدارة أمن الشبكات، على حماية الشبكات اللاسلكية باستخدام وسائل آمنة للتحقق من الهوية والتشفير، وعدم ربطها بالشبكة الداخلية للجهة إلا بعد دراسة متكاملة للمخاطر ومعالجتها بما يحمي الأصول التقنية للجهة، كما جاء في النص الرسمي لوثيقة ECC-2:2024. وما بنيناه في هذا المقال يخدم هذا الضابط مباشرة: التحقق بحساب لكل شخص بدل سر مشترك، وتشفير بمفتاح لكل جهاز، والـ VLAN الديناميكية التي تمنع الضيف من الوصول إلى الشبكة الداخلية. وهذه الضوابط ملزمة للجهات الحكومية والجهات المشغلة للبنى التحتية الحساسة، ولكنها مرجع جيد لأي مؤسسة تريد أن تعرف ما المقصود بشبكة لاسلكية آمنة.

قائمة تحقق قبل التشغيل

الخلاصة

• كلمة المرور المشتركة لا تخرج الموظف الذي غادر، ولا تعرف من دخل، ولا تفصل الأدوار، وWPA3-Personal لا يغير هذا، فالسؤال هو Personal أم Enterprise.
• في 802.1X نقطة الوصول لا تعرف كلمات المرور، بل تمرر رسائل EAP إلى RADIUS، ودخول PEAP واحد احتاج في المختبر 22 رسالة RADIUS.
• FreeRADIUS 3.2.10 قبل أحمد وسارة ورفض كلمة المرور الخاطئة، ووضع كل واحد في الـ VLAN الخاصة به بعد تفعيل نسخ الرد من inner-tunnel.
• الشهادة التجريبية المنتهية أوقفت الدخول كله، فاصنع جهة إصدار خاصة وراقب تاريخ انتهاء شهادة السيرفر.
• التحقق من اسم السيرفر وشهادة الـ CA على الجهاز هو ما يرفض السيرفر الخطأ، فوزعه من أداة إدارة الأجهزة ولا تتركه للمستخدم.
• EAP-TLS يلغي كلمات المرور كلها، وثمنه تشغيل جهة إصدار وتوزيع الشهادات وإلغاؤها.

وفي المقال القادم بإذن الله سوف نعود إلى الأساس: إعدادات أمن الشبكة اللاسلكية في أي راوتر، من WPA3 إلى فصل شبكة الضيوف وإيقاف WPS، وهي الخطوة التي تحتاجها كل مؤسسة حتى قبل أن تبني RADIUS.

دليلتقسيم الشبكة Network Segmentation بال VLAN وال VPCلماذا تصل كاميرا مخترقة إلى قاعدة بياناتك، وكيف تمنع ذلك بتقسيم الشبكة إلى مناطق لا يمر بينها إلا ما تسمح به.دليلبوابة الدخول Captive Portal: شبكة الضيوف برمز تحققكيف تعمل بوابة الدخول في شبكة Wi-Fi الضيوف، وكيف تختار طريقة التحقق والأدوات المناسبة لمقهى أو فندق أو شركة.دليلبناء بوابة دخول Wi-Fi برمز تحقق: تجربة عملية كاملةنبني بوابة دخول تعمل فعلاً برمز تحقق وجلسة محدودة المدة وسجل لكل اتصال، ثم ننقلها إلى راوتر حقيقي.دليلMikroTik في الواقع: سيناريوهات عملية للبيت والمكتبكيف تبني على RouterOS ما تحتاجه فعلاً في البيت والمكتب، من شبكة ضيوف معزولة إلى الوصول الآمن من الخارج عبر WireGuard.

تدريب عملي Practice

• شغل FreeRADIUS بالخيار -X وأضف مستخدماً ثالثاً بـ VLAN مختلفة، ثم اختبره بـ eapol_test واقرأ الصفة 81 في Access-Accept بنفسك.
• أصدر شهادة سيرفر صالحة يوماً واحداً، وانتظر انتهاءها، وشاهد الرسالة التي يعطيها eapol_test، حتى تعرفها يوم تراها في الإنتاج.

سجل التحديثات

• أكتوبر 2026: كتابة الدليل وتنفيذ المختبر يوم 26 أكتوبر 2026 على FreeRADIUS 3.2.10 مع eapol_test 2.12 المبني من الكود الرسمي، بطريقتي PEAP-MSCHAPv2 وEAP-TLS والـ VLAN الديناميكية.