بوابة الدخول Captive Portal: شبكة الضيوف برمز تحقق

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

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

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

• ما هي بوابة الدخول، وماذا يحدث للضيف من الاتصال حتى انتهاء الجلسة؟ في تسع خطوات.
• كيف يكتشف Android وApple وWindows البوابة، بعناوين الفحص من وثائقهم الرسمية.
• لماذا لا تستطيع البوابة تحويل طلبات HTTPS، والطريقة القياسية الحديثة عبر الخيار 114 في DHCP والواجهة البرمجية Captive Portal API.
• طرق التحقق: رمز SMS، ورمز WhatsApp، والقسائم Vouchers، والبريد، وحسابات التواصل، ورقم الغرفة، وموافقة الموظف المضيف، ومقارنة بينها.
• أمان رمز التحقق OTP، وهجمات ضخ الرسائل SMS Pumping وتبديل الشريحة SIM Swap، وأثر عنوان MAC العشوائي.
• RADIUS والمحاسبة Accounting وقطع الجلسة عن بعد CoA، وعزل الضيوف عن بعضهم، والتشفير دون كلمة مرور عبر OWE.
• ما الذي وجدناه في أنظمة هيئة الاتصالات والفضاء والتقنية CST، ونظام حماية البيانات الشخصية PDPL.
• الأدوات المتاحة بتراخيصها، وجدول يساعدك على الاختيار حسب المكان.

ما هي بوابة الدخول Captive Portal؟

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

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

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

ماذا يحدث للضيف من الاتصال حتى انتهاء الجلسة؟

الصورة التالية تبين الخطوات التسع التي يمر بها كل جهاز، من لحظة اختيار اسم الشبكة إلى أن تنتهي جلسته ويعود محجوزاً:

وفيما يلي كل خطوة بتفصيلها:

1. الاتصال بنقطة الوصول Association: يختار الضيف اسم الشبكة SSID، وفي الشبكة المفتوحة لا توجد كلمة مرور، فيتصل الهاتف مباشرة. وفي هذه اللحظة لا تعرف البوابة شيئاً عن الضيف إلا عنوان MAC الخاص ببطاقة الشبكة، وهو كما سنرى في قسم MAC العشوائي ليس ثابتاً كما كان في السابق.
2. العنوان عبر DHCP: يطلب الهاتف عنواناً فيحصل على عنوان IP في شبكة الضيوف، والبوابة الافتراضية Default Gateway وهي جهاز البوابة نفسه، وسيرفر DNS، وفي الشبكات الحديثة يحصل أيضاً على رابط الواجهة البرمجية للبوابة عبر الخيار 114 كما سيأتي.
3. الحديقة المسورة Walled Garden: هي القائمة الصغيرة من الوجهات المسموحة قبل الدخول: DNS، وصفحة البوابة، وأحياناً صفحة الدفع أو صفحة الشروط أو خادم تسجيل الدخول عبر Google إذا كانت البوابة تستخدمه. وكل ما عداها يمنعه الجدار.
4. التحويل إلى البوابة Redirect: عندما يفحص الهاتف الاتصال، أو عندما يفتح المستخدم موقعاً عبر HTTP، يعترض الجدار الطلب على المنفذ 80 ويرسله إلى سيرفر البوابة، فيرد عليه بإعادة توجيه 302 إلى صفحة الدخول. وبعض البوابات القديمة تفعل ذلك بتزوير ردود DNS، أي أن كل اسم يتحول إلى عنوان البوابة، وهذه أسوأ الطرق على الإطلاق لأنها تفسد ذاكرة DNS في الهاتف وتكسر التحقق عبر DNSSEC.
5. التحقق Authentication: هنا يثبت الضيف شيئاً ما: أنه وافق على الشروط، أو أنه يملك هذا الرقم، أو أنه نزيل في الغرفة 412، أو أنه اشترى قسيمة. وهذا موضوع قسم طرق التحقق.
6. القرار عبر RADIUS: في الأنظمة البسيطة تقرر البوابة بنفسها، وفي الأنظمة المتوسطة والكبيرة تسأل سيرفر RADIUS، فيرد بالقبول ومعه حدود الجلسة: مدتها وسرعتها وكمية البيانات المسموحة.
7. التفويض Authorisation: يضيف الجدار الناري هذا الجهاز إلى قائمة المسموح لهم، وغالباً بعنوان IP وعنوان MAC معاً، فلا يستطيع جهاز آخر أن يأخذ العنوان نفسه ويمر. ومن هذه اللحظة لا يرى الضيف البوابة، وتمر حركته إلى الإنترنت مع حد للسرعة Bandwidth إن وجد.
8. المحاسبة Accounting: يرسل جهاز البوابة إلى RADIUS سجل بداية Start، ثم تحديثات دورية Interim-Update فيها المدة وعدد البايتات، ثم سجل نهاية Stop عند الخروج، وهذا هو السجل الذي تعود إليه إذا سألتك جهة ما: من كان يستخدم هذا العنوان في الساعة التاسعة مساءً؟
9. الانتهاء أو الخروج: تنتهي الجلسة عند انتهاء مدتها Session Timeout، أو بعد خمول Idle Timeout، أو عندما يضغط الضيف «تسجيل الخروج»، أو عندما يقطعها المسؤول عن بعد، فيحذف الجدار الجهاز من القائمة ويعود محجوزاً، ويظهر له الفحص البوابة من جديد.

