إدارة عرض النطاق في MikroTik: الطوابير

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

ما هي إدارة عرض النطاق في MikroTik?

إدارة عرض النطاق في MikroTik هي استخدام طوابير RouterOS للتحكم في مقدار ما يمكن أن يستهلكه كل عميل أو شبكة فرعية أو فئة حركة مرور من الرابط — بتحديد المعدلات، وضمان الحدود الدنيا، وتقرير من يتنازل عندما يمتلئ الرابط. ينفّذ RouterOS الطوابير عبر مجدول Hierarchical Token Bucket (HTB)، المتاح في موضعين: الطوابير البسيطة، وهي قائمة مرتّبة تُطبّق بالتسلسل، وشجرة الطوابير، وهي هرمية مرتبطة بالواجهات أو بعلامات الحزم من أداة mangle في جدار الحماية (توثيق MikroTik — الطوابير).

هذا التمييز يحدد إلى أي مدى سيتوسّع تصميمك. الطابور البسيط يجيب عن “قيّد هذا العميل عند 50 ميجابت/ث.” أما شجرة الطوابير فتجيب عن “هذا الرابط الصاعد بسعة 500 ميجابت/ث يتقاسمه 300 مشترك، وVoIP يمر أولاً، ولا يتضور أحد جوعاً، ولا يفسد المُنزِّلون الثقيلون الأمسية.” كل مزود إنترنت يحتاج في النهاية إلى الإجابة الثانية.

الخطوة 1 — تقييد عميل واحد بطابور بسيط

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

/queue simple add name=client-101 target=10.10.0.101/32 max-limit=10M/50M

يُكتب max-limit بصيغة upload/download من وجهة نظر الراوتر. تُقيَّم القواعد بالترتيب ويفوز أول تطابق — لذا فإن قاعدة عامة مبكرة تبتلع بصمت القواعد المحددة التي تضيفها لاحقاً. هذا الترتيب هو السبب الأكثر شيوعاً لتوقّف طابور “يعمل” عن العمل بعد أن يضيف أحدهم قاعدة فوقه (توثيق MikroTik — الطوابير).

تقترن الطوابير البسيطة أيضاً بمصادقة المشتركين: حقل rate-limit في ملف تعريف PPPoE ينشئ طابوراً بسيطاً ديناميكياً لكل جلسة، فتتبع الخطط المستخدم بدلاً من عنوان IP. يغطي دليل خادم PPPoE لـ MikroTik لمزودي الإنترنت جانب ملف التعريف.

الخطوة 2 — تعليم حركة المرور عبر mangle في جدار الحماية

لا تستطيع شجرة الطوابير أن ترى “VoIP” أو “العميل 101”؛ بل ترى علامات الحزم. أنشئها في mangle، بتعليم الاتصال أولاً ثم الحزم ثانياً، وهو أرخص من إعادة فحص كل حزمة:

/ip firewall mangle
add chain=forward action=mark-connection new-connection-mark=voip-conn protocol=udp port=5060,10000-20000
add chain=forward action=mark-packet connection-mark=voip-conn new-packet-mark=voip-pkt passthrough=no

أبقِ تصنيف العلامات صغيراً وثابتاً. العلامات هي المفردات التي تتحدث بها طوابيرك، وحالما يمتلك الأسطول ثلاثة أجيال من أسماء علامات ارتجالية، لا يعود أحد يعرف أي راوتر يفرض أي سياسة. هنا يثبت تدقيق الإعدادات وسجلها في MKController جدواه: اطّلع على حالة mangle والطوابير لكل راوتر، وقارنها بالسياسة المقصودة، وادفع القواعد المصححة عبر الأسطول بالكامل بدلاً من فتح ثلاثين جلسة Winbox للعثور على الجهاز الوحيد الذي لم يصله التغيير.

الخطوة 3 — بناء هرمية شجرة الطوابير

لشجرة الطوابير أب واحد يحمل السعة الحقيقية للرابط، وأبناء يقتسمونها:

/queue tree
add name=download parent=bridge-lan max-limit=500M
add name=voip parent=download packet-mark=voip-pkt limit-at=50M max-limit=100M priority=1
add name=bulk parent=download packet-mark=bulk-pkt limit-at=50M max-limit=500M priority=8

ثلاثة حقول تقوم بالعمل. limit-at هو الضمان الذي يتلقاه الابن حتى عند تشبّع الرابط. max-limit هو السقف الذي قد يبلغه عندما تكون السعة متاحة. priority — 1 هو الأعلى و8 هو الأدنى — يحدد أي ابن يحصل على الفائض أولاً، ويُطبَّق فقط بين limit-at وmax-limit (توثيق MikroTik — الطوابير). اضبط max-limit الأب على ما يقدّمه الرابط فعلياً، لا على ما ينص عليه العقد، وإلا لن يصبح الطابور أبداً عنق الزجاجة ولن يشكّل شيئاً.

الخطوة 4 — إضافة PCQ للتقاسم العادل

Per Connection Queue (PCQ) هو السبب في قدرة MikroTik على التوسع إلى أعداد مشتركين تجعل قائمة طابور لكل مستخدم غير قابلة للإدارة. نوع طابور PCQ يصنّف حركة المرور حسب حقل عنوان وينشئ طابوراً فرعياً ديناميكياً لكل قيمة مميزة، مطبّقاً نفس المعدل على كل منها (توثيق MikroTik — مثال PCQ):

/queue type
add name=pcq-down kind=pcq pcq-rate=20M pcq-classifier=dst-address
add name=pcq-up   kind=pcq pcq-rate=10M pcq-classifier=src-address

