سنونو ساس: التنصيب والربط بـ MikroTik — وثلاثة أعطال حقيقية

‏Snono SAS4 هو نظام محاسبة المشتركين الأوسع انتشاراً في السوق العراقي: المشتركون والباقات والفواتير والكروت والوكلاء والتقارير في لوحة واحدة، وخادم راديوس يقف خلفها ويقرّر من يدخل ومن لا يدخل.

سننصّبه على بروكسموكس، ونربطه ببرّاس MikroTik، ثم — وهو الأهم — نعرض كل عطل قابلناه فعلاً في الطريق وكيف شخّصناه. لأن الربط ينجح من أول مرّة عند قليلين، والفرق بين من يحلّه في عشر دقائق ومن يقضي ليلته هو معرفة أين ينظر.

ما الذي تراه حين يعمل

الخطوة 1: الجهاز والموارد

والقرص يكبر مع السجلات لا مع عدد المشتركين — جداول المحاسبة والجلسات هي التي تتضخّم. خطّط لتقليمها من الشهر الأول.

qm clone <القالب> 7201 --name sas --full 1
qm set 7201 --cores 2 --memory 2048 --net0 virtio,bridge=vmbr2 \
    --ipconfig0 ip=10.10.10.90/24,gw=10.10.10.1 --nameserver 1.1.1.1
qm start 7201

الخطوة 2: الترخيص

النظام لا يعمل بلا ترخيص فعّال، والترخيص مرتبط بمعرّف عتاد يتولّد من الجهاز:

الخطوة 3: عرّف البرّاس في النظام

هذه أول خطوة ربط: النظام لا يجيب راوتراً لا يعرفه.

الحقول التي تهمّ فعلاً:

الخطوة 4: الباقات والمشتركون

الباقة تحدّد السرعة والمدة والسعر، والمشترك يُربط بباقة. وحدّ السرعة يُرسَل من النظام مع كل قبول، فلا تضعه على الراوتر إطلاقاً.

الخطوة 5: الربط الفعلي — وثلاثة أعطال متتابعة

هنا الجزء الذي لا تجده في أي شرح. وصلنا البرّاس بالنظام، فلم يعمل. وكل عطل كان يبدو كسابقه ويحتاج علاجاً مختلفاً:

العطل الأول: radius timeout

البرّاس يرسل ولا يأتيه جواب. والسبب الذي يضيّع ساعات:

systemctl restart freeradius

والأداة التي تحسم هذا العطل في ثانيتين هي مراقبة الحزم على خادم النظام:

tcpdump -ni any udp port 1812

إن رأيت Access-Request يصل ولا جواب يخرج، فالمشكلة عند النظام لا في الشبكة. وإن لم يصل شيء أصلاً، فالمشكلة في الطريق أو الجدار.

العطل الثاني: Access-Reject

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

وهنا يفيد تشغيل الراديوس بوضع التشخيص، فيطبع سبب الرفض حرفياً:

systemctl stop freeradius
radiusd -X | tee /tmp/radius-debug.log

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

العطل الثالث: قبول من النظام ورفض عند الراوتر

وهذا أخبثها. سجلّ النظام يقول Access-Accept و«تمّت المصادقة بنجاح»، وجهاز المشترك يقول failed to authenticate. الاثنان صادقان — ونشرحه في القسم التالي لأنه يستحقّ عنواناً مستقلاً.

‏⭐ السطر الذي يوقف كل مزوّد اليوم

/radius set [find] require-message-auth=no

‏⭐ فخّ ثانٍ: زرّ الحفظ الذي لا يحفظ

في النسخة التي اختبرناها كان الضغط على Submit في نموذج إضافة راوتر لا يفعل شيئاً — ولا رسالة خطأ. وبفحص الطلب تبيّن أن الخادم يردّ 405 Method Not Allowed: الواجهة الأمامية والخلفية من إصدارين مختلفين، فالواجهة ترسل بطريقة لا تقبلها الخلفية.

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

ترتيب التشخيص الذي يوفّر عليك الليل

خمسة أسئلة بالترتيب — ولا تنتقل إلى التالي قبل أن يكون جواب سابقه نعم. هذا وحده يختصر أغلب ليالي المزوّدين.

أخطاء شائعة وحلولها

أسئلة شائعة

هل أحتاج ترخيصاً لأجرّب؟

نعم للاستعمال الفعلي. والطريقة المعقولة: احصل على ترخيص بحدّ مشتركين صغير، وارفعه حين تكبر.

هل يعمل مع أكثر من برّاس؟

نعم — أضف كل برّاس كراوتر مستقلّ بسرّ مختلف. والسرّ المختلف ليس تزيّداً: تسريب سرّ برج لا يجب أن يفتح بقية الشبكة.

كيف أنقله إلى سيرفر آخر؟

نسخة قاعدة البيانات + إعادة تفعيل الترخيص على المعرّف الجديد. تواصل مع المزوّد قبل النقل، لا بعده والنظام متوقّف.

وهل أستطيع ربطه بنظام الفوترة عندي؟

عبر واجهته البرمجية، نعم. وفي أغلب الحالات يكفي أن تستعمل فوترته الداخلية بدل بناء تكامل تصونه إلى الأبد.

ما أهم شيء أفعله بعد التنصيب مباشرةً؟

نسخة احتياطية مجدولة لقاعدة البيانات — واختبر استرجاعها. فقدان قاعدة المشتركين يعني فقدان شركتك، لا فقدان خادم. وشرحنا الإجراء في مقالة النسخ والاسترجاع.

الخطوة التالية

عندك الآن نظام يعمل. لكن هل هو الأنسب لك؟ في الجزء الرابع نجرّب نظاماً منافساً على نفس البرّاس ونقارن بصراحة — بلا مجاملة لأحد.