كيف يعرف الهاتف أنه خلف بوابة دخول؟

لا ينتظر الهاتف أن يفتح المستخدم المتصفح، فكل نظام تشغيل حديث يطلب بعد الاتصال بأي شبكة عنواناً معروفاً عبر HTTP العادي، ويعرف مسبقاً الرد الصحيح عليه، فإذا وصل الرد كما هو فالإنترنت متاح، وإذا وصل رد آخر، مثل إعادة توجيه أو صفحة HTML لا يعرفها، فهذه علامة على وجود بوابة، فيفتح نافذة «سجل الدخول إلى الشبكة» بنفسه. والصورة التالية تبين الفرق بين الحالتين وعناوين الفحص في الأنظمة الثلاثة:

والعناوين من مصادرها الرسمية كما يلي:

• Android: في إعدادات وحدة NetworkStack في كود Android العنوان الافتراضي للفحص عبر HTTP هو http://connectivitycheck.gstatic.com/generate_204، وعبر HTTPS هو https://www.google.com/generate_204، والرد الصحيح رد فارغ برمز 204. ويستطيع مصنع الهاتف أن يغير هذه العناوين، لذلك قد ترى عناوين أخرى في هواتف بعض الشركات.
• Apple: في قائمة العناوين التي تحتاجها أجهزة Apple في شبكات المؤسسات يظهر captive.apple.com على المنفذين 80 و443 لغرض «التحقق من الاتصال بالإنترنت في الشبكات التي تستخدم بوابة دخول». والصفحة التي تطلبها الأجهزة عملياً هي /hotspot-detect.html، وردها صفحة صغيرة فيها كلمة Success.
• Windows: في وثيقة Microsoft عن مؤشر حالة الاتصال NCSI يطلب Windows 10 وما بعده الملف http://www.msftconnecttest.com/connecttest.txt ويتأكد أن محتواه Microsoft Connect Test، ثم يسأل DNS عن dns.msftncsi.com، وإذا كانت الشبكة تطلب تسجيل الدخول يفتح المتصفح الافتراضي بصفحتها.

ونستطيع أن نطلب هذه العناوين الثلاثة بأنفسنا من شبكة عادية بالأمر curl:

curl -s -i http://connectivitycheck.gstatic.com/generate_204 | head -5
curl -s -i http://captive.apple.com/hotspot-detect.html | sed -n '1p;$p'
curl -s -i http://www.msftconnecttest.com/connecttest.txt | sed -n '1p;$p'

والمخرج سوف يكون كما يلي:

HTTP/1.1 204 No Content
Content-Length: 0
Cross-Origin-Resource-Policy: cross-origin
Date: Fri, 09 Oct 2026 01:15:43 GMT

HTTP/1.1 200 OK
<HTML><HEAD><TITLE>Success</TITLE></HEAD><BODY>Success</BODY></HTML>
HTTP/1.1 200 OK
Microsoft Connect Test

ولاحظ أن الفحص كله عبر HTTP دون تشفير، وهذا مقصود، لأن البوابة تستطيع أن تعترض HTTP وترد عليه دون أن يظهر أي خطأ، وهي لا تستطيع ذلك مع HTTPS كما سنرى بعد قليل. وفي التجربة العملية ترى الطلب نفسه خلف البوابة وقد تحول إلى 302 Found.

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

لماذا لا تستطيع البوابة تحويل طلبات HTTPS؟

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

وفي الشكل أعلاه لاحظ ما يلي:

• تزوير الشهادة يظهر للضيف صفحة خطأ مخيفة، وفي المواقع التي تستخدم ترويسة HSTS أو الموجودة في القائمة المسبقة للمتصفح لا يوجد زر «المتابعة رغم الخطر» أصلاً، وهذا هو المطلوب من HSTS. وقد كتبت معمارية IETF للبوابات في RFC 8952 أن الحلول يجب ألا تعتمد على تزوير ردود DNS أو HTTP أو أي بروتوكول آخر، وأن بعض البوابات تحاول أن تكون وسيطاً لاعتراض HTTPS وهذا تحديداً ما تريد المعمارية التخلص منه.
• إغلاق المنفذ 443 هو ما تفعله أغلب البوابات، والأفضل أن يرد الجدار برفض فوري TCP Reset بدل أن يسقط الحزمة بصمت، فيظهر للمتصفح خطأ الاتصال خلال جزء من الثانية بدل أن ينتظر دقيقة، ويحاول الهاتف الفحص عبر HTTP فيرى البوابة.
• صفحة البوابة نفسها يجب أن تكون على HTTPS بشهادة صحيحة لاسم حقيقي، لأن الضيف يكتب فيها رقم جواله ورمز التحقق، ولأن أنظمة Apple تشترط HTTPS في الطريقة الحديثة كما سيأتي. وهذا يعني أن البوابة تحتاج اسم نطاق Domain وشهادة تتجدد، وأن اسم البوابة يجب أن يحل عبر DNS قبل الدخول.

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

