جدار الحماية Firewall في MikroTik RouterOS بالتفصيل

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

المواضيع في السلسلة:

1. MikroTik وRouterOS للمبتدئين: الأجهزة والتراخيص وWinBox، وأول إعداد آمن.
2. جدار الحماية في MikroTik RouterOS بالتفصيل: السلاسل وتتبع الاتصالات والقوائم وNAT (الموضوع الحالي).
3. MikroTik في الواقع: شبكة الضيوف وVLAN وWireGuard وتوجيه المنافذ وأكثر من مزود إنترنت.

وفي هذا المقال سوف نتناول:

• الجداول Tables والسلاسل Chains في RouterOS، وطريق الحزمة بينها.
• حالات الاتصال في تتبع الاتصالات Connection Tracking، ولماذا هي أساس كل جدار ناري حديث.
• قوائم الواجهات وقوائم العناوين Address Lists، والإجراءات Actions، وترتيب القواعد.
• مجموعة القواعد الأساسية التي توصي بها MikroTik، مطبقة على RouterOS حقيقي، مع العدادات بعد حركة حقيقية.
• FastTrack: ما الذي يسرعه وما الذي يتجاوزه.
• NAT: الفرق بين masquerade وsrc-nat، وتوجيه المنافذ بـ dst-nat، وHairpin NAT.
• جدول raw للإسقاط المبكر، والحماية من تخمين كلمات المرور بقوائم العناوين، مع تجربة حقيقية.
• جدار IPv6 الذي ينساه كثيرون، والتسجيل Logging، والأخطاء الشائعة، وقائمة تحقق.

ونفترض في هذا المقال أنك تعرف ما هو NAT وكيف يحفظ ال Router كل اتصال في جدول، وإذا لم تكن تعرف فابدأ ب ما هو NAT؟ شرح للمبتدئين، فهو يشرح الفكرة على Linux عموماً، وهنا نركز على ما يخص RouterOS.

الجداول والسلاسل: أين تكتب القاعدة؟

الجدار الناري في RouterOS مقسم إلى جداول Tables، كل جدول له وظيفة، وفي كل جدول سلاسل Chains هي اللحظات التي يمر فيها الجدول على الحزمة، كما في صفحة Firewall:

وأهم ثلاث سلاسل في جدول filter هي:

• input: الحزم الموجهة إلى الراوتر نفسه، مثل SSH وWinBox وDNS إلى الراوتر، وهي التي تحمي الجهاز.
• forward: الحزم التي تمر عبر الراوتر من شبكة إلى أخرى، مثل حاسوبك وهو يتصفح الإنترنت، وهي التي تحمي الأجهزة خلفه.
• output: الحزم التي ينشئها الراوتر نفسه، مثل تحديث النظام أو استعلام NTP، ونادراً ما تحتاج إلى قواعد فيها.

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

طريق الحزمة داخل الراوتر

MikroTik تنشر مخططاً مفصلاً اسمه Packet Flow in RouterOS فيه كل مرحلة تمر بها الحزمة، ورسمنا منه في الصورة التالية الطرق الثلاثة التي تهمك:

في الرسم أعلاه لاحظ التالي:

1. الحزمة تمر على جدول raw أولاً ثم على تتبع الاتصالات، ولذلك فإن raw هو المكان الوحيد الذي تسقط فيه حزمة قبل أن تأخذ مكاناً في جدول الاتصالات، أو تستثنيها منه.
2. ترجمة الوجهة dstnat تحدث قبل قرار التوجيه Routing Decision، لأن الراوتر يجب أن يعرف الوجهة الحقيقية حتى يقرر هل الحزمة له أم لجهاز خلفه، ولهذا فإن الحزمة التي وجهت بتوجيه المنافذ تصل إلى سلسلة forward وليس input.
3. ترجمة المصدر srcnat تحدث في النهاية بعد الفلترة، لذلك ترى قواعد forward العناوين الداخلية الأصلية للأجهزة، وليس عنوان الراوتر العام.
4. الحزم التي تنتمي لاتصال عليه علامة FastTrack تتجاوز أغلب هذه المراحل، وسوف نعود إلى ذلك.

حالات الاتصال: لماذا لا تفحص كل حزمة من جديد؟

تتبع الاتصالات Connection Tracking هو جزء النواة الذي يتذكر كل اتصال يمر عبر الراوتر، وقد شرحنا فكرته في جدول الاتصالات في مقال NAT، وما يهمنا هنا أن كل حزمة تأخذ حالة State من خمس حالات حسب صفحة Connection Tracking، والصورة التالية تبينها:

• new: أول حزمة في اتصال جديد، مثل حزمة SYN في TCP، أو أول حزمة UDP لا يوجد لها سجل.
• established: حزمة تنتمي لاتصال موجود في الجدول.
• related: حزمة جديدة ولكنها مرتبطة باتصال موجود، مثل رسالة ICMP تخبرك أن الوجهة غير موجودة، أو اتصال البيانات في FTP.
• invalid: حزمة لا تنتمي لأي اتصال ولا تبدأ اتصالاً صحيحاً، وفي أغلب الحالات يجب أن تسقط.
• untracked: حزمة استثنيتها من التتبع بقاعدة في جدول raw، فلا يعرف عنها الجدول شيئاً.

