دليل MikroTik IPsec للربط بين موقعين

الملخّص تُشفّر شبكة MikroTik IPsec للربط بين موقعين حركة البيانات بين شبكتين كاملتين — مقر رئيسي وفرع، أو مركز عمليات وموقع برج — بحيث تصل الأجهزة على كل شبكة محلية إلى الأخرى وكأنها محلية. يضبط هذا الدليل كلا الموجّهين على RouterOS v7: نظير IKEv2، وهوية المفتاح المشترك مسبقًا، واقتراح المرحلة 2، وسياسة النفق، وقاعدة تجاوز NAT التي تُعثر معظم المحاولات الأولى، وقواعد جدار الحماية والفحوص التي تؤكد أن النفق يعمل.

ما هي شبكة MikroTik IPsec للربط بين موقعين؟

شبكة MikroTik IPsec للربط بين موقعين هي نفق مشفّر دائم بين موجّهين يدمج شبكتين محليتين منفصلتين في شبكة واحدة قابلة للتوجيه على الطبقة 3، دون أن يعرّض أي من الموجّهين منفذ إدارة للإنترنت العام. وعلى خلاف شبكات VPN لوصول العملاء مثل WireGuard أو OpenVPN — حيث يتصل جهاز إداري واحد — يكون النفق بين موقعين دائم التشغيل ومن شبكة فرعية إلى أخرى: كل مضيف خلف الموجّه A يمكنه الوصول تلقائيًا إلى كل مضيف مسموح به خلف الموجّه B. و IPsec هو الأداة الصحيحة هنا لأنه معيار مفتوح تدعمه تقريبًا كل الشركات المصنّعة لجدران الحماية والموجّهات، ويعمل داخل نواة RouterOS بإنتاجية جيدة، وهو مدمج في MikroTik دون الحاجة إلى تثبيت حزمة إضافية.

يُبنى النفق عبر تفاوضين. المرحلة 1 (IKE) تصادق الموجّهين لدى بعضهما وتُنشئ قناة آمنة؛ والمرحلة 2 (IPsec) تتفاوض على المفاتيح التي تُشفّر بياناتك فعليًا. اجعل المرحلتين متطابقتين على الطرفين فيرتفع النفق؛ واجعل خوارزمية واحدة غير متطابقة فيفشل بصمت — ولهذا تُبقي الخطوات أدناه الطرفين متماثلين.

قبل أن تبدأ

تحتاج إلى موجّهَي MikroTik يعملان بنظام RouterOS v7، لكل منهما عنوان IP عام أو اسم مضيف DDNS يعمل، وشبكتين فرعيتين محليتين غير متداخلتين. يستخدم هذا الدليل 192.168.10.0/24 في الموقع A و 192.168.20.0/24 في الموقع B. إذا استخدم الموقعان 192.168.88.0/24، فالتوجيه مستحيل — أعد عنونة أحد الطرفين أولًا. وبما أن IPsec حسّاس جدًا لانحراف الساعة، فعّل NTP على كلا الموجّهين قبل البدء؛ فإذا ابتعد الطرفان زمنيًا، تنتهي صلاحية ارتباطات الأمان ويظل النفق ينقطع.

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

الخطوة 1: إنشاء ملف تعريف IKE والنظير

في الموقع A، عرّف ملف تعريف المرحلة 1 ووجّه نظيرًا إلى العنوان العام للموقع B:

/ip ipsec profile add name=to-siteB hash-algorithm=sha256 \
    enc-algorithm=aes-256 dh-group=modp2048 lifetime=1d

/ip ipsec peer add name=siteB address=<SITE_B_PUBLIC_IP>/32 \
    profile=to-siteB exchange-mode=ike2

dh-group=modp2048 هو Diffie-Hellman Group 14 — خيار افتراضي حديث وسليم. و exchange-mode=ike2 يختار IKEv2، وهو أسرع وأمتن من وضع main/IKEv1 القديم. يجب أن يستخدم الطرفان القيم نفسها في ملف التعريف ووضع التبادل نفسه.

الخطوة 2: إضافة الهوية (المفتاح المشترك مسبقًا)

/ip ipsec identity add peer=siteB auth-method=pre-shared-key \
    secret="<long-random-shared-secret>"

استخدم سرًا طويلًا وعشوائيًا وخزّنه كما تخزّن مفتاح SSH — لا في رسالة محادثة. ويوضع السر نفسه على كلا الموجّهين.

الخطوة 3: تعريف اقتراح المرحلة 2

/ip ipsec proposal add name=to-siteB auth-algorithms=sha256 \
    enc-algorithms=aes-256-cbc pfs-group=modp2048

السرية التامة للتمرير (pfs-group) تعني أن كل إعادة توليد للمفاتيح تستخدم مادة مفاتيح جديدة، فلا يكشف مفتاح مخترق حركة سابقة أبدًا. وكما في المرحلة 1، يجب أن تتطابق الخوارزميات على الطرفين.

الخطوة 4: إنشاء سياسة النفق

تُخبر السياسة RouterOS بأي حركة يجب تشفيرها — من الشبكة المحلية المحلية إلى الشبكة المحلية البعيدة:

/ip ipsec policy add peer=siteB tunnel=yes \
    src-address=192.168.10.0/24 dst-address=192.168.20.0/24 \
    proposal=to-siteB action=encrypt

