مسار احتياطي على MikroTik عند سقوط نفق WireGuard أو الخط

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

هذا المقال يبني مساراً احتياطياً على MikroTik بأوامر RouterOS v7، ويغطي حالتين: سقوط النفق، وسقوط خط الإنترنت. ويوضح أيضاً متى يكون الانتقال التلقائي قراراً خاطئاً.

لماذا لا يكفي مسار بقيمة distance أعلى؟

المسار الاحتياطي البسيط يعمل حين تسقط الواجهة فعلاً. لكن واجهة WireGuard قد تبقى في حالة running حتى لو كان السيرفر معطلاً، لأن البروتوكول بلا جلسة دائمة بالمعنى التقليدي. فيبقى المسار فعالاً، ويرسل الراوتر الترافيك إلى لا مكان.

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

التصميم الذي سنبنيه

عندنا نفق إلى السيرفر 203.0.113.10 وعنوان السيرفر داخله 10.66.66.1، وخطان: الأول ببوابة 198.51.100.1 والثاني ببوابة 192.0.2.1. نريد هذا الترتيب: النفق أولاً، ثم الخط الأول، ثم الخط الثاني.

الجزء الأول: مسار النفق بفحص حقيقي

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

/ip route
add dst-address=0.0.0.0/0 gateway=10.66.66.1 distance=1 \
    check-gateway=ping comment="default-tunnel"
add dst-address=0.0.0.0/0 gateway=198.51.100.1 distance=5 \
    check-gateway=ping comment="default-wan1"
add dst-address=0.0.0.0/0 gateway=192.0.2.1 distance=10 \
    comment="default-wan2"

افتراضياً يرسل الراوتر فحصاً كل 10 ثوانٍ، ويعدّ البوابة ساقطة بعد انقضاء مهلتين متتاليتين. أي أن الانتقال ليس فورياً، ويستغرق ثوانيَ عدة. ويمكن ضبط هذه القيم في قائمة /routing settings بالإصدارات الحديثة.

تأكد أن السيرفر يرد على ping من عنوان النفق، وإلا سيحكم الراوتر بأن النفق ساقط وهو سليم. وعدّل مسارات خطوطك الحالية إن كانت تأتي من DHCP أو PPPoE، باستعمال default-route-distance بدل إضافة مسارات يدوية مكررة.

الجزء الثاني: حماية طريق النفق نفسه

هذه النقطة ينساها كثيرون. مسار السيرفر /32 يمر عبر الخط الأول. فإن سقط الخط الأول، يجب أن يجد النفق طريقه عبر الخط الثاني، وإلا فقدت النفق رغم وجود خط سليم.

/ip route
add dst-address=203.0.113.10/32 gateway=198.51.100.1 distance=1 \
    check-gateway=ping comment="wg-server-wan1"
add dst-address=203.0.113.10/32 gateway=192.0.2.1 distance=2 \
    comment="wg-server-wan2"

وهنا فخ آخر. نفق WireGuard يستعمل UDP، والراوتر يسجل الاتصال في connection tracking مع عنوان NAT القديم. فبعد الانتقال قد يستمر الترافيك باستعمال السجل القديم، فلا يعود النفق. والحل مسح السجل عند تغير الحالة:

/tool netwatch add host=10.66.66.1 type=icmp interval=10s \
    down-script=":log warning \"wg down\"; /ip firewall connection remove [find dst-address~\"203.0.113.10\"]" \
    up-script=":log info \"wg up\""

نفّذ هذا السكربت في تجربة مجدولة، وراقب سجل الراوتر بعدها. فـNetwatch يعمل بصلاحيات محدودة، وتكفيه هنا صلاحيتا القراءة والكتابة.

الجزء الثالث: كشف انقطاع ما بعد البوابة

فحص البوابة يبقى ناجحاً حتى لو انقطع المزود خلفها. فاستعمل مساراً recursive يفحص هدفاً أبعد. استبدل مسار default-wan1 السابق بهذا، و203.0.113.20 مثال لهدف ثابت تثق به:

/ip route
add dst-address=203.0.113.20/32 gateway=198.51.100.1 scope=10 \
    comment="probe-via-wan1"
add dst-address=0.0.0.0/0 gateway=203.0.113.20 target-scope=11 \
    distance=5 check-gateway=ping comment="default-wan1-recursive"

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

متى لا تريد انتقالاً تلقائياً؟

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

• استمرارية أولاً: اسمح بالانتقال إلى الخط مباشرة، كما في الأمثلة.
• سرية أولاً: أوقف الانتقال، وضع الأنظمة الحساسة خلف قواعد لا تخرج إلا عبر النفق.
• حل وسط: سيرفر نفق ثانٍ بدل الخروج المباشر، فتبقى الحماية عند سقوط السيرفر الأول.

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

اختبر قبل أن يختبرك العطل

لا تعتمد إعداداً لم تجرّب سقوطه. جرّب في وقت هادئ، ولا تجرّب من بعيد دون طريق بديل إلى الراوتر.

1. أوقف WireGuard على السيرفر، وراقب انتقال المسار.
2. أعده، وتأكد من رجوع الترافيك إلى النفق.
3. افصل كابل الخط الأول، وتأكد من قيام النفق عبر الخط الثاني.
4. افصل الخدمة عند المودم مع بقاء المنفذ مضاءً، إن أمكن.
5. سجّل زمن الانتقال الفعلي عندك، فهو رقمك الحقيقي.

/ip route print where dst-address=0.0.0.0/0
/ip route print detail where comment~"default"
/log print where message~"wg"

ماذا يلاحظ المستخدم عند الانتقال؟

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

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

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

وأخيراً، راجع قواعد جدارك بعد إضافة أي خط. فالقاعدة التي تذكر ether1 وحده لن تحمي الخط الثاني، لذا ضع الخطين معاً في قائمة WAN، واجعل masquerade يعمل عليها.

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

الخلاصة

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

وإن كنت تخطط لسيرفر نفق ثانٍ أو طرف ثابت لأعمال لا تحتمل التوقف، فسيرفرات مرام تساعدك على بناء ذلك بما يناسب حمل شبكتك. وتتوفر لدينا خيارات منافذ بسرعات أعلى تصل إلى 100 جيجابت حسب التوفر والموقع، ونؤكد التفاصيل قبل الطلب.