وفكرة الجدار الناري الحديث كلها مبنية على هذه الحالات: تقبل established وrelated في أول القائمة بقاعدة واحدة، لأنها اتصالات قررت السماح بها من قبل، وتسقط invalid، ثم تكتب القواعد المفصلة للحالة new فقط، وبهذا تمر أغلب الحزم على قاعدة واحدة بدلاً من القائمة كلها. ولكن التوثيق يحذر من حالة واحدة: إذا كانت شبكتك فيها توجيه غير متماثل Asymmetric Routing، أي أن الذهاب يمر من راوتر والعودة من آخر، فإن الراوتر لا يرى إلا نصف الاتصال ويعتبر حزمه invalid، فلا تستخدم قاعدة إسقاط invalid في مثل هذه الشبكة.

وجدول الاتصالات له حجم أقصى يعتمد على ذاكرة الجهاز، وهذه إعداداته في CHR الذي يعمل في مختبرنا بذاكرة 256 ميغابايت:

[netadmin@CHR] > /ip firewall connection tracking print
                   enabled: auto
               active-ipv4: yes
               active-ipv6: no
      tcp-syn-sent-timeout: 5s
  tcp-syn-received-timeout: 5s
   tcp-established-timeout: 1d
      tcp-fin-wait-timeout: 10s
    tcp-close-wait-timeout: 10s
      tcp-last-ack-timeout: 10s
     tcp-time-wait-timeout: 10s
         tcp-close-timeout: 10s
   tcp-max-retrans-timeout: 5m
       tcp-unacked-timeout: 5m
        loose-tcp-tracking: yes
      liberal-tcp-tracking: no
               udp-timeout: 30s
        udp-stream-timeout: 3m
              icmp-timeout: 10s
           generic-timeout: 10m
               max-entries: 71680
             total-entries: 2
         total-ip4-entries: 2
         total-ip6-entries: 0    

في المخرج أعلاه لاحظ التالي:

• enabled: auto يعني أن التتبع معطل حتى تضاف أول قاعدة في الجدار الناري، ولهذا لم يكن في CHR الفارغ أي تتبع للاتصالات قبل أن نكتب القواعد.
• tcp-established-timeout: 1d يعني أن اتصال TCP المفتوح يبقى في الجدول يوماً كاملاً إذا لم تمر فيه حزمة، وهذا ما يجعل الجدول يمتلئ في الشبكات الكبيرة، وقد شرحنا أعراض امتلائه في امتلاء جدول الاتصالات وكيف تراقبه على Linux في قسم conntrack.
• max-entries: 71680 هو الحد في هذا الجهاز الصغير، والتوثيق يقول إنه يعتمد على الذاكرة ولا يتجاوز 1048576.

أدوات كتابة القواعد: القوائم والإجراءات

قوائم الواجهات Interface Lists

بدلاً من أن تكتب in-interface=ether1 في كل قاعدة، تكتب in-interface-list=WAN، وتضع في القائمة WAN كل واجهة تتصل بالإنترنت. والفائدة تظهر عندما يتغير شيء: إذا انتقلت من DHCP إلى PPPoE فإن واجهة الإنترنت تصبح pppoe-out1 بدلاً من ether1، والقواعد التي تستخدم القائمة تبقى صحيحة بمجرد أن تضيف الواجهة الجديدة إليها، أما القواعد التي تستخدم الاسم فتترك الواجهة الجديدة دون حماية، وهذا خطأ يتكرر في الشروحات. والإعداد الافتراضي يستخدم القائمتين WAN وLAN، وأنشأناهما في المقال الأول.

قوائم العناوين Address Lists

قائمة العناوين اسم تجمع تحته عناوين أو شبكات، ثم تكتب قاعدة واحدة على القائمة، كما في صفحة Address Lists. والمدخلات تأتي من ثلاثة مصادر: أنت تضيفها، أو قاعدة في الجدار الناري تضيفها بالإجراء add-src-to-address-list مع مدة انتهاء Timeout، أو تضع اسم نطاق مثل اسم DDNS لمكتبك فيحله الراوتر إلى عنوان ويحدثه عندما يتغير. ولاحظ أن المدخلات التي لها مدة انتهاء ديناميكية، فلا تحفظ في الإعداد وتختفي بعد إعادة التشغيل.

الإجراءات Actions

كل قاعدة تنتهي بإجراء، وأهمها حسب مرجع /ip firewall filter:

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

ترتيب القواعد: أول قاعدة تطابق تفوز

الصورة التالية تبين حزمتين تمران على سلسلة input نفسها، واحدة من الشبكة الداخلية وأخرى من الإنترنت:

والخطأ الأكثر تكراراً أن تضيف قاعدة قبول بالأمر add فتذهب إلى آخر القائمة، بعد قاعدة الإسقاط العامة، فلا تعمل أبداً، لذلك استخدم place-before لتضع القاعدة في مكانها، مثل place-before=[find comment="input: drop all not coming from LAN"]، وهذا سبب آخر لكتابة تعليق Comment واضح على كل قاعدة.

