توجيه كل الترافيك عبر WireGuard على MikroTik دون كسر الاتصال

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

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

سنفترض أن النفق قائم أصلاً، وأن الواجهة اسمها wg0، وأن عنوان السيرفر 203.0.113.10، وبوابة خط الإنترنت 198.51.100.1، وشبكة المكتب 192.168.88.0/24.

المعادلة في جملة واحدة

يختار الراوتر المسار الأدق أولاً، ثم الأقل distance عند تساوي الدقة. ومن هاتين القاعدتين يأتي الحل كله:

• مسار /32 لعنوان السيرفر عبر خط الإنترنت، وهو أدق من أي مسار افتراضي، فيبقى النفق حياً.
• مسار افتراضي عبر wg0 بقيمة distance صغيرة.
• مسار افتراضي عبر خط الإنترنت بقيمة distance أكبر، فيبقى احتياطاً.

تنبيه مهم: عند تساوي distance بين مسارين افتراضيين، يوزّع RouterOS الترافيك بينهما بطريقة ECMP، وهذا ليس ما تريده هنا. فلا تترك القيمتين متساويتين.

الخطوة الأولى: مسار السيرفر قبل كل شيء

هذا هو الأمر الذي ينقذك، فنفّذه أولاً دائماً:

/ip route add dst-address=203.0.113.10/32 gateway=198.51.100.1 \
    comment="wg-server-via-wan"

إن كان خطك PPPoE فيمكنك استعمال اسم الواجهة بصفته بوابة، مثل gateway=pppoe-out1، فلا يهمك تغيّر العنوان. أما إن كان خطك DHCP وبوابته تتغير، فراقب هذا المسار، لأن البوابة القديمة ستتركه معطلاً.

الخطوة الثانية: رفع distance لخط الإنترنت

المسار الافتراضي يأتي غالباً من عميل DHCP أو PPPoE بقيمة distance تساوي 1. ارفعها كي يأخذ النفق الأولوية:

# إن كان الخط DHCP
/ip dhcp-client set [find interface=ether1] default-route-distance=10

# إن كان الخط PPPoE
/interface pppoe-client set pppoe-out1 default-route-distance=10

# ثم أضف مسار النفق
/ip route add dst-address=0.0.0.0/0 gateway=wg0 distance=1 \
    comment="default-via-wg"

افتح جلسة Safe Mode قبل هذه الخطوة بضغط Ctrl+X في الطرفية. فإن انقطع اتصالك بالراوتر، أُلغيت التغييرات تلقائياً. وهي عادة صغيرة قد توفر عليك رحلة إلى الموقع.

الخطوة الثالثة: السماح بالعبور والعنونة

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

أبسط تطبيق للطريقة الأولى أن تضيف الواجهة إلى قائمة WAN، إن كان إعدادك الافتراضي يستعمل هذه القائمة في قاعدة masquerade:

/interface list member add list=WAN interface=wg0

ثم تحقق من أن على السيرفر قاعدة NAT تخرج ترافيك 10.66.66.0/24 إلى الإنترنت، وأن net.ipv4.ip_forward=1 مفعّل، وأن allowed-address على الراوتر أصبح 0.0.0.0/0:

/interface wireguard peers set [find interface=wg0] allowed-address=0.0.0.0/0

بديل أنظف: توجيه شبكة المكتب فقط

أحياناً لا تريد إدخال ترافيك الراوتر نفسه في النفق. هنا تفيد جداول التوجيه في RouterOS v7، فتبقى المسارات الرئيسية كما هي، ولا تحتاج إلى مسار /32:

/routing table add name=via-wg fib
/ip route add dst-address=0.0.0.0/0 gateway=wg0 routing-table=via-wg

/routing rule add dst-address=192.168.88.0/24 action=lookup table=main
/routing rule add src-address=192.168.88.0/24 action=lookup table=via-wg

القاعدة الأولى تبقي الترافيك الداخلي داخل الشبكة، والثانية ترسل الباقي عبر النفق. ولأن action=lookup يكمل البحث إن لم يجد مساراً فعالاً، فسيعود الترافيك إلى الجدول الرئيسي إذا تعطلت الواجهة. أما إن أردت منع الخروج خارج النفق نهائياً، فاستعمل lookup-only-in-table، ثم اختبر النتيجة.

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

التحقق من أن كل شيء سليم

/ip route print where dst-address=0.0.0.0/0
/ip route print where dst-address=203.0.113.10/32
/interface wireguard peers print detail
/ping 10.66.66.1 count=10

ابحث عن ثلاثة أمور: مسار النفق فعال، ومسار السيرفر يمر عبر الخط، وlast-handshake حديث. ثم افتح من جهاز في المكتب صفحة تعرض عنوانك العام، فيجب أن ترى عنوان السيرفر. وهذا ما تحققنا منه في تجربتنا على RouterOS 7.25: مصافحة ناجحة، وفقد 0%، وخروج من عنوان السيرفر. ولم نقس سرعة MikroTik في تلك التجربة.

ولا تنس IPv6. فإن كان خطك يعطي عناوين IPv6، فقد يخرج جزء من الترافيك خارج النفق دون أن تلاحظ. إما أن تدخله في النفق بإضافة ::/0، وإما أن تعطله عن الأجهزة بقرار واعٍ.

كم يكلفك هذا في الأداء؟

كل ترافيك المكتب سيمر الآن بنقطتين: الراوتر والسيرفر. فاختيار السيرفر يؤثر في تجربة الجميع. وقرب السيرفر وحده لا يكفي، فالعتاد الضعيف يضيف انتظاراً تحت الحمل حتى لو كانت المسافة قصيرة.

على أحد سيرفراتنا كان WireGuard داخل VM بأربع أنوية يملك قدرة تشفير داخلية نحو 1.7Gbps، بينما بلغ التنزيل عبر النفق 57MB/s على منفذ محدود بـ480Mbps. هذا قياس سيرفر، وليس وعداً لراوترك، فقس على جهازك.

أخطاء تعيدك إلى نقطة البداية

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

• إضافة مسار النفق قبل مسار السيرفر: تسقط المصافحة فوراً، ويتوقف الإنترنت معها.
• مسار السيرفر بعنوان قديم: إن تغير عنوان السيرفر ولم تعدل المسار، فسيدخل النفق في نفسه.
• نسيان NAT على السيرفر: تنجح المصافحة ويعمل ping إلى النفق، ولا يخرج شيء إلى الإنترنت.
• نسيان DNS: تعمل العناوين الرقمية ولا تعمل النطاقات، إن كان خادم الأسماء لا يُصل إليه عبر النفق.
• مسار إدارة مفقود: إن كنت تدير الراوتر من خارج شبكته، فأبقِ لنفسك طريقاً ثابتاً، أو استعمل الطرفية من الموقع.

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

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

الخلاصة

الترتيب هو كل القصة: مسار السيرفر أولاً، ثم distance الخط، ثم مسار النفق، ثم NAT والتحقق. احترم هذا الترتيب، ولن ينقطع عنك الراوتر.

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