أرفق pcq-down كـ queue للابن الذي يحمل حركة تنزيل العملاء، فيحصل كل عميل على ما يصل إلى 20 ميجابت/ث، مُخصَّصة تلقائياً. اضبط pcq-rate=0 فيقسم PCQ عرض نطاق الأب بالتساوي بين كل من هو نشط — إعداد “لا يتضور أحد جوعاً” الكلاسيكي. نوع طابور واحد يحل محل مئات الإدخالات المكتوبة يدوياً.

نفس منطق التسوية ينطبق على WiFi المشترك: حد معدل الخطة وأب PCQ معاً يمنعان ضيفاً واحداً من استهلاك الرابط الصاعد للمكان — راجع دليل إعداد قسائم HotSpot لـ MikroTik لجانب بيانات الاعتماد.

الخطوة 5 — ضبط limit-at وmax-limit وburst وpriority

معظم QoS المعطوب ليس أداة خاطئة، بل أرقاماً خاطئة. أبقِ مجموع limit-at لكل الأبناء عند max-limit الأب أو دونه؛ فإذا تجاوزت الضمانات سعة الرابط، لا يستطيع HTB الوفاء بها وتتوقف الأولويات عن التصرف كما تتوقع. احجز priority=1 لحركة المرور الحساسة للكمون — VoIP والألعاب وDNS — ودع عمليات النقل الضخمة تعيش عند 8 بسقف سخي.

يستحق burst تحذيراً. burst-limit وburst-threshold وburst-time تتيح للعميل تجاوز max-limit لفترة وجيزة بينما يبقى متوسطه منخفضاً — رائع لاختبارات السرعة، وأسوأ لرابط متجاوز السعة. قِس بالأمر /queue simple print stats أو عدّادات شجرة الطوابير بينما يكون الرابط تحت الحمل، لا في الثالثة صباحاً حين يكون كل شيء خاملاً. إذا لم تكن قراءة العدّادات عند الذروة عملية، فإن عرض Internet Link في MKController يحفظ نفس الصورة باستمرار — الاستخدام مقابل السرعة المتعاقد عليها؛ والكمون كمتوسط وأقصى وP95؛ وكم ساعة أمضاها كل رابط فوق 90% — فتضبط استناداً إلى التاريخ، لا إلى لقطة محظوظة.

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

الخطوة 6 — نشر السياسة عبر الأسطول بالكامل

راوتر واحد هو إعداد؛ مئة راوتر هي عملية تشغيلية. على السياسة الآن أن تكون متطابقة على كل جهاز، وأن تنجو من الفني الذي رفع سقف عميل “مؤقتاً”، وأن تكون قابلة للاستعادة حين يُعاد تثبيت راوتر برج عبر netinstall. لا شيء في RouterOS يفعل ذلك نيابة عنك.

MKController يفعل: دفعات على مستوى الأسطول لأنواع الطوابير وملفات تعريف rate-limit وقواعد جدار الحماية؛ وسجل الإعدادات، لترى متى تغيّر حد ما وتستعيد النسخة السابقة بنقرة واحدة؛ ونسخ احتياطية تلقائية قبل أي تغيير؛ ووصول عن بُعد صادر وآمن إلى الراوترات خلف CGNAT أو على Starlink، دون عنوان IP عام ودون توجيه منافذ — وهو النهج الذي نشرحه في إدارة MikroTik عن بُعد خلف CGNAT. ومراقبة Internet Link فيه تراقب الروابط الصاعدة ذاتها التي شكّلتها للتو — الاستخدام لكل مصدر مقابل السرعة المتعاقد عليها، والكمون مع P95، والاستهلاك عند تجاوز نطاقي 75% و90% عبر ما يصل إلى أربعة مصادر WAN لكل راوتر — فيظهر رابط يزحف نحو التشبّع على لوحة التحكم، و(مقترناً بتنبيهات Telegram) في إشعاراتك، قبل أن يتصل مشترك. مزودو الإنترنت وWISP الذين يشغّلون MikroTik على نطاق واسع يستخدمونه كي تبقى سياسة عرض النطاق قراراً واحداً، لا مئة قرار.

نصائح

• شكّل على الواجهة التي تغادر منها حركة المرور الراوتر؛ فالطوابير تتحكم في الخروج، لذا تُشكَّل التنزيلات على جانب LAN والرفع على جانب WAN.
• فضّل نوع طابور PCQ واحداً على مئات الطوابير البسيطة حالما تتجاوز بضع عشرات من المشتركين.
• passthrough=no على قواعد mark-packet يوفّر اجتيازاً لا لزوم له لبقية قواعد mangle.
• خذ دائماً نسخة احتياطية قبل المساس بالطوابير على حافة إنتاجية، وغيّر متغيراً واحداً في كل مرة.

توقّف عن التخمين أين ذهب عرض نطاقك

الطوابير هي الفرق بين بيع خطة وتقديمها. الطوابير البسيطة تقيّد عميلاً، وشجر الطوابير تمنح البنية والأولوية، وPCQ يجعل العدالة تلقائية — وMKController يحوّل الثلاثة جميعاً إلى سياسة تطبّقها مرة وتفرضها في كل مكان: إدارة مركزية للأسطول، ودفعات rate-limit وجدار الحماية إلى كل راوتر، وسجل إعدادات مع استعادة بنقرة واحدة، ووصول عن بُعد دون عنوان IP عام، ومراقبة Internet Link التي تنبّه إلى رابط يتشبّع مقابل سرعته المتعاقد عليها قبل أن يفعل عملاؤك.

ابدأ تجربتك المجانية من MKController