الطريقة القياسية الحديثة: الشبكة تخبر الجهاز بنفسها

كل ما سبق قائم على التخمين: الهاتف يحاول ويستنتج من الرد الغريب أن هناك بوابة. ولهذا نشرت IETF في 2020 مجموعة معايير تسمى CAPPORT تقلب الفكرة، فالشبكة تقول للجهاز صراحة عند إعطائه العنوان: «هناك بوابة، واسألني عن حالتك من هذا الرابط». والصورة التالية تبين الأجزاء الخمسة كما وصفتها RFC 8952:

• إعلان الرابط عبر RFC 8910: تحدد RFC 8910 الخيار 114 في DHCPv4، والخيار 103 في DHCPv6، والخيار 37 في إعلانات الراوتر Router Advertisement في IPv6، وكلها تحمل رابطاً واحداً يشير إلى الواجهة البرمجية. وقد ألغت هذه الوثيقة RFC 7710 التي كانت تستخدم الرقم 160، لأنه كان مستخدماً في أجهزة Polycom. وإذا كانت الشبكة بلا بوابة تستطيع أن ترسل القيمة urn:ietf:params:capport:unrestricted فيتجاوز الجهاز الفحوصات.
• الواجهة البرمجية عبر RFC 8908: تحدد RFC 8908 أن الرابط يجب أن يكون https، وأن الرد من نوع application/captive+json، وأن الحقل الوحيد الإلزامي هو captive، ومعه حقول اختيارية مثل user-portal-url وvenue-info-url وseconds-remaining وbytes-remaining وcan-extend-session.

وهذا مثال الرد من الوثيقة نفسها لجهاز سجل الدخول وبقي له 326 ثانية:

{
   "captive": false,
   "user-portal-url": "https://example.org/portal.html",
   "venue-info-url": "https://flight.example.com/entertainment",
   "seconds-remaining": 326,
   "can-extend-session": true
}

وقد أعلنت Apple في صفحة تحديث الشبكات المحجوزة دعم الخيارات الثلاثة والواجهة البرمجية منذ iOS 14 وmacOS Big Sur، واشترطت أن يعمل سيرفر ال API بتشفير TLS. ويدعمها أيضاً OPNsense الذي يشترط شهادة موثوقة عامة على منطقة البوابة، وopenNDS الذي يرسل الخيار 114 افتراضياً.

وهل يعني هذا أن نترك الاعتراض القديم؟ لا، والسبب أن ليس كل جهاز يفهم الخيار 114، فتوثيق openNDS نفسه يذكر أن أجهزة قليلة كانت تدعم ال API عند كتابته، وتوثيق OPNsense يقول إن التحويل القسري يبقى مفعلاً لأقصى توافق. لذلك فالإعداد الصحيح اليوم هو الطريقتان معاً: الخيار 114 مع API صحيح لمن يفهمه، والاعتراض على المنفذ 80 لمن لا يفهمه.

طرق التحقق: ماذا يثبت الضيف بالضبط؟

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

• الموافقة فقط Click-through: صفحة فيها الشروط وزر «موافق». لا توجد أي هوية، وتكفي حيث لا تحتاج أن تعرف من دخل، وهي الأسهل للضيف.
• رمز عبر SMS: يكتب الضيف رقمه فيصله رمز لمرة واحدة One-Time Password، واختصاراً OTP. وهي الطريقة الأشهر في المطارات والمراكز التجارية، لأن رقم الجوال في المملكة مرتبط بهوية صاحبه عند شركة الاتصالات، ولكنها تكلف ثمن رسالة لكل دخول، وتفشل مع الزائر الذي لا يملك شريحة محلية تعمل.
• رمز عبر WhatsApp: الرمز نفسه ولكن برسالة من حساب WhatsApp Business، وينفع الزائر الذي يعمل WhatsApp عنده دون شريحة محلية، والتفصيل في القسم التالي.
• القسائم Vouchers: رموز مطبوعة أو مولدة سلفاً، لكل رمز مدة وحد، يعطيها موظف الاستقبال أو تطبع مع الفاتورة. لا تحتاج أي مزود رسائل، وتعمل دون إنترنت للبوابة نفسها، وتدعمها OPNsense وpfSense مباشرة.
• البريد الإلكتروني: إما أن يكتب الضيف بريده دون تحقق فيصبح مثل الموافقة، وإما أن يصله رابط أو رمز، ولكن هذا يحتاج أن تسمح له بالوصول إلى بريده قبل الدخول، أي أن تفتح الحديقة المسورة لخدمات البريد، وهذه مشكلة.
• حسابات التواصل Social Login: الدخول بحساب Google أو Facebook عبر تدفق OAuth وOpenID Connect، ويحتاج أن تضيف نطاقات مزود الهوية إلى الحديقة المسورة، وهي قائمة تتغير، وتعطيك بيانات أكثر مما تحتاج.
• رقم الغرفة واسم العائلة Property Management System: في الفنادق يربط النظام البوابة بنظام إدارة الفندق PMS، فيكتب النزيل رقم غرفته واسم العائلة، وتنتهي صلاحيته تلقائياً يوم المغادرة.
• موافقة المضيف Sponsor Approval: في الشركات يكتب الزائر بريد الموظف الذي يزوره، فيصل الموظف رابط موافقة، وبعد موافقته يدخل الزائر، وهكذا يكون لكل زائر مسؤول معروف. وهذه الطريقة موجودة في أنظمة التحكم بالوصول إلى الشبكة NAC مثل PacketFence.