مجموعة القواعد الأساسية

القواعد التالية هي جوهر الإعداد الافتراضي الذي تأتي به أجهزة البيت، وتشرحه MikroTik في Securing your router وفي Building Advanced Firewall الذي يصف الجدار العادي بأنه يقبل established وrelated وuntracked ويسقط كل ما لا يأتي من LAN. وكتبناها في ملف fw.rsc بتعليقات خاصة بنا، ونقلناه إلى CHR ثم استوردناه بالأمر /import file-name=fw.rsc:

/ip firewall filter
add chain=input action=accept connection-state=established,related,untracked comment="input: accept established,related,untracked"
add chain=input action=drop connection-state=invalid comment="input: drop invalid"
add chain=input action=accept protocol=icmp comment="input: accept ICMP"
add chain=input action=drop in-interface-list=!LAN comment="input: drop all not coming from LAN"
add chain=forward action=fasttrack-connection connection-state=established,related comment="forward: fasttrack"
add chain=forward action=accept connection-state=established,related,untracked comment="forward: accept established,related,untracked"
add chain=forward action=drop connection-state=invalid comment="forward: drop invalid"
add chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN comment="forward: drop all from WAN not DSTNATed"
/ip firewall nat
add chain=srcnat action=masquerade out-interface-list=WAN ipsec-policy=out,none comment="masquerade LAN to WAN"

في الإعداد أعلاه لاحظ التالي:

• سلسلة input تحمي الراوتر: تقبل ردود الاتصالات المعروفة، وتسقط invalid، وتقبل ICMP لأن ping وتقسيم الحزم Path MTU Discovery يعتمدان عليه، ثم تسقط كل ما لا يأتي من قائمة LAN. ولاحظ أن القاعدة الأخيرة تقول !LAN وليس WAN، فأي واجهة جديدة تنساها خارج القوائم تكون محمية تلقائياً.
• سلسلة forward تحمي الأجهزة خلف الراوتر: تقبل الاتصالات المعروفة، وتسقط invalid، ثم تسقط كل اتصال جديد يأتي من WAN إلا إذا كان قد مر على dst-nat، أي إلا إذا كان توجيه منفذ أنشأته أنت، وهذا معنى connection-nat-state=!dstnat.
• الإعداد الافتراضي في الأجهزة الحقيقية يضيف قبل FastTrack قاعدتي قبول للحركة التي تطابق سياسات IPsec ipsec-policy=in,ipsec وout,ipsec، لأن حركة IPsec يجب ألا تمر عبر FastTrack، وأضفنا ipsec-policy=out,none إلى masquerade للسبب نفسه.
• الإعداد الافتراضي يضع hw-offload=yes على قاعدة FastTrack، وعندما كتبناها في CHR رفضها بالخطأ bad parameter hw-offload، لأن المرجع يقول إنها تعمل فقط على السويتشات التي تدعم تسريع FastTrack في العتاد، فحذفناها في المختبر.

والمخرج بعد الاستيراد سوف يكون كما يلي:

[netadmin@CHR] > /ip firewall filter print
Flags: D - DYNAMIC
0 D ;;; special dummy rule to show fasttrack counters
    chain=forward action=passthrough

1   ;;; input: accept established,related,untracked
    chain=input action=accept connection-state=established,related,untracked

2   ;;; input: drop invalid
    chain=input action=drop connection-state=invalid

3   ;;; input: accept ICMP
    chain=input action=accept protocol=icmp

4   ;;; input: drop all not coming from LAN
    chain=input action=drop in-interface-list=!LAN

5   ;;; forward: fasttrack
    chain=forward action=fasttrack-connection
    connection-state=established,related

6   ;;; forward: accept established,related,untracked
    chain=forward action=accept connection-state=established,related,untracked

7   ;;; forward: drop invalid
    chain=forward action=drop connection-state=invalid

8   ;;; forward: drop all from WAN not DSTNATed
    chain=forward action=drop connection-state=new connection-nat-state=!dstnat
    in-interface-list=WAN

والقاعدة رقم 0 لم نكتبها، وإنما يضيفها RouterOS عندما توجد قاعدة FastTrack، وهي لا تفعل شيئاً سوى أن تعرض عدد الحزم التي مرت بطريق FastTrack، لأن هذه الحزم لا تمر على بقية القواعد فلا تظهر في عداداتها.

العدادات بعد حركة حقيقية

بعد ذلك صفرنا العدادات، ثم أرسلنا من الجهاز الداخلي 192.168.88.10 ثلاثة طلبات HTTPS إلى example.com وتنزيلاً بحجم 2 ميغابايت من خادم MikroTik، ثم طبعنا العدادات:

