ربط فرعين بـWireGuard على MikroTik خطوة بخطوة

لديك مكتب في بغداد وفرع في البصرة. موظفو الفرع يحتاجون إلى برنامج المحاسبة والطابعة وملفات المشاركة في المكتب الرئيسي، وكأن الفرعين في مبنى واحد. هذا بالضبط ما يقدمه ربط Site-to-Site عبر WireGuard بين راوترين MikroTik.

الموظف لا يثبت أي برنامج. الراوتران يتوليان الأمر، وتمر البيانات مشفرة بين الفرعين. والأوامر هنا لـRouterOS v7 فقط.

الخطة قبل الأوامر

أهم قرار هو العنونة. يجب ألا تتشابه شبكتا الفرعين، وإلا فلن يعرف الراوتر أي جهاز تقصد. ولهذا غيّر الشبكة الافتراضية 192.168.88.0/24 قبل الربط، إن كانت مستعملة في الفرعين.

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

إعداد الفرع A

/interface wireguard add name=wg-s2s listen-port=13231 mtu=1420
/ip address add address=10.66.66.1/24 interface=wg-s2s
/interface wireguard print

انسخ public-key الظاهر، ثم نفّذ الأوامر نفسها على الفرع B بعنوان 10.66.66.2/24 وانسخ مفتاحه أيضاً. بعد ذلك أضف الطرف والمسار على الفرع A:

/interface wireguard peers add interface=wg-s2s \
    public-key="<BRANCH_B_PUBLIC_KEY>" \
    allowed-address=10.66.66.2/32,192.168.20.0/24 \
    comment="branch-b"

/ip route add dst-address=192.168.20.0/24 gateway=wg-s2s

لا نكتب endpoint-address هنا، لأن الفرع B هو من يبدأ الاتصال، وقد يتغير عنوانه. والراوتر سيتعلم العنوان الحالي من الحزم الموثقة.

إعداد الفرع B

/interface wireguard peers add interface=wg-s2s \
    public-key="<BRANCH_A_PUBLIC_KEY>" \
    endpoint-address=203.0.113.10 endpoint-port=13231 \
    allowed-address=10.66.66.1/32,192.168.10.0/24 \
    persistent-keepalive=25s comment="branch-a"

/ip route add dst-address=192.168.10.0/24 gateway=wg-s2s

تذكر أن allowed-address لا يضيف مساراً في RouterOS، فالمسار اليدوي ضروري على الطرفين. ونسيانه من أكثر الأخطاء شيوعاً: تنجح المصافحة، ولا يعبر شيء بين الشبكتين.

جدار الحماية والـNAT

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

/ip firewall filter add chain=input protocol=udp dst-port=13231 \
    action=accept comment="allow-wg-s2s" place-before=0

ثم اسمح بالعبور بين الشبكتين. وهذه الأوامر للفرع A، وعلى الفرع B اعكس العناوين:

/ip firewall filter
add chain=forward src-address=192.168.10.0/24 dst-address=192.168.20.0/24 \
    action=accept comment="s2s-a-to-b" place-before=0
add chain=forward src-address=192.168.20.0/24 dst-address=192.168.10.0/24 \
    action=accept comment="s2s-b-to-a" place-before=0

أما NAT، فلا تضع masquerade على واجهة النفق في هذا التصميم. فأنت تريد أن يرى كل فرع عناوين الأجهزة الأصلية. وقاعدة الخروج الافتراضية مرتبطة بقائمة WAN، وwg-s2s ليست فيها، فلا حاجة لاستثناء. لكن إن كانت لديك قاعدة masquerade عامة بلا واجهة، فاحذر أن تطبّق على ترافيك الفروع.

ويمكنك تضييق القواعد لاحقاً بحسب الخدمات. فالسماح بمنفذ قاعدة البيانات لجهاز واحد أفضل من فتح الشبكة كلها. وإن كان ترافيك الفرع يتعلق، فأضف ضبط MSS على wg-s2s.

الاختبار من الجهة الصحيحة

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

/interface wireguard peers print detail
/ping 192.168.20.1 src-address=192.168.10.1 count=10
/tool traceroute 192.168.20.1 src-address=192.168.10.1 count=1

ثم انتقل إلى جهاز حقيقي: افتح مشاركة ملفات من الفرع الآخر، أو اتصل بقاعدة البيانات. وتذكر أن جدار ويندوز يرفض كثيراً من الاتصالات القادمة من شبكة أخرى، حتى لو كان النفق سليماً. فمشكلة «ping لا يصل إلى الحاسبة» قد تكون في الحاسبة.

عندما يكون الفرعان خلف NAT

هذه حالة شائعة مع خطوط المشتركين التي لا تعطي عنواناً عاماً. الحل تصميم hub-and-spoke: يتصل كل فرع بسيرفر ثابت، ويمرر السيرفر الترافيك بينهما.

في التصميم الثاني يضع السيرفر شبكة كل فرع في AllowedIPs الخاصة بطرف ذلك الفرع. ويفعّل net.ipv4.ip_forward=1 ويسمح بالعبور بين الطرفين. ثم يضيف كل فرع مساراً إلى شبكة الفرع الآخر عبر النفق.

وهنا يظهر أن القرب ليس كل شيء. فالسيرفر الوسيط يشفّر ويفك التشفير لكل حزمة، فقوة معالجه تؤثر في الفرعين معاً. وعلى أحد سيرفراتنا، بمعالج Xeon E5-2698 v4 وVM بأربع أنوية، بلغت قدرة التشفير الداخلية نحو 1.7Gbps. وبلغ التنزيل عبر النفق 57MB/s على منفذ حده النظري 60MB/s.

تشغيل برامج العمل عبر الربط

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

وتحتاج الأسماء إلى عناية كذلك. قد يعمل الوصول بالعنوان الرقمي، ويفشل باسم الجهاز، لأن اكتشاف الأسماء في ويندوز يعتمد على البث، والبث لا يعبر النفق. والحل أن تستعمل خادم DNS داخلياً، أو أن تضيف سجلات ثابتة عبر /ip dns static:

/ip dns static add name=accounting.branch.lan address=192.168.10.10

ترتيب لإضافة فرع ثالث

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

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

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

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

الخلاصة

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