والجدول التالي يضعها جنباً إلى جنب:

رمز التحقق عبر WhatsApp

لا يسمح WhatsApp بأن ترسل نصاً حراً بالرمز، وإنما يحدد توثيق قوالب التحقق Authentication Templates نصاً ثابتاً لا تغيره: «<VERIFICATION_CODE> is your verification code»، مع جملة أمان اختيارية «For your security, do not share this code» وجملة انتهاء اختيارية «This code expires in <NUM_MINUTES> minutes». وتحت الرسالة زر من ثلاثة أنواع: نسخ الرمز Copy Code، أو التعبئة بلمسة One-tap Autofill، أو التعبئة دون لمس Zero-tap حيث يلتقط تطبيق Android الرمز بنفسه، والنوعان الأخيران للتطبيقات وليس لصفحة ويب في متصفح البوابة، لذلك فزر نسخ الرمز هو المناسب للبوابة. ويذكر التوثيق أيضاً أن رسائل التحقق عبر Cloud API تصل إلى الجهاز الرئيسي للحساب فقط وليس إلى الأجهزة المرتبطة، وينصح بأن تتأكد من الرقم قبل أن ترسل إليه الرمز.

أما التكلفة، ففي صفحة الأسعار أن Meta تحاسب منذ 1 يوليو 2025 على كل رسالة تصل بدل كل محادثة، وأن الرسائل مقسمة إلى فئات أهمها التسويق Marketing والخدمات Utility والتحقق Authentication، ولبعض الدول سعر أعلى اسمه Authentication-International. وفي صفحة تحديثات الأسعار أن قوالب الخدمات تكون مجانية داخل نافذة خدمة العملاء المفتوحة، ولكن هذا الاستثناء لا يشمل قوالب التحقق، فكل رمز تدفع ثمنه. والأسعار تختلف حسب دولة الرقم وتتغير، لذلك لا نضع أرقاماً هنا، وراجع جدول الأسعار عند التنفيذ. والطلب نفسه إلى Cloud API، كما في توثيق قالب نسخ الرمز، عبارة عن POST إلى graph.facebook.com بمعرف رقم الحساب ومعه الرمز مرتين: مرة في نص الرسالة ومرة في الزر، وسوف ترى شكله الكامل في التجربة العملية.

رمز التحقق عبر SMS في المملكة

في تنظيمات تقديم خدمة الرسائل القصيرة SMS من هيئة الاتصالات والفضاء والتقنية (الإصدار الثالث، فبراير 2024) أن بيع الرسائل يكون من مقدم خدمة مرخص فقط، ولا يسمح بأكثر من وسيط واحد بينه وبين المشترك، وأن السيرفر يجب أن يكون داخل المملكة والبيانات مخزنة داخلها، وأن الدخول إلى أنظمة الإرسال يكون بتحقق ثنائي. وهذا يعني عملياً أن البوابة التي ترسل رموزاً إلى أرقام سعودية تتعامل مع مزود رسائل محلي مرخص، ومن أمثلة الشركات العاملة في السوق Unifonic وTaqnyat وMsegat، وذكرها هنا للتمثيل وليس توصية، وتحقق من الترخيص في دليل التراخيص في موقع الهيئة قبل التعاقد. وكل هذه الخدمات تعطيك واجهة HTTP بسيطة: ترسل الرقم والنص واسم المرسل، فيرد عليك بمعرف الرسالة.

أمان رمز التحقق

الرمز المكون من ست خانات فيه مليون احتمال فقط، وهذا رقم صغير إذا تركت المهاجم يجرب دون حد، لذلك فإن قوة الرمز تأتي من القواعد حوله وليس من طوله. وتضع إرشادات NIST SP 800-63B-4 للرموز التي تصل عبر قناة ثانية ثلاث قواعد أساسية: أن يكون الرمز ست خانات عشرية على الأقل من مولد عشوائي معتمد، وأن يعتبر التحقق باطلاً إذا لم يكتمل خلال 10 دقائق، وأن يكون هناك حد لعدد المحاولات الخاطئة المتتالية لا يزيد عن 100. وتصنف الإرشادات نفسها الإرسال عبر شبكة الهاتف على أنه طريقة مقيدة Restricted، وتطلب أن ينتبه السيرفر لعلامات الخطر مثل تغيير الشريحة ونقل الرقم قبل أن يرسل الرمز، وقد شرحنا تبديل الشريحة SIM Swap في مقال Passkeys.

ولكن الخطر الأكبر على بوابة الضيوف ليس أن يخمن أحد الرمز، وإنما أن يستخدم أحد بوابتك لإرسال رسائل لا يقرؤها أحد، وهذا ما يسمى ضخ الرسائل SMS Pumping أو الحركة المضخمة صناعياً Artificially Inflated Traffic، والصورة التالية تبين كيف يحدث وما الذي تضعه في بوابتك لمنعه:

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