[netadmin@CHR] > /ip firewall filter print stats
Flags: D - DYNAMIC
Columns: CHAIN, ACTION, BYTES, PACKETS
#   CHAIN    ACTION                    BYTES  PACKETS
;;; special dummy rule to show fasttrack counters
0 D forward  passthrough                   0        0
;;; input: accept established,related,untracked
1   input    accept                   10 598       53
;;; input: drop invalid
2   input    drop                      7 824      186
;;; input: accept ICMP
3   input    accept                       84        1
;;; input: drop all not coming from LAN
4   input    drop                          0        0
;;; forward: fasttrack
5   forward  fasttrack-connection  2 121 424      865
;;; forward: accept established,related,untracked
6   forward  accept                2 121 424      865
;;; forward: drop invalid
7   forward  drop                        120        3
;;; forward: drop all from WAN not DSTNATed
8   forward  drop                          0        0

Columns: CHAIN, ACTION, BYTES, PACKETS
# CHAIN   ACTION      BYTES  PACKETS
;;; masquerade LAN to WAN
0 srcnat  masquerade    316        5

في المخرج أعلاه لاحظ التالي:

• قاعدة masquerade عدت 5 حزم فقط رغم أن التنزيل مر فيه أكثر من 800 حزمة، والسبب أن NAT يقرر عند أول حزمة في كل اتصال فقط، ثم يترجم بقية الحزم من جدول الاتصالات، وهذا ما شرحناه في كيف يعمل NAT.
• قاعدتا FastTrack والقبول بعدها عدتا الحزم نفسها، 865 حزمة، والقاعدة الوهمية رقم 0 بقيت على صفر، أي أن الاتصالات أخذت علامة FastTrack ولكن الحزم لم تمر فعلاً بالطريق السريع، وسوف نعود إلى ذلك في القسم التالي.
• القاعدة 4 بقيت على صفر لأن أحداً لم يحاول الوصول إلى الراوتر من WAN أثناء هذه الحركة، وبعد طباعة العدادات حاولنا الدخول بـ SSH من جهة WAN فأصبح المخرج Connection to 127.0.0.1 port 21182 timed out بدلاً من Connection closed by remote host الذي رأيناه في المقال الأول، أي أن المنفذ لم يعد يرد إطلاقاً، وهذا هو الفرق بين drop وavailable-from.

FastTrack: سرعة مقابل تجاوز

FastTrack اختصار لطريق سريع مع تتبع الاتصالات، فعندما يأخذ الاتصال علامة fasttrack-connection تمر حزمه بطريق مختصر يتجاوز أغلب مراحل النواة، فيرتفع ما يمرره الجهاز الصغير بشكل كبير، ولكن الثمن مكتوب في صفحة Connection Tracking: الحزم في هذا الطريق تتجاوز الجدار الناري، وتتبع الاتصالات، والطوابير البسيطة Simple Queues، وQueue Tree المربوط ب global، ومحاسبة IP، وIPsec، وتوجيه VRF. وهذا يعني عملياً:

• إذا وضعت Simple Queue لتحديد سرعة جهاز، ولم تستثنه من FastTrack، فقد لا يعمل التحديد.
• إذا كان عندك نفق IPsec، فيجب أن تقبل حركته قبل قاعدة FastTrack، وهذا سبب قاعدتي IPsec في الإعداد الافتراضي.
• FastTrack يعمل مع جدول التوجيه الرئيسي main فقط، فإذا كنت توجه بعض الحركة بجداول أخرى عبر علامات mangle فلا تضع عليها FastTrack.
• FastTrack يخص IPv4 فقط، وTCP وUDP فقط.

والطريقة التي يقترحها التوثيق لاستثناء جهاز هي قاعدة قبول له قبل قاعدة FastTrack، فلا يصل اتصاله إليها:

/ip firewall filter
add action=accept chain=forward connection-state=established,related src-address=192.168.88.111
add action=accept chain=forward connection-state=established,related dst-address=192.168.88.111
add action=fasttrack-connection chain=forward connection-state=established,related hw-offload=no
add action=accept chain=forward connection-state=established,related

أما لماذا بقي عداد FastTrack على صفر في مختبرنا، فقد سألنا الراوتر نفسه:

[netadmin@CHR] > /ip settings print
                            allow-fast-path: yes
                      ipv4-fast-path-active: no
                     ipv4-fast-path-packets: 0
                       ipv4-fast-path-bytes: 0
                      ipv4-fasttrack-active: yes
                     ipv4-fasttrack-packets: 0
                       ipv4-fasttrack-bytes: 0            

المخرج أعلاه جزء من مخرج الأمر، ويبين أن FastTrack مفعل ولكن لم تمر فيه حزمة واحدة في CHR الذي يعمل بالترخيص المجاني داخل QEMU، ولم نجد في التوثيق سبباً محدداً لهذه الحالة، لذلك لا تعتمد على وجود القاعدة وحده، وتحقق دائماً من ipv4-fasttrack-packets ومن القاعدة الوهمية على جهازك، وسوف ترى في المقال الثالث أثر ذلك على الطوابير.

NAT في RouterOS

masquerade أم src-nat؟