tunnel=yes هو ما يجعل هذا ربطًا بين موقعين لا بين مضيفين: تُغلَّف الحزم الأصلية بالكامل، فتتحدث الشبكتان المحليتان بشفافية.

الخطوة 5: إضافة قاعدة تجاوز NAT (الخطوة التي ينساها الجميع)

هنا تنهار معظم المحاولات الأولى. يحتوي موجّهك أصلًا على قاعدة masquerade تعيد كتابة عنوان المصدر لحركة الشبكة المحلية الصادرة. فإذا عملت قبل IPsec، يستقبل الطرف البعيد حزمًا لم يعد مصدرها مطابقًا للسياسة فيُسقطها. أضف قاعدة قبول فوق قاعدة masquerade حتى تتخطى الحركة المتجهة إلى النفق عملية NAT:

/ip firewall nat add chain=srcnat action=accept place-before=0 \
    src-address=192.168.10.0/24 dst-address=192.168.20.0/24

place-before=0 يضع القاعدة في أعلى سلسلة srcnat تمامًا، وهذا إلزامي — فقاعدة تجاوز موضوعة بعد masquerade لا تفعل شيئًا.

الخطوة 6: فتح جدار الحماية والتحقق

اسمح بمنافذ IKE و NAT-T إضافة إلى بروتوكول ESP في سلسلة input حتى يتمكن النفق من التأسيس، خاصة إذا كان أحد الموقعين خلف جهاز NAT آخر:

/ip firewall filter add chain=input protocol=udp dst-port=500,4500 action=accept
/ip firewall filter add chain=input protocol=ipsec-esp action=accept

ثم تأكد من أن النفق يعمل:

/ip ipsec active-peers print
/ip ipsec policy print

يُظهر النفق السليم نظيرًا نشطًا وسياسة تقرأ فيها ph2-state القيمة established. واختبار ping سريع من مضيف على شبكة محلية إلى مضيف على الأخرى يثبت الوصول من طرف إلى طرف.

عكس الإعداد على الموقع B

كرّر كل خطوة على الموقع B مع عكس العناوين: يشير النظير إلى عنوان IP العام للموقع A، وتستخدم السياسة وقاعدة تجاوز NAT القيمتين src-address=192.168.20.0/24 و dst-address=192.168.10.0/24. أما ملف التعريف والاقتراح وسر الهوية ووضع IKEv2 فتبقى متطابقة. وعندما يتطابق الطرفان، تكتمل المرحلة 1 والمرحلة 2 ويرتفع النفق.

نصائح للأمان والتشغيل

أبقِ RouterOS محدّثًا — فقد شملت إصدارات حديثة إصلاحات تمسّ مطابقة شهادات النظير في IPsec/IKEv2، لذا يستحق نفق كان يعمل الربع الماضي إعادة اختبار بعد كل ترقية. فضّل IKEv2 مع PFS على الإعدادات الافتراضية القديمة لـ IKEv1. وحيثما أمكن، انتقل من السر المشترك إلى مصادقة الشهادات مع تزايد عدد الأنفاق، لأن تسريب مفتاح مشترك واحد يؤثر على كل موقع يتشاركه. وسجّل حالة النفق في مكان تراقبه فعلًا: فالرابط المعطّل بين موقعين يبقى غير مرئي حتى يحاول أحدهم الوصول إلى الشبكة المحلية البعيدة ويعجز.

على مستوى أسطول، فإن نفق IPsec ينقطع بهدوء بعد انحراف الساعة أو تذبذب في WAN هو بالضبط نوع الأعطال التي يلاحظها العميل قبلك. ويسدّ MKController هذه الفجوة: فهو يراقب كل موجّه عبر نفق صادر آمن لا يحتاج إلى عنوان IP عام ولا إلى إعادة توجيه منافذ على الجهاز، ويحتفظ بنسخ احتياطية مؤرشفة للإعدادات حتى تقارن وتستعيد كتلة IPsec سليمة بعد تعديل خاطئ، ويمكنه فتح تذكرة عند حدث انقطاع الرابط قبل أن يرن الهاتف. أما بخصوص إعداد النفق نفسه، فدليلنا عن NAT على MikroTik يشرح قاعدة masquerade التي تتجاوزها هنا، وللوصول إلى موجّه واحد بدل ربط شبكتين محليتين، راجع الإدارة عن بُعد خلف CGNAT وشرحنا عن الإدارة عن بُعد باستخدام WireGuard.

اجمع أنفاقك تحت سقف واحد

يربط IPsec موقعين بنظافة، لكن مزوّد خدمة إنترنت أو مزوّد خدمات مُدارة في نمو سرعان ما يجد عشرات الأنفاق والمفاتيح وقواعد جدار الحماية التي يجب إبقاؤها متزامنة — وكل تعديل يدوي فرصة لأن تحبس نفسك خارج موقع بعيد. صُمم MKController لهذا النطاق تحديدًا: إدارة مركزية للأسطول، ووصول آمن عن بُعد دون منافذ مكشوفة، وسجل إعدادات ونسخ احتياطية، ودفع تغييرات جدار الحماية والسياسات على مستوى الأسطول، فتُنشر قوالب الأنفاق مرة واحدة بدل إعادة كتابتها موجّهًا موجّهًا. والمشغّلون الذين يديرون MikroTik على نطاق واسع يستخدمونه لتحويل ظهيرة ضائعة من جلسات SSH لكل جهاز إلى بضع نقرات لكل تغيير.

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