• اقبل أرقام الدول التي تحتاجها فقط، وارفض كل ما عداها قبل أن تصل إلى المزود.
• مهلة بين رمزين للرقم نفسه، مثل 30 ثانية، وحد لكل رقم مثل 3 رموز في 15 دقيقة، وحد لكل جهاز مثل 5 رموز في الساعة، والسبب أن المهاجم يغير الرقم في كل طلب، فالحد على الرقم وحده لا يكفي لإيقافه.
• عمر قصير للرمز مثل 5 دقائق، وإلغاؤه بعد 5 محاولات خاطئة، وحذفه فور استخدامه مرة واحدة.
• اربط الرمز بالجهاز الذي طلبه، فإذا كتبه جهاز آخر فهو مرفوض، وهذا يمنع أن يطلب أحد الرمز من جهاز ويستخدمه من جهاز آخر.
• لا تكتب الرمز في السجلات، واحفظه إذا احتجت بصيغة هاش Hash مع حذفه بعد انتهائه، مع العلم أن هاش رقم من ست خانات يمكن تخمينه بسهولة، فالحماية الحقيقية هي العمر القصير والحذف.
• راقب نسبة الرموز المرسلة إلى الرموز التي تم التحقق منها، فإذا ارتفع الإرسال وبقي التحقق كما هو فهذه علامة الهجوم.

عنوان MAC العشوائي: لماذا يطلب منك الدخول مرة أخرى؟

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

• Android: في توثيق Android أن الأجهزة من Android 10 تستخدم عنواناً عشوائياً افتراضياً، وهو ثابت لكل شبكة Persistent ولا يتغير إلا بإعادة ضبط المصنع، ومنذ Android 12 يوجد نوع غير ثابت Non-persistent يتغير مثلاً إذا انتهى عقد DHCP ومضت أكثر من 4 ساعات على آخر انقطاع، أو إذا مضت 24 ساعة على توليد العنوان.
• Apple: في توثيق Apple عن عنوان Wi-Fi الخاص ثلاثة خيارات منذ iOS 18: مغلق Off، وثابت Fixed، ومتغير Rotating يتغير كل أسبوعين، والجهاز يختار الثابت للشبكات المحمية بـ WPA2 أو أقوى، ويختار المتغير للشبكات ضعيفة الحماية أو المفتوحة، أي أن شبكة الضيوف المفتوحة هي بالضبط الحالة التي يتغير فيها العنوان. ونسيان الشبكة يمسح العنوان الذي استخدمه الجهاز معها.

والنتيجة أن الضيف قد يعود بعد يومين فتطلب منه البوابة الدخول من جديد، وهذا ليس خطأ في البوابة. لذلك لا تقم بربط هوية الضيف بعنوان MAC وحده، ولا تعتمد عليه في حدود «مرة واحدة لكل جهاز»، فالعنوان قد يتغير مع الجهاز نفسه، وقد يغيره الضيف بنفسه. وهو مع ذلك مفيد خلال الجلسة الواحدة، لأن ربط الإذن بعنوان IP وMAC معاً يمنع جهازاً آخر من أن يأخذ العنوان نفسه ويمر.

RADIUS: القرار والسجل في مكان واحد

عندما يكون لديك فرع واحد ونقطة وصول واحدة تستطيع البوابة أن تقرر وحدها، ولكن عندما يكون لديك عشرون فرعاً، أو تريد أن يكون للضيف حساب واحد في كل الفروع، أو تريد سجلاً واحداً لكل الجلسات، فأنت تحتاج سيرفراً مركزياً يجيب عن ثلاثة أسئلة: من هذا؟ وماذا يسمح له؟ وماذا فعل؟ وهذه هي AAA، أي Authentication وAuthorization وAccounting، والبروتوكول المستخدم في كل أجهزة الشبكات هو RADIUS، وأشهر سيرفر مفتوح له هو FreeRADIUS.

• التحقق والقرار في RFC 2865: في RFC 2865 يرسل جهاز الشبكة، ويسمى في RADIUS باسم NAS أي Network Access Server، طلب Access-Request إلى المنفذ 1812 فيه اسم المستخدم وكلمة المرور وعنوان الجهاز، فيرد السيرفر بـ Access-Accept أو Access-Reject، ومع القبول خصائص Attributes منها مدة الجلسة Session-Timeout برقم 27، ومدة الخمول Idle-Timeout برقم 28.
• المحاسبة في RFC 2866: في RFC 2866 يرسل جهاز الشبكة إلى المنفذ 1813 سجلات Start وInterim-Update وStop، وفيها Acct-Session-Time وAcct-Input-Octets وAcct-Output-Octets وسبب الانتهاء Acct-Terminate-Cause.
• قطع الجلسة عن بعد في RFC 5176: في RFC 5176 يستطيع السيرفر أن يرسل إلى جهاز الشبكة على المنفذ 3799 طلب Disconnect-Request لقطع جلسة، أو CoA-Request لتغيير حدودها وهي تعمل، مثل رفع السرعة لمن دفع، فيرد الجهاز بـ ACK أو NAK.