الاثنان يترجمان عنوان المصدر إلى عنوان الراوتر، والفرق كما في صفحة NAT أن masquerade يأخذ عنوان الواجهة الخارجة وقت الترجمة، وعندما تنقطع الواجهة أو يتغير عنوانها يحذف كل الاتصالات المترجمة عليها من الجدول، وهذا مناسب لعنوان يتغير مع DHCP أو PPPoE. أما src-nat فتكتب فيه العنوان بنفسك to-addresses=...، والاتصالات تبقى بعد انقطاع قصير، وهو المناسب عندما يكون عنوانك العام ثابتاً. والتوثيق يذكر مشكلة مع masquerade في الشبكات التي فيها أكثر من مزود: عندما ينقطع المزود الأول ثم يعود، قد تخرج حزم اتصالات قديمة عبره دون ترجمة فتتسرب العناوين الداخلية، والحل الذي يقترحه مسار احتياطي من نوع blackhole، وسوف نذكره مع أكثر من مزود في المقال الثالث.

توجيه المنافذ بـ dst-nat

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

وفي المختبر شغلنا سيرفر ويب صغير على الجهاز الداخلي 192.168.88.10 بالمنفذ 8000، ثم أضفنا قاعدة توجه المنفذ 8443 القادم من WAN إليه:

/ip firewall nat add chain=dstnat action=dst-nat in-interface-list=WAN protocol=tcp dst-port=8443 to-addresses=192.168.88.10 to-ports=8000 comment="home server web"

ثم طلبنا الصفحة من جهة WAN مرتين، والمخرج سوف يكون كما يلي:

hello from the home server 192.168.88.10
 [200 0.003573s]
hello from the home server 192.168.88.10
 [200 0.003441s]

وجدول الاتصالات يبين الترجمتين معاً، فالسطر الأول اتصال وارد عليه العلم d أي DSTNAT، والثاني اتصال خارج من الجهاز الداخلي عليه العلم s أي SRCNAT:

[netadmin@CHR] > /ip firewall connection print where (dstnat or srcnat)
Flags: S - SEEN-REPLY; A - ASSURED; C - CONFIRMED; F - FASTTRACK; s - SRCNAT
       d - DSTNAT
Columns: PROTOCOL, SRC-ADDRESS, SRC-PORT, DST-ADDRESS, DST-PORT, TCP-STATE,
         TIMEOUT
 #        PRO  SRC-ADDRESS    SRC-PORT  DST-ADDRESS    DST-PORT  TCP-STATE  TI
30 SACF d tcp  10.0.2.2          38470  10.0.2.15          8443  time-wait  7s
31 SACFs  tcp  192.168.88.10     51158  104.20.23.154       443  time-wait  8s

في المخرج أعلاه لاحظ التالي:

• الاتصال الوارد مر على سلسلة forward وليس input، لأن dst-nat غير الوجهة قبل قرار التوجيه، ولهذا لم تسقطه القاعدة الأخيرة في forward، فهي تسقط فقط ما لم يمر على dstnat.
• الاتصالان عليهما العلم F، أي أنهما أخذا علامة FastTrack، رغم أن العداد بقي صفراً كما رأينا.
• القاعدة كما كتبناها مفتوحة لكل الإنترنت، فإذا كان السيرفر لك وحدك فأضف src-address أو src-address-list كما يقترح التوثيق، والأفضل ألا تفتح منفذاً أصلاً وأن تصل عبر VPN، وقد شرحنا البدائل كلها في فتح المنافذ في ال Router بالطريقة الصحيحة.

Hairpin NAT: عندما تطلب عنوانك العام من داخل البيت

إذا فتحت الموقع من حاسوب داخل البيت باستخدام اسم النطاق الذي يشير إلى عنوانك العام، فإن الراوتر يغير الوجهة إلى السيرفر، ولكن السيرفر يرى أن الطالب في شبكته نفسها فيرد عليه مباشرة، والحاسوب يرفض رداً يأتي من عنوان لم يطلبه، فيفشل الاتصال. وقد شرحنا هذه الحالة بالتفصيل في Hairpin NAT في مقال NAT، والحل في RouterOS قاعدة srcnat تجعل الاتصال الداخلي يبدو كأنه من الراوتر، وهذا مثال التوثيق كما هو، حيث 10.0.0.3 هو السيرفر و10.0.0.0/24 هي الشبكة الداخلية:

/ip/firewall/nat
add action=masquerade chain=srcnat dst-address=10.0.0.3 out-interface=LAN protocol=tcp src-address=10.0.0.0/24

ولم نجرب هذه القاعدة في المختبر لأن الجهاز الداخلي والسيرفر فيه هما الجهاز نفسه، والبديل الأنظف أحياناً أن تجعل DNS الداخلي يجيب بالعنوان الداخلي للسيرفر، وسوف نرى السجلات الثابتة في DNS الراوتر في المقال الثالث.

جدول raw: أسقط قبل أن تتذكر

كل حزمة new تأخذ مكاناً في جدول الاتصالات قبل أن تصل إلى filter، فإذا كان أحد يغرق عنوانك بحزم من عناوين مزيفة، فإن الجدول يمتلئ قبل أن تسقطها قاعدة filter. لذلك فإن جدول raw يعمل في prerouting قبل تتبع الاتصالات، فما تسقطه فيه لا يكلف الجهاز ذاكرة، ومثاله في صفحة Address Lists أن تضع في قائمة كل مصدر يحاول الوصول إلى منفذ Telnet على عنوانك العام، لأن من يطرق هذا المنفذ يبحث في الغالب عن أجهزة ضعيفة، ثم تسقط كل حركته في raw. وفي Building Advanced Firewall تجد مثالاً كاملاً يسقط في raw العناوين التي لا يجب أن تأتي من الإنترنت أصلاً، مثل العناوين الخاصة ونطاقات التوثيق، وهذا جزء منه كما هو:

/ip/firewall/raw
add action=accept chain=prerouting comment="defconf: enable for transparent firewall" disabled=yes
add action=accept chain=prerouting comment="defconf: accept DHCP discover" dst-address=255.255.255.255 dst-port=67 in-interface-list=LAN protocol=udp src-address=0.0.0.0 src-port=68
add action=drop chain=prerouting comment="defconf: drop bogon IP's" src-address-list=bad_ipv4
add action=drop chain=prerouting comment="defconf: drop bogon IP's" dst-address-list=bad_ipv4
add action=drop chain=prerouting comment="defconf: drop bogon IP's" src-address-list=bad_src_ipv4
add action=drop chain=prerouting comment="defconf: drop bogon IP's" dst-address-list=bad_dst_ipv4
add action=drop chain=prerouting comment="defconf: drop non global from WAN" src-address-list=not_global_ipv4 in-interface-list=WAN

ولا تقم بنسخ المثال الكامل إلى جهازك دون أن تقرأه، والسبب أن فيه قواعد تفترض أن شبكتك الداخلية هي 192.168.88.0/24، وأخرى تسقط العناوين الخاصة القادمة من WAN، وهذه تقطع الإنترنت إذا كان جهازك خلف Router آخر أو خلف CGNAT، لأن عنوان بوابتك نفسه عنوان خاص في هذه الحالة، كما رأينا في ال Double NAT.

الحماية من تخمين كلمات المرور بقوائم العناوين

الحل الأفضل أن تبقى SSH وWinBox مغلقة من الإنترنت وتصل إليهما عبر VPN، ولكن إذا كان لا بد من فتح SSH، فإن صفحة Bruteforce Prevention تقترح قواعد تنقل كل مصدر بين ثلاث قوائم مع كل اتصال جديد، ثم تضعه في قائمة سوداء ليوم كامل عند الاتصال الرابع، والصورة التالية تبين المراحل:

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

/ip firewall filter
add chain=input action=add-src-to-address-list protocol=tcp dst-port=22 connection-state=new in-interface-list=WAN src-address-list=connection3 address-list=bruteforce_blacklist address-list-timeout=1d comment="SSH brute force: blacklist" place-before=[find comment="input: drop all not coming from LAN"]
add chain=input action=add-src-to-address-list protocol=tcp dst-port=22 connection-state=new in-interface-list=WAN src-address-list=connection2 address-list=connection3 address-list-timeout=1h comment="SSH brute force: third connection" place-before=[find comment="input: drop all not coming from LAN"]
add chain=input action=add-src-to-address-list protocol=tcp dst-port=22 connection-state=new in-interface-list=WAN src-address-list=connection1 address-list=connection2 address-list-timeout=15m comment="SSH brute force: second connection" place-before=[find comment="input: drop all not coming from LAN"]
add chain=input action=add-src-to-address-list protocol=tcp dst-port=22 connection-state=new in-interface-list=WAN address-list=connection1 address-list-timeout=5m comment="SSH brute force: first connection" place-before=[find comment="input: drop all not coming from LAN"]
add chain=input action=accept protocol=tcp dst-port=22 in-interface-list=WAN src-address-list=!bruteforce_blacklist comment="SSH brute force: accept" place-before=[find comment="input: drop all not coming from LAN"]
add chain=input action=drop protocol=tcp dst-port=22 in-interface-list=WAN comment="SSH brute force: drop blacklisted" place-before=[find comment="input: drop all not coming from LAN"]

في الإعداد أعلاه لاحظ التالي:

• القواعد مكتوبة بترتيب معكوس، من القائمة السوداء إلى المرحلة الأولى، والسبب أن add-src-to-address-list لا يوقف الحزمة، فلو كتبت بالترتيب الطبيعي لنقلت أول حزمة المصدر عبر كل المراحل دفعة واحدة.
• القاعدة الأخيرة هي التي تمنع فعلاً، فبدونها تكمل الحزمة من القائمة السوداء طريقها في السلسلة.
• لكي يصل الاتصال من WAN إلى SSH أصلاً، فتحنا مؤقتاً available-from في خدمة SSH لكل العناوين، ثم أعدناها إلى الشبكة الداخلية بعد التجربة.

ثم اتصلنا خمس مرات من جهة WAN بمفتاح صحيح، والمخرج سوف يكون كما يلي:

--- attempt 1
CHR
--- attempt 2
CHR
--- attempt 3
CHR
--- attempt 4
Connection timed out during banner exchange
--- attempt 5
Connection timed out during banner exchange

[netadmin@CHR] > /ip firewall address-list print where list~"^connection|^bruteforce"
Flags: D - DYNAMIC
Columns: LIST, ADDRESS, CREATION-TIME, TIMEOUT
#   LIST                  ADDRESS     CREATION-TIME        TIMEOUT
4 D connection1           172.17.0.1  2026-10-07 10:51:49  4m56s
5 D connection2           172.17.0.1  2026-10-07 10:51:49  14m56s
6 D connection3           172.17.0.1  2026-10-07 10:51:51  59m56s
7 D bruteforce_blacklist  172.17.0.1  2026-10-07 10:51:51  23h59m58s

في المخرج أعلاه لاحظ التالي:

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

جدار IPv6: الباب الذي ينساه الجميع

جدار IPv4 لا يحمي IPv6 إطلاقاً، فهما جدولان منفصلان في /ip firewall و/ipv6 firewall، وإذا كان مزودك يعطيك IPv6 فإن أجهزتك قد تأخذ عناوين عامة يمكن الوصول إليها مباشرة دون NAT. والإعداد الافتراضي لأجهزة البيت فيه جدار IPv6 مفعل حسب صفحة Default Configurations، أما CHR فهذا ما وجدناه فيه بعد أن كتبنا جدار IPv4 كاملاً:

[netadmin@CHR] > /ipv6 address print
Flags: D - DYNAMIC; L - LINK-LOCAL
Columns: ADDRESS, INTERFACE, VRF, ADVERTISE
#    ADDRESS                    INTERFACE  VRF   ADVERTISE
0 D  ::1/128                    lo         main  no
1 DL fe80::5054:ff:fe00:101/64  ether1     main  no
2 DL fe80::5054:ff:fe00:202/64  ether2     main  no

[netadmin@CHR] > /ipv6 firewall filter print count-only
0

أي أن IPv6 يعمل على الواجهتين بعناوين Link-Local، وجدول IPv6 فارغ، وكل ما قلناه عن السياسة الافتراضية ينطبق عليه، فلو أعطى المزود هذا الجهاز عنواناً عاماً لكانت كل خدماته مفتوحة عليه. وقواعد input التي يقترحها التوثيق ل IPv6 في Building Advanced Firewall أطول قليلاً من IPv4، لأن IPv6 يحتاج ICMPv6 ليعمل أصلاً، ويحتاج منفذ DHCPv6 لاستلام النطاق من المزود:

/ipv6/firewall/filter
add action=accept chain=input comment="defconf: accept ICMPv6 after RAW" protocol=icmpv6
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=accept chain=input comment="defconf: accept UDP traceroute" dst-port=33434-33534 protocol=udp
add action=accept chain=input comment="defconf: accept DHCPv6-Client prefix delegation." dst-port=546 protocol=udp src-address=fe80::/10
add action=accept chain=input comment="defconf: accept IKE" dst-port=500,4500 protocol=udp
add action=accept chain=input comment="defconf: accept IPSec AH" protocol=ipsec-ah
add action=accept chain=input comment="defconf: accept IPSec ESP" protocol=ipsec-esp
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN

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

التسجيل: اعرف ماذا يسقط جدارك

أي قاعدة تستطيع أن تسجل الحزم التي تطابقها، بإضافة log=yes وبادئة تعرفها بها في السجل:

/ip firewall filter set [find comment="input: drop all not coming from LAN"] log=yes log-prefix="WAN-IN-DROP"
/log print where message~"WAN-IN-DROP"

ثم طلبنا المنفذ 80 من جهة WAN، والمخرج سوف يكون كما يلي:

 2026-10-07 10:52:20 firewall,info WAN-IN-DROP input: in:ether1 out:(unknown 0), connection-state:new src-mac 52:55:0A:00:02:02, proto TCP (SYN), 172.17.0.1:51898->10.0.2.15:80, len 44
 2026-10-07 10:52:25 firewall,info WAN-IN-DROP input: in:ether1 out:(unknown 0), connection-state:new src-mac 52:55:0A:00:02:02, proto TCP (SYN), 172.17.0.1:51898->10.0.2.15:80, len 44

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

الأخطاء الشائعة

• قاعدة قبول بعد قاعدة الإسقاط: الأمر add يضع القاعدة في آخر القائمة، فاستخدم place-before وتأكد بالأمر print.
• قاعدة إسقاط عامة من جلسة بعيدة دون Safe Mode: قاعدة drop في input قبل قاعدة قبول اتصالك تقطع جلستك فوراً، لذلك اعمل في Safe Mode كما في المقال الأول.
• كتابة in-interface=ether1 بدلاً من القائمة: فإذا انتقلت إلى PPPoE بقيت الواجهة الجديدة دون حماية.
• نسيان IPv6: جدار IPv4 كامل وجدار IPv6 فارغ يعني أن الباب مفتوح من الجهة الأخرى.
• Simple Queue لا يعمل مع FastTrack: استثن الأجهزة التي تحدد سرعتها، أو أطفئ FastTrack إذا كانت الطوابير أهم لك من السرعة.
• توجيه منفذ دون قاعدة forward: في الإعداد الافتراضي القاعدة connection-nat-state=!dstnat تسمح بما وجهته تلقائياً، ولكن إذا كتبت جداراً صارماً بنفسك فيجب أن تسمح بالحركة الموجهة في forward، كما ينبه First Time Configuration.
• جعل الراوتر سيرفر DNS مفتوحاً: تفعيل allow-remote-requests مع جدار لا يسقط المنفذ 53 من WAN.
• نسخ مثال raw الكامل كما هو: فتنقطع الإنترنت إذا كان جهازك خلف NAT آخر.

قائمة تحقق الجدار الناري

1. input يبدأ بقبول established وrelated وuntracked، ثم إسقاط invalid، وينتهي بإسقاط كل ما لا يأتي من LAN.
2. forward يقبل established وrelated، ويسقط invalid، ويسقط كل جديد من WAN لم يمر على dstnat.
3. القواعد تستخدم قوائم WAN وLAN، وكل واجهة إنترنت جديدة في WAN.
4. كل قاعدة عليها تعليق، وقواعد القبول قبل قواعد الإسقاط.
5. masquerade لعنوان متغير، وsrc-nat لعنوان ثابت.
6. كل توجيه منفذ محصور بمصدر إن أمكن، أو مستبدل ب VPN.
7. جدار IPv6 فيه قواعد input وforward، أو IPv6 معطل.
8. FastTrack مستثنى منه ما يحتاج طوابير أو IPsec، وipv4-fasttrack-packets يتحرك فعلاً.
9. التسجيل مفعل فقط وقت التشخيص.

تدريب عملي

1. اطبع /ip firewall filter print stats على جهازك، ثم صفر العدادات وافتح موقعاً من حاسوبك، وحدد أي قاعدة زادت ولماذا.
2. أضف قاعدة قبول ل SSH من WAN بالأمر add دون place-before، واطبع القائمة، ولاحظ أين ذهبت ولماذا لن تعمل، ثم احذفها.

الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

• الجدار الناري في RouterOS جداول filter وraw وnat وmangle، وأهم السلاسل input لحماية الراوتر وforward لحماية الأجهزة خلفه.
• القواعد من الأعلى إلى الأسفل وأول تطابق يفوز، والحزمة التي لا تطابق شيئاً تقبل، لذلك ينتهي كل جدار بإسقاط صريح.
• تتبع الاتصالات يعطي كل حزمة حالة، فتقبل established وrelated أولاً وتسقط invalid وتقرر في new فقط.
• dst-nat يحدث قبل التوجيه فالحزمة الموجهة تمر على forward، وsrcnat يحدث بعد الفلترة.
• FastTrack يسرع الحركة ويتجاوز الجدار والطوابير وIPsec، وتحقق من أنه يعمل فعلاً على جهازك.
• قواعد قوائم العناوين تبطئ تخمين كلمات المرور ولا تمنعه، والحل الأفضل VPN ومفاتيح SSH.
• جدار IPv6 منفصل، وفي CHR كان فارغاً تماماً.

وفي المقال التالي بإذن الله سوف نستخدم كل ذلك في سيناريوهات حقيقية: شبكة ضيوف معزولة، وVLAN، وWireGuard، وتحديد السرعة، وأكثر من مزود إنترنت.

دليلMikroTik وRouterOS للمبتدئين: أول إعداد آمنتعرف على أجهزة MikroTik وتراخيص RouterOS، ثم قم بتأمين جهازك من أول دخول حتى لا يصبح جزءاً من شبكة مخترقة.دليلMikroTik في الواقع: سيناريوهات عملية للبيت والمكتبكيف تبني على RouterOS ما تحتاجه فعلاً في البيت والمكتب، من شبكة ضيوف معزولة إلى الوصول الآمن من الخارج عبر WireGuard.دليلأجهزة الشبكة في البيت والمكتب: ماذا يفعل كل جهاز؟نأخذ كل جهاز في شبكة البيت والمكتب على حدة، من المودم إلى ال Router وال Switch، ونعرف ماذا يفعل ولماذا تحتاجه.دليلBridge Mode: متى تجعل راوتر المزود مجرد مودملماذا يفشل توجيه المنافذ عندما تضع Router خاصاً بك خلف جهاز المزود، وكيف يحل وضع الجسر مشكلة ال Double NAT.دليلما هو NAT؟ شرح ترجمة العناوين وتوجيه المنافذلماذا تخرج كل أجهزة بيتك بعنوان عام واحد، وكيف يترجم ال Router العناوين، ولماذا يفشل توجيه المنافذ خلف CGNAT.دليلما هو VPN؟ الشبكة الخاصة الافتراضية من المشكلة إلى الأنواعلماذا تحتاج شبكة خاصة افتراضية VPN، وكيف تغلف حزمك وتشفرها داخل نفق، وأي نوع منها يناسب فريقك.

سجل التحديثات

• أكتوبر 2026: كتابة المقال على RouterOS 7.24.5 (stable)، مع مخرجات وعدادات حقيقية من CHR يعمل في QEMU داخل Docker.