نتيجة عميل موثقة
القطاع: الشركات الصغيرة والمتوسطة
إعادة بناء شبكة مكتب موروثة تعمل بأربعة خطوط إنترنت
- MikroTik RouterOS
- Firewall filter rules
- PCC load balancing
- PCQ queue trees
- Policy routing
- DHCP
- RouterOS scripting
مدة التنفيذ: أغسطس – سبتمبر 2026 (فترة العمل الموثقة)
نظرة عامة
كان مكتب يضم نحو 75 جهازًا يعتمد على جدار ناري وأربعة خطوط إنترنت أُعدّت قبل أن يبدأ هذا العمل. أعدنا بناء الأجزاء التي لم تكن تؤدي دورها، وأوضح مثال على ذلك قيود وُضعت على أحد أجهزة العمل ولم تمنع شيئًا، إذ لم تسجّل أيُّ قاعدة من قواعدها الاثنتي عشرة حزمة بيانات واحدة.
التحدي
بدت الشبكة مضبوطة كما ينبغي، لكن أجزاءً مهمة منها لم تكن تؤدي دورها. فالجهاز الذي كان يُفترض ألا يصل إلا إلى مواقع معتمدة لم تكن تلك القيود تُطبَّق عليه في الواقع. وكان يُفترض أن تتوزع حركة الإنترنت على الخطوط، بينما كان خط واحد يحمل 51 Mbps، وخطان آخران لا يكادان يُستخدمان. وفوق ذلك، كان على أي تغيير في طريقة توزيع الحركة أن يحافظ على جلسات الدخول إلى البنوك والبوابات الضريبية دون انقطاع.
الحل
كشفت عدادات الجدار الناري نفسها سبب فشل القيود: كل القواعد الواقعة فوق قاعدة سماح شاملة من LAN إلى WAN سجّلت حركة فعلية، بينما سجّلت القواعد الاثنتا عشرة الواقعة تحتها صفرًا تامًا. أعدنا بناء القيود في قاعدتين فوق قاعدة السماح، مقصورتين على واجهات WAN حتى يبقى الوصول الداخلي متاحًا، ونقلنا سياسة الجهاز فوق مصنِّف DHCP كان سيعيده إلى قائمة بيضاء تتجاوز القيود عند اتصاله التالي. وكان توزيع الحمل بتقنية PCC يعتمد على تجزئة عنوان المصدر على قسمين فقط، فيربط كل جهاز بأحد خطين بشكل دائم ويستبعد الخط الثالث تمامًا. فأعدنا بناءه على خمسة أقسام موزونة حسب السعة المقيسة لكل خط، بتجزئة على عنواني المصدر والوجهة معًا، مع وجود خط LTE احتياطيًا، وتثبيت الوجهات الحساسة للجلسات كالبنوك على خط واحد حتى لا تنقطع جلسات الدخول. كما أعدنا تصميم شرائح السرعة لكل جهاز عبر PCQ، وأزلنا كلمة مرور مدير مكتوبة نصًا صريحًا من سكربت على الراوتر كان تصدير الإعدادات ينسخها في كل نسخة احتياطية على وحدة التخزين الشبكية. وكان أحد الأعطال من صنعنا نحن: فسكربت قياس السرعة الليلي الخاص بنا كان يتعلّق بدلًا من أن ينتهي، فتراكمت منه أربع نسخ على مدى أربعة أيام، وظل استهلاك معالج الراوتر عند 100%، بينما أفاد الموظفون بأن الإنترنت متصل لكنه لا يعمل. أوقفنا هذه النسخ، وجعلنا المُجدول يزيل أي بقايا قبل كل تشغيل، وأضفنا آلية مراقبة تعمل كل ساعة توقف أي مهمة ما زالت تعمل منذ يوم سابق وتبلّغ عنها.
النتائج
بحسب قياسات أُخذت قبل التغييرات وبعدها وقت تنفيذ العمل: انخفض استهلاك معالج الراوتر تحت الحمل من 100% إلى نحو 50% فور إيقاف المهام العالقة، وارتفع معدل نقل البيانات من 51 Mbps على خط واحد إلى 112 Mbps أو أكثر موزعة على ثلاثة خطوط، وانخفض عدد الأجهزة الخارجة عن ضبط السرعة من 41 إلى صفر، وعاد النسخ الاحتياطي الآلي للراوتر، بعد تعطّله لأسابيع، إلى العمل ليليًا مع التحقق منه. وأبلغنا كذلك عن خطر لم نعالجه لأن معالجته تتطلب تغييرًا في العتاد: كانت وحدتا التخزين على الخادم تعملان بنظام RAID 0، أي أن تلف قرص واحد كفيل بضياع وحدة كاملة.
القياس والأدلة
قراءات مأخوذة من الأجهزة نفسها أثناء العمل: عدادات الحزم في قواعد الجدار الناري، ومحلل استهلاك المعالج وقائمة المهام الجارية على الراوتر، وحركة البيانات وعدد الاتصالات على كل خط، إلى جانب مراجعة قبل التغييرات وبعدها لمدى شمول ضبط السرعة للأجهزة ولحالة النسخ الاحتياطي الآلي للراوتر. أما سعات الخطوط التي اعتمد عليها ترجيح توزيع الحمل فقد قيست لكل خط على حدة ولم تُؤخذ من السرعات المعلنة لمزودي الخدمة. تصف كل الأرقام حالة الشبكة وقت تنفيذ العمل (أغسطس – سبتمبر 2026) لا حالتها الحالية، وهي قياسات هندسية أجريناها بأنفسنا، وليست تدقيقًا رسميًا أو شهادة امتثال أو اختبار اختراق.