وقد يتساءل البعض: كيف يتحقق RADIUS من رمز وصل عبر SMS؟ والإجابة أن البوابة عندما ترسل الرمز تكتبه في قاعدة بيانات RADIUS على أنه كلمة مرور مؤقتة لهذا الرقم، ثم عندما يكتبه الضيف ترسله في Access-Request كأي كلمة مرور، وبعد القبول تحذفه، وهذا بالضبط ما نفعله في التجربة العملية. وفي يوليو 2024 نشر باحثون من جامعة كاليفورنيا سان دييغو هجوماً اسمه BlastRADIUS برقم CVE-2024-3596 يستغل ضعف MD5 في تصميم RADIUS نفسه، ويذكر فريق FreeRADIUS أن العيب في البروتوكول وليس في منتج معين، وأن العلاج الذي اعتمده المصنعون هو إلزام الحقل Message-Authenticator، لذلك فعل هذا الإلزام في السيرفر وفي أجهزة الشبكة، وأبق RADIUS في شبكة إدارة لا يصل إليها الضيوف.

وسجل المحاسبة فيه أرقام جوالات الضيوف وأوقاتهم، فهو سجل بيانات شخصية يحتاج مدة احتفاظ وصلاحيات قراءة، كما شرحنا في قسم الخصوصية في مقال سجل التدقيق.

عزل الضيوف عن بعضهم وعن شبكتك

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

• شبكة ضيوف مستقلة Guest VLAN: الضيوف في شبكة منفصلة في الطبقة الثانية بعنوان شبكة مستقل، والجدار يسمح لهم بالإنترنت فقط، وقد شرحنا الفكرة في مقال تقسيم الشبكة، والإعداد على MikroTik في شبكة الضيوف على الراوتر، وحجم الشبكة يحسب كما في مقال الشبكات الفرعية، فالمطار يحتاج /22 أو أكبر وليس /24.
• عزل الأجهزة Client Isolation: نقطة الوصول نفسها تمنع الأجهزة المتصلة بها من أن تتحدث مع بعضها مباشرة، وفي OpenWrt هو الخيار isolate في إعداد الشبكة اللاسلكية، والذي يتحول كما في كود إعداد hostapd في OpenWrt إلى ap_isolate. ولاحظ أن العزل في نقطة وصول واحدة لا يمنع ضيفين على نقطتي وصول مختلفتين في ال VLAN نفسه، فهنا تحتاج قاعدة في الجدار أو خاصية عزل في ال Switch.
• التشفير دون كلمة مرور Enhanced Open: في الشبكة المفتوحة التقليدية كل ما يرسله الضيف يمكن أن يلتقطه من يجلس بجانبه بهوائي، والحل هو Wi-Fi Enhanced Open المبني على التشفير الانتهازي OWE في RFC 8110، حيث يتفق الهاتف ونقطة الوصول على مفتاح لكل جهاز دون أن يكتب الضيف أي كلمة مرور. وهو تشفير دون تحقق من هوية الشبكة، فلا يحمي من نقطة وصول مزيفة بالاسم نفسه، ولكنه أفضل بكثير من لا شيء، ويعمل مع البوابة دون أي تغيير.

ماذا يطلب النظام في المملكة؟

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

• تنظيمات تقديم خدمات الإنترنت ISP (الإصدار الثالث، فبراير 2024) تطلب من حامل تصريح تقديم خدمة الإنترنت أن يحفظ بيانات حسابات المشتركين لمدة سنة على الأقل، وأن يحافظ على سرية بياناتهم، وهي موجهة إلى مقدمي الخدمة المرخصين وليس إلى المقهى الذي يشترك عند أحدهم.
• تنظيمات الرسائل القصيرة التي ذكرناها في قسم SMS، وهي تحكم مزود الرسائل الذي تتعامل معه.
• وثيقة المبادئ العامة لحماية البيانات الشخصية في قطاع الاتصالات وتقنية المعلومات، وهي موجهة كذلك إلى مقدمي الخدمات في القطاع.

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

الأدوات المتاحة

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

وفيما يلي كل واحدة باختصار:

• OPNsense: نقاط القوة أنها جدار ناري كامل يدير الشبكات والبوابة معاً، وفيها مناطق Zones متعددة، ومدير قسائم يصدر ملف CSV للطباعة، ومهلة خمول ومهلة إجبارية، ودعم IPv6، والطريقة الحديثة بالخيار 114، وواجهة REST. ونقاط الضعف أنها لا ترسل SMS بنفسها، فطريقة الرمز تمر عبر RADIUS الذي تملؤه خدمتك، كما في تجربتنا.
• pfSense CE: نقاط القوة مثل OPNsense تقريباً مع خيارات مفصلة للمهلة، وحد لكمية البيانات، ورصيد مرور Pass-through Credits لكل عنوان MAC، ومنع الدخول المتزامن بالقسيمة نفسها. ونقاط الضعف أنه لا يرسل رموزاً بنفسه، فالرمز يمر عبر RADIUS كما في OPNsense.
• OpenWrt مع openNDS: نقاط القوة أنه يعمل على راوتر منزلي صغير، ويدعم الكشف التقليدي والخيار 114 وواجهة RFC 8908، وفيه حدود للبيانات والسرعة لكل جهاز، وتستطيع أن تكتب صفحتك بأي لغة عبر خدمة التحقق الخارجية FAS. ونقاط الضعف أنه يحتاج من يكتب ويصون هذه الخدمة، ولا يوجد RADIUS مدمج.
• CoovaChilli: نقاط القوة أنه قديم ومجرب ومبني على فكرة الإحالة إلى بوابة خارجية UAM مع RADIUS، ونقاط الضعف أنه يحتاج سيرفر بوابة وRADIUS منفصلين، ونشاط تطويره محدود.
• FreeRADIUS: نقاط القوة أنه المعيار الفعلي لـ RADIUS المفتوح ويعمل مع كل ما سبق، ونقاط الضعف أن إعداده بالملفات يحتاج صبراً في البداية.
• PacketFence: نقاط القوة أنه نظام متكامل للتحكم بالوصول فيه بوابة ضيوف وتسجيل أجهزة وموافقة المضيف وفصل الأجهزة في VLAN حسب الحالة، ونقاط الضعف أنه أكبر بكثير مما يحتاجه مقهى، ومكانه الطبيعي شبكة شركة.
• MikroTik HotSpot: نقاط القوة أنه مدمج في الراوتر الذي قد تملكه، ويدعم RADIUS والحديقة المسورة وملفات تعريف للسرعة والمدة، ونقاط الضعف أن RouterOS مغلق المصدر، وأن عدد مستخدمي HotSpot محدود بمستوى الترخيص كما في جدول تراخيص RouterOS.

وفي الأنظمة التجارية، تعطي أنظمة إدارة نقاط الوصول المركزية بوابة ضيوف جاهزة، مثل UniFi Hotspot Portal الذي يذكر توثيقه الدخول بحساب Facebook أو بكلمة مرور أو بالدفع عبر Stripe أو بالقسائم أو عبر RADIUS أو عبر بوابة خارجية، وفي المؤسسات الكبيرة أنظمة مثل Aruba ClearPass من HPE التي تجمع بوابة الضيوف مع التحكم بالوصول. وهي مناسبة إذا كانت نقاط الوصول من الشركة نفسها، ولكنك تربط البوابة بمنتج واحد.

ولإرسال الرموز تحتاج مزود رسائل محلي مرخص كما ذكرنا، أو WhatsApp Cloud API من Meta مباشرة أو عبر أحد مزودي الحلول المعتمدين.

أي حل يناسب مكانك؟

الجدول التالي ليس قاعدة، ولكنه نقطة بداية تختصر ما سبق حسب المكان:

أخطاء شائعة

• السماح لعناوين الفحص قبل الدخول: فيظن الهاتف أن الإنترنت متاح ولا تظهر البوابة أبداً.
• إسقاط HTTPS بصمت: فينتظر المتصفح والتطبيقات حتى تنتهي المهلة، والأفضل رفض فوري بـ TCP Reset.
• صفحة البوابة عبر HTTP أو بشهادة ذاتية التوقيع: فيظهر تحذير للضيف وهو يكتب رقمه، ولا تعمل الطريقة الحديثة مع أجهزة Apple.
• الخيار 114 يشير إلى صفحة HTML: الرابط يجب أن يشير إلى الواجهة البرمجية التي ترد بـ JSON، وليس إلى صفحة الدخول نفسها.
• جلسة أطول من عقد DHCP: يذكر توثيق pfSense أن مدة الجلسة يجب أن تكون أقل من مدة عقد DHCP، وإلا فقد يأخذ جهاز جديد عنوان جهاز غادر وجلسته ما زالت مفتوحة، فيمر دون دخول إذا كان الإذن بعنوان IP وحده، فإذا جعلت الجلسة 24 ساعة فاجعل العقد أطول منها.
• جلسة أقصر من الزيارة: فتنتهي الجلسة والضيف جالس، ولا تظهر البوابة لأن الهاتف لا يعيد الفحص، فيظن أن الشبكة معطلة.
• رمز بلا حدود: لا مهلة ولا حد لكل رقم ولا قائمة دول، فتصلك فاتورة رسائل لم يطلبها أحد.
• الضيوف في شبكة الموظفين: البوابة فوق شبكة مسطحة تحمي الإنترنت منك، ولا تحمي شبكتك من الضيف.
• سجلات بلا مدة احتفاظ: أرقام الضيوف تبقى سنوات في قاعدة بيانات لا يعرف أحد من يقرؤها.

قائمة التحقق

1. شبكة ضيوف في VLAN مستقل، وحجمها يكفي أكبر عدد متوقع من الأجهزة، والجدار يسمح لها بالإنترنت فقط.
2. عزل الأجهزة في نقاط الوصول، وEnhanced Open إذا كانت الأجهزة تدعمه.
3. الحديقة المسورة: DNS وصفحة البوابة وما تحتاجه طريقة التحقق فقط، ولا تشمل عناوين الفحص.
4. اعتراض المنفذ 80 إلى البوابة، ورفض فوري لما عداه قبل الدخول.
5. صفحة البوابة على HTTPS باسم حقيقي وشهادة تتجدد تلقائياً، والخيار 114 يشير إلى API يعمل.
6. الرمز: ست خانات عشوائية، وعمر قصير، وحد للمحاولات، ومهلة وحدود لكل رقم وجهاز، وقائمة دول.
7. مدة جلسة تناسب المكان، ومهلة خمول، وحد سرعة لكل جهاز.
8. RADIUS في شبكة إدارة، مع إلزام Message-Authenticator، والمحاسبة مفعلة.
9. نص واضح في صفحة البوابة عن الغرض من جمع الرقم ومدة الاحتفاظ، وحذف تلقائي عند انتهائها.
10. مزود رسائل مرخص، ومراقبة نسبة الإرسال إلى التحقق.

الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

• بوابة الدخول وسيلة تحكم بالوصول وتسجيل، تحجز الجهاز حتى يثبت شيئاً، ثم تعطيه جلسة لها بداية ونهاية وسجل، وهي لا تشفر شيئاً بنفسها.
• الهواتف تكتشف البوابة بطلب عنوان HTTP معروف: generate_204 في Android، وcaptive.apple.com في Apple، وconnecttest.txt في Windows.
• البوابة لا تستطيع تحويل HTTPS دون خطأ في الشهادة، وHSTS يمنع تجاوزه، لذلك تعترض HTTP فقط وترفض الباقي فوراً.
• الطريقة الحديثة أن تعلن الشبكة رابط ال API عبر الخيار 114 في DHCPv4 أو 103 في DHCPv6 أو 37 في RA، وأن يرد ال API بـ application/captive+json عبر HTTPS، مع إبقاء الاعتراض القديم للأجهزة الأقدم.
• اختر التحقق حسب ما تريد أن تعرفه: الموافقة لا تثبت شيئاً، والرمز يثبت حيازة الرقم، ورقم الغرفة يثبت الإقامة، وموافقة المضيف تعطي مسؤولاً معروفاً.
• رمز WhatsApp يستخدم قوالب تحقق بنص ثابت، ويحاسب على كل رسالة تصل منذ يوليو 2025، ورسائل SMS في المملكة عبر مزود مرخص من الهيئة.
• ضخ الرسائل أخطر على فاتورتك من تخمين الرمز، والحماية قائمة دول وحدود لكل رقم وجهاز ومراقبة النسبة.
• عنوان MAC العشوائي يجعل الضيف يسجل الدخول من جديد أحياناً، فلا تبن الهوية عليه.
• لم نجد في أنظمة CST المنشورة وثيقة خاصة بهوية مستخدمي Wi-Fi العام ومدة سجلاتهم، فاسأل مزودك وجهة ترخيصك، وطبق PDPL على أرقام الضيوف في كل الأحوال.

وفي المقال المرافق نبني هذا كله بأنفسنا في Containers، من DHCP بالخيار 114 إلى سجل RADIUS، ثم ننقله إلى راوتر حقيقي:

دليلبناء بوابة دخول Wi-Fi برمز تحقق: تجربة عملية كاملةنبني بوابة دخول تعمل فعلاً برمز تحقق وجلسة محدودة المدة وسجل لكل اتصال، ثم ننقلها إلى راوتر حقيقي.دليلMikroTik في الواقع: سيناريوهات عملية للبيت والمكتبكيف تبني على RouterOS ما تحتاجه فعلاً في البيت والمكتب، من شبكة ضيوف معزولة إلى الوصول الآمن من الخارج عبر WireGuard.دليلتقسيم الشبكة Network Segmentation بال VLAN وال VPCلماذا تصل كاميرا مخترقة إلى قاعدة بياناتك، وكيف تمنع ذلك بتقسيم الشبكة إلى مناطق لا يمر بينها إلا ما تسمح به.دليلHSTS وCSP: ترويسات الأمان التي يحتاجها كل تطبيقما الذي تطلبه كل ترويسة أمان من المتصفح، ولماذا يصعب التراجع عن HSTS، وكيف تبني سياسة CSP لا تكسر تطبيقك.دليلالدخول دون كلمة مرور: شرح Passkeys وWebAuthnلماذا لا تحميك رموز SMS وTOTP من التصيد الحديث، وكيف تحل Passkeys المشكلة بمفتاح خاص لا يغادر جهازك.دليلAudit Trail: كيف تبني سجل تدقيق لا يقبل العبثكيف تصمم سجلاً يجيب عن سؤال من غير هذه الصلاحية ومتى، وتحميه من الحذف والتعديل بعد كتابته.

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

• أكتوبر 2026: كتابة المقال، ومراجعة RFC 8910 وRFC 8908 وRFC 8952 وRFC 2865 وRFC 2866 وRFC 5176 وRFC 8110، ووثائق Android وApple وMicrosoft عن كشف البوابة وعنوان MAC العشوائي، ووثائق Meta عن قوالب التحقق والأسعار، وNIST SP 800-63B-4، وتنظيمات CST للإنترنت والرسائل القصيرة، وتوثيق OPNsense وpfSense وopenNDS وMikroTik وUniFi، وطلب عناوين الفحص الثلاثة بالأمر curl 8.12.1.