> ## Content Index > Fetch the complete content index at: https://arabroot.io/llms.txt > Use this file to discover other available public pages before exploring further. # جدار الحماية Firewall في MikroTik RouterOS بالتفصيل - URL: https://arabroot.io/articles/جدار-الحماية-في-mikrotik-routeros-بالتفصيل/ - Published: 2026-10-06T11:30:00.000Z - Updated: 2026-10-09T09:44:00.000Z - Description: كيف تمر الحزمة داخل جدار الحماية في RouterOS، وكيف تكتب قواعد مرتبة تحمي الراوتر والشبكة خلفه دون أن تفقد الوصول إليه. - Author: فريق عرب رووت - Tags: الأدلة التقنية, الشبكات والبنية التحتية, الشبكات والوصول, هوم لاب, الاستضافة الذاتية في [المقال الأول](https://arabroot.io/articles/mikrotik-%D9%88-routeros-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-%D8%A7%D9%88%D9%84-%D8%A7%D8%B9%D8%AF%D8%A7%D8%AF-%D8%A7%D9%85%D9%86/) أغلقنا خدمات الإدارة وحصرنا SSH في الشبكة الداخلية، ثم حاولنا الدخول من جهة الإنترنت فرأينا أن الراوتر يقبل الاتصال ثم يغلقه، أي أن المنفذ ما زال يظهر مفتوحاً لكل من يفحص عنوانك، وأن أي خدمة جديدة تضيفها غداً سوف تكون مفتوحة للعالم حتى تتذكر أن تحصرها. والحل الذي يغلق هذا الباب مرة واحدة هو الجدار الناري Firewall، ولكن الجدار الناري في RouterOS ليس قائمة منافذ مفتوحة ومغلقة كما في أجهزة البيت، وإنما جداول وسلاسل وحالات اتصال، ومن لا يفهم ترتيبها يكتب قاعدة صحيحة في المكان الخطأ فلا تعمل، أو يكتب قاعدة منع في أول القائمة فيغلق الجهاز على نفسه. المواضيع في السلسلة: 1. [MikroTik وRouterOS للمبتدئين](https://arabroot.io/articles/mikrotik-%D9%88-routeros-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-%D8%A7%D9%88%D9%84-%D8%A7%D8%B9%D8%AF%D8%A7%D8%AF-%D8%A7%D9%85%D9%86/): الأجهزة والتراخيص وWinBox، وأول إعداد آمن. 2. جدار الحماية في MikroTik RouterOS بالتفصيل: السلاسل وتتبع الاتصالات والقوائم وNAT (الموضوع الحالي). 3. [MikroTik في الواقع](https://arabroot.io/articles/mikrotik-%D9%81%D9%8A-%D8%A7%D9%84%D9%88%D8%A7%D9%82%D8%B9-%D8%B4%D8%A8%D9%83%D8%A9-%D8%A7%D9%84%D8%B6%D9%8A%D9%88%D9%81-%D9%88vlan-%D9%88%D8%A7%D9%84vpn-%D9%88%D8%AA%D9%88%D8%AC%D9%8A%D9%87-%D8%A7%D9%84%D9%85%D9%86%D8%A7%D9%81%D8%B0/): شبكة الضيوف و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؟ شرح للمبتدئين](https://arabroot.io/articles/%D9%85%D8%A7-%D9%87%D9%88-nat-%D8%B4%D8%B1%D8%AD-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/)، فهو يشرح الفكرة على Linux عموماً، وهنا نركز على ما يخص RouterOS. ## الجداول والسلاسل: أين تكتب القاعدة؟ الجدار الناري في RouterOS مقسم إلى جداول Tables، كل جدول له وظيفة، وفي كل جدول سلاسل Chains هي اللحظات التي يمر فيها الجدول على الحزمة، كما في [صفحة Firewall](https://manual.mikrotik.com/docs/firewall-and-quality-of-service/firewall/?ref=arabroot.io): | الجدول | وظيفته | سلاسله | | ------ | -------------------------------------------------------- | ----------------------------------------------- | | filter | السماح والمنع، وهو الجدار الناري الذي تعرفه | input وforward وoutput | | raw | المنع المبكر قبل تتبع الاتصالات، أو استثناء حركة منه | prerouting وoutput | | nat | ترجمة العناوين والمنافذ | srcnat وdstnat | | mangle | وضع علامات Marks على الحزم والاتصالات، وتعديل بعض الحقول | prerouting وinput وforward وoutput وpostrouting | وأهم ثلاث سلاسل في جدول filter هي: - **input:** الحزم الموجهة إلى الراوتر نفسه، مثل SSH وWinBox وDNS إلى الراوتر، وهي التي تحمي الجهاز. - **forward:** الحزم التي تمر عبر الراوتر من شبكة إلى أخرى، مثل حاسوبك وهو يتصفح الإنترنت، وهي التي تحمي الأجهزة خلفه. - **output:** الحزم التي ينشئها الراوتر نفسه، مثل تحديث النظام أو استعلام NTP، ونادراً ما تحتاج إلى قواعد فيها. وهناك جملة واحدة في التوثيق يجب أن تحفظها قبل أن تكتب أي قاعدة: القواعد تقرأ من الأعلى إلى الأسفل، وأول قاعدة تطابق الحزمة ينفذ إجراؤها ولا تكمل الحزمة بقية السلسلة، و**إذا لم تطابق الحزمة أي قاعدة فإنها تقبل**. أي أن السياسة الافتراضية في RouterOS هي القبول، وهذا ما رأيناه في CHR بجدول فارغ وكل الخدمات مفتوحة، ولذلك فإن كل جدار ناري صحيح في RouterOS ينتهي بقاعدة منع صريحة. ## طريق الحزمة داخل الراوتر MikroTik تنشر مخططاً مفصلاً اسمه [Packet Flow in RouterOS](https://manual.mikrotik.com/docs/firewall-and-quality-of-service/packet-flow-in-routeros?ref=arabroot.io) فيه كل مرحلة تمر بها الحزمة، ورسمنا منه في الصورة التالية الطرق الثلاثة التي تهمك: ![مخطط يبين حزمة تدخل من الواجهة وتمر في prerouting على raw ثم تتبع الاتصالات ثم mangle ثم dstnat، ثم قرار التوجيه، فإذا كانت للراوتر تذهب إلى mangle input ثم filter input ثم إلى عملية في الراوتر، وإذا كانت عابرة تذهب إلى mangle forward ثم filter forward ثم postrouting على mangle ثم srcnat ثم تخرج، والحزم التي ينشئها الراوتر تمر على raw output وmangle output وfilter output ثم postrouting، والحزم التي عليها علامة FastTrack تقفز من الدخول إلى الخروج متجاوزة أغلب المراحل](https://arabroot.io/content/images/2026/10/mikrotik-firewall-01-packet-flow.webp) كل حزمة تمر على dstnat قبل قرار التوجيه، وعلى srcnat بعد الفلترة، وهذا يحدد أين تكتب كل قاعدة في الرسم أعلاه لاحظ التالي: 1. الحزمة تمر على جدول raw أولاً ثم على تتبع الاتصالات، ولذلك فإن raw هو المكان الوحيد الذي تسقط فيه حزمة قبل أن تأخذ مكاناً في جدول الاتصالات، أو تستثنيها منه. 2. ترجمة الوجهة dstnat تحدث قبل قرار التوجيه Routing Decision، لأن الراوتر يجب أن يعرف الوجهة الحقيقية حتى يقرر هل الحزمة له أم لجهاز خلفه، ولهذا فإن الحزمة التي وجهت بتوجيه المنافذ تصل إلى سلسلة forward وليس input. 3. ترجمة المصدر srcnat تحدث في النهاية بعد الفلترة، لذلك ترى قواعد forward العناوين الداخلية الأصلية للأجهزة، وليس عنوان الراوتر العام. 4. الحزم التي تنتمي لاتصال عليه علامة FastTrack تتجاوز أغلب هذه المراحل، وسوف نعود إلى ذلك. ## حالات الاتصال: لماذا لا تفحص كل حزمة من جديد؟ تتبع الاتصالات Connection Tracking هو جزء النواة الذي يتذكر كل اتصال يمر عبر الراوتر، وقد شرحنا فكرته في [جدول الاتصالات في مقال NAT](https://arabroot.io/articles/%D9%85%D8%A7-%D9%87%D9%88-nat-%D8%B4%D8%B1%D8%AD-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/#conntrack)، وما يهمنا هنا أن كل حزمة تأخذ حالة State من خمس حالات حسب [صفحة Connection Tracking](https://manual.mikrotik.com/docs/firewall-and-quality-of-service/connection-tracking?ref=arabroot.io)، والصورة التالية تبينها: ![مخطط يبين حالات الاتصال الخمس: new لأول حزمة في اتصال جديد مثل SYN، وestablished للحزم التي تنتمي لاتصال معروف في الجدول، وrelated لحزمة تخص اتصالاً معروفاً مثل رسالة ICMP عن خطأ أو اتصال بيانات FTP، وinvalid لحزمة لا تنتمي لأي اتصال ولا تبدأ اتصالاً صحيحاً فتسقط، وuntracked لحزمة استثنيت من التتبع في جدول raw](https://arabroot.io/content/images/2026/10/mikrotik-firewall-02-conntrack-states.webp) الجدار الناري الحديث يقرر مرة واحدة عند new، ثم يقبل established وrelated بقاعدة واحدة سريعة - **new:** أول حزمة في اتصال جديد، مثل حزمة SYN في TCP، أو أول حزمة UDP لا يوجد لها سجل. - **established:** حزمة تنتمي لاتصال موجود في الجدول. - **related:** حزمة جديدة ولكنها مرتبطة باتصال موجود، مثل رسالة ICMP تخبرك أن الوجهة غير موجودة، أو اتصال البيانات في FTP. - **invalid:** حزمة لا تنتمي لأي اتصال ولا تبدأ اتصالاً صحيحاً، وفي أغلب الحالات يجب أن تسقط. - **untracked:** حزمة استثنيتها من التتبع بقاعدة في جدول raw، فلا يعرف عنها الجدول شيئاً. وفكرة الجدار الناري الحديث كلها مبنية على هذه الحالات: تقبل established وrelated في أول القائمة بقاعدة واحدة، لأنها اتصالات قررت السماح بها من قبل، وتسقط invalid، ثم تكتب القواعد المفصلة للحالة new فقط، وبهذا تمر أغلب الحزم على قاعدة واحدة بدلاً من القائمة كلها. ولكن التوثيق يحذر من حالة واحدة: إذا كانت شبكتك فيها توجيه غير متماثل Asymmetric Routing، أي أن الذهاب يمر من راوتر والعودة من آخر، فإن الراوتر لا يرى إلا نصف الاتصال ويعتبر حزمه invalid، فلا تستخدم قاعدة إسقاط invalid في مثل هذه الشبكة. وجدول الاتصالات له حجم أقصى يعتمد على ذاكرة الجهاز، وهذه إعداداته في CHR الذي يعمل في مختبرنا بذاكرة 256 ميغابايت: ```text [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 المفتوح يبقى في الجدول يوماً كاملاً إذا لم تمر فيه حزمة، وهذا ما يجعل الجدول يمتلئ في الشبكات الكبيرة، وقد شرحنا أعراض امتلائه في [امتلاء جدول الاتصالات](https://arabroot.io/articles/%D9%85%D8%A7-%D9%87%D9%88-nat-%D8%B4%D8%B1%D8%AD-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/#conntrack-full) وكيف تراقبه على Linux في [قسم conntrack](https://arabroot.io/articles/%D8%AA%D8%AD%D9%84%D9%8A%D9%84-%D8%A7%D8%AF%D8%A7%D8%A1-%D8%B3%D9%8A%D8%B1%D9%81%D8%B1-linux-%D9%81%D9%8A-60-%D8%AB%D8%A7%D9%86%D9%8A%D8%A9/#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](https://manual.mikrotik.com/docs/firewall-and-quality-of-service/firewall/address-lists?ref=arabroot.io). والمدخلات تأتي من ثلاثة مصادر: أنت تضيفها، أو قاعدة في الجدار الناري تضيفها بالإجراء `add-src-to-address-list` مع مدة انتهاء Timeout، أو تضع اسم نطاق مثل اسم DDNS لمكتبك فيحله الراوتر إلى عنوان ويحدثه عندما يتغير. ولاحظ أن المدخلات التي لها مدة انتهاء ديناميكية، فلا تحفظ في الإعداد وتختفي بعد إعادة التشغيل. ### الإجراءات Actions كل قاعدة تنتهي بإجراء، وأهمها حسب [مرجع /ip firewall filter](https://manual.mikrotik.com/docs/cli-reference/ip/firewall/filter/?ref=arabroot.io): | الإجراء | ما يفعله | هل تكمل الحزمة السلسلة؟ | | ----------------------- | ---------------------------------------------------- | ----------------------- | | accept | يقبل الحزمة | لا | | drop | يسقط الحزمة بصمت، فينتظر المرسل حتى تنتهي المهلة | لا | | reject | يسقطها ويرد برسالة ICMP أو TCP reset حسب reject-with | لا | | fasttrack-connection | يضع علامة FastTrack على الاتصال | نعم، لذلك يتبعه accept | | jump وreturn | ينتقل إلى سلسلة تنشئها أنت، ثم يعود منها | حسب ما في السلسلة | | add-src-to-address-list | يضيف عنوان المصدر إلى قائمة لمدة محددة | نعم | | log وpassthrough | يسجل الحزمة أو يعدها فقط | نعم | وقد يتساءل البعض: هل أستخدم drop أم reject؟ والإجابة أن drop هو المناسب لما يأتي من الإنترنت، لأنه لا يعطي من يفحص عنوانك أي معلومة ولا يستهلك منك ردوداً، أما reject فيناسب الشبكة الداخلية، لأن البرنامج الذي منعته يعرف فوراً أن الطريق مغلق بدلاً من أن ينتظر المهلة. ## ترتيب القواعد: أول قاعدة تطابق تفوز الصورة التالية تبين حزمتين تمران على سلسلة input نفسها، واحدة من الشبكة الداخلية وأخرى من الإنترنت: ![مخطط يبين قواعد سلسلة input بالترتيب: قبول established وrelated وuntracked، ثم إسقاط invalid، ثم قبول ICMP، ثم إسقاط كل ما لا يأتي من LAN، وحزمة SSH جديدة من الشبكة الداخلية تمر على القواعد الثلاث الأولى دون تطابق وتتجاوز قاعدة الإسقاط لأنها من LAN فتقبل بالسياسة الافتراضية، وحزمة SSH جديدة من الإنترنت تطابق قاعدة الإسقاط الأخيرة وتسقط، وقاعدة قبول SSH من WAN لو وضعت بعد الإسقاط لن تصل إليها أي حزمة](https://arabroot.io/content/images/2026/10/mikrotik-firewall-03-rule-order.webp) القاعدة التي توضع بعد قاعدة إسقاط عامة لا تصل إليها أي حزمة، مهما كانت صحيحة والخطأ الأكثر تكراراً أن تضيف قاعدة قبول بالأمر `add` فتذهب إلى آخر القائمة، بعد قاعدة الإسقاط العامة، فلا تعمل أبداً، لذلك استخدم `place-before` لتضع القاعدة في مكانها، مثل `place-before=[find comment="input: drop all not coming from LAN"]`، وهذا سبب آخر لكتابة تعليق Comment واضح على كل قاعدة. ## مجموعة القواعد الأساسية القواعد التالية هي جوهر الإعداد الافتراضي الذي تأتي به أجهزة البيت، وتشرحه MikroTik في [Securing your router](https://manual.mikrotik.com/docs/getting-started/securing-your-router?ref=arabroot.io) وفي [Building Advanced Firewall](https://manual.mikrotik.com/docs/firewall-and-quality-of-service/user-guides/building-advanced-firewall?ref=arabroot.io) الذي يصف الجدار العادي بأنه يقبل established وrelated وuntracked ويسقط كل ما لا يأتي من LAN. وكتبناها في ملف `fw.rsc` بتعليقات خاصة بنا، ونقلناه إلى CHR ثم استوردناه بالأمر `/import file-name=fw.rsc`: ```text /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 في العتاد، فحذفناها في المختبر. والمخرج بعد الاستيراد سوف يكون كما يلي: ```text [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، ثم طبعنا العدادات: ```text [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](https://arabroot.io/articles/%D9%85%D8%A7-%D9%87%D9%88-nat-%D8%B4%D8%B1%D8%AD-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/#how-nat-works). - قاعدتا 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](https://manual.mikrotik.com/docs/firewall-and-quality-of-service/connection-tracking?ref=arabroot.io): الحزم في هذا الطريق تتجاوز الجدار الناري، وتتبع الاتصالات، والطوابير البسيطة Simple Queues، وQueue Tree المربوط ب global، ومحاسبة IP، وIPsec، وتوجيه VRF. وهذا يعني عملياً: - إذا وضعت Simple Queue لتحديد سرعة جهاز، ولم تستثنه من FastTrack، فقد لا يعمل التحديد. - إذا كان عندك نفق IPsec، فيجب أن تقبل حركته قبل قاعدة FastTrack، وهذا سبب قاعدتي IPsec في الإعداد الافتراضي. - FastTrack يعمل مع جدول التوجيه الرئيسي main فقط، فإذا كنت توجه بعض الحركة بجداول أخرى عبر علامات mangle فلا تضع عليها FastTrack. - FastTrack يخص IPv4 فقط، وTCP وUDP فقط. والطريقة التي يقترحها التوثيق لاستثناء جهاز هي قاعدة قبول له قبل قاعدة FastTrack، فلا يصل اتصاله إليها: ```text /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 على صفر في مختبرنا، فقد سألنا الراوتر نفسه: ```text [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](https://manual.mikrotik.com/docs/firewall-and-quality-of-service/firewall/nat?ref=arabroot.io) أن masquerade يأخذ عنوان الواجهة الخارجة وقت الترجمة، وعندما تنقطع الواجهة أو يتغير عنوانها يحذف كل الاتصالات المترجمة عليها من الجدول، وهذا مناسب لعنوان يتغير مع DHCP أو PPPoE. أما `src-nat` فتكتب فيه العنوان بنفسك `to-addresses=...`، والاتصالات تبقى بعد انقطاع قصير، وهو المناسب عندما يكون عنوانك العام ثابتاً. والتوثيق يذكر مشكلة مع masquerade في الشبكات التي فيها أكثر من مزود: عندما ينقطع المزود الأول ثم يعود، قد تخرج حزم اتصالات قديمة عبره دون ترجمة فتتسرب العناوين الداخلية، والحل الذي يقترحه مسار احتياطي من نوع blackhole، وسوف نذكره مع أكثر من مزود في [المقال الثالث](https://arabroot.io/articles/mikrotik-%D9%81%D9%8A-%D8%A7%D9%84%D9%88%D8%A7%D9%82%D8%B9-%D8%B4%D8%A8%D9%83%D8%A9-%D8%A7%D9%84%D8%B6%D9%8A%D9%88%D9%81-%D9%88vlan-%D9%88%D8%A7%D9%84vpn-%D9%88%D8%AA%D9%88%D8%AC%D9%8A%D9%87-%D8%A7%D9%84%D9%85%D9%86%D8%A7%D9%81%D8%B0/). ### توجيه المنافذ بـ dst-nat الصورة التالية تبين ما يحدث لحزمة تصل إلى عنوانك العام على منفذ وجهته إلى سيرفر داخلي، ومعها حالة Hairpin NAT التي سوف نشرحها بعد قليل: ![مخطط يبين ثلاث حالات: خروج جهاز داخلي 192.168.88.10 إلى الإنترنت مع masquerade يغير المصدر إلى عنوان WAN، ودخول اتصال من الإنترنت إلى عنوان WAN على المنفذ 8443 يغير dst-nat وجهته إلى السيرفر الداخلي 192.168.88.10 على المنفذ 8000 ثم يمر على سلسلة forward، وجهاز داخلي يطلب العنوان العام نفسه فيرد السيرفر عليه مباشرة دون المرور بالراوتر فيرفض الرد، والحل قاعدة Hairpin NAT تغير المصدر إلى عنوان الراوتر](https://arabroot.io/content/images/2026/10/mikrotik-firewall-04-nat.webp) dst-nat يغير الوجهة قبل التوجيه، والرد يعود بالطريق نفسه، إلا إذا كان الطالب في الشبكة نفسها وفي المختبر شغلنا سيرفر ويب صغير على الجهاز الداخلي `192.168.88.10` بالمنفذ 8000، ثم أضفنا قاعدة توجه المنفذ 8443 القادم من WAN إليه: ```text /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 مرتين، والمخرج سوف يكون كما يلي: ```text 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: ```text [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 بالطريقة الصحيحة](https://arabroot.io/articles/%D8%AA%D8%B4%D8%BA%D9%8A%D9%84-%D8%AE%D8%A7%D8%AF%D9%85%D9%83-%D9%85%D9%86-%D8%A5%D9%86%D8%AA%D8%B1%D9%86%D8%AA-%D8%A7%D9%84%D9%85%D9%86%D8%B2%D9%84/#port-forwarding). ### Hairpin NAT: عندما تطلب عنوانك العام من داخل البيت إذا فتحت الموقع من حاسوب داخل البيت باستخدام اسم النطاق الذي يشير إلى عنوانك العام، فإن الراوتر يغير الوجهة إلى السيرفر، ولكن السيرفر يرى أن الطالب في شبكته نفسها فيرد عليه مباشرة، والحاسوب يرفض رداً يأتي من عنوان لم يطلبه، فيفشل الاتصال. وقد شرحنا هذه الحالة بالتفصيل في [Hairpin NAT في مقال NAT](https://arabroot.io/articles/%D9%85%D8%A7-%D9%87%D9%88-nat-%D8%B4%D8%B1%D8%AD-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/#hairpin)، والحل في RouterOS قاعدة srcnat تجعل الاتصال الداخلي يبدو كأنه من الراوتر، وهذا مثال التوثيق كما هو، حيث `10.0.0.3` هو السيرفر و`10.0.0.0/24` هي الشبكة الداخلية: ```text /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](https://manual.mikrotik.com/docs/firewall-and-quality-of-service/firewall/address-lists?ref=arabroot.io) أن تضع في قائمة كل مصدر يحاول الوصول إلى منفذ Telnet على عنوانك العام، لأن من يطرق هذا المنفذ يبحث في الغالب عن أجهزة ضعيفة، ثم تسقط كل حركته في raw. وفي [Building Advanced Firewall](https://manual.mikrotik.com/docs/firewall-and-quality-of-service/user-guides/building-advanced-firewall?ref=arabroot.io) تجد مثالاً كاملاً يسقط في raw العناوين التي لا يجب أن تأتي من الإنترنت أصلاً، مثل العناوين الخاصة ونطاقات التوثيق، وهذا جزء منه كما هو: ```text /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](https://arabroot.io/articles/%D9%88%D8%B6%D8%B9-%D8%A7%D9%84%D8%AC%D8%B3%D8%B1-bridge-mode-%D9%84%D8%B1%D8%A7%D9%88%D8%AA%D8%B1-%D8%A7%D9%84%D9%85%D8%B2%D9%88%D8%AF/#double-nat). ## الحماية من تخمين كلمات المرور بقوائم العناوين الحل الأفضل أن تبقى SSH وWinBox مغلقة من الإنترنت وتصل إليهما عبر VPN، ولكن إذا كان لا بد من فتح SSH، فإن [صفحة Bruteforce Prevention](https://manual.mikrotik.com/docs/firewall-and-quality-of-service/user-guides/bruteforce-prevention?ref=arabroot.io) تقترح قواعد تنقل كل مصدر بين ثلاث قوائم مع كل اتصال جديد، ثم تضعه في قائمة سوداء ليوم كامل عند الاتصال الرابع، والصورة التالية تبين المراحل: ![مخطط يبين أربع محاولات اتصال SSH من المصدر نفسه: الأولى تضعه في القائمة connection1 لمدة خمس دقائق، والثانية خلال خمس دقائق تنقله إلى connection2 لمدة 15 دقيقة، والثالثة خلال 15 دقيقة تنقله إلى connection3 لمدة ساعة، والرابعة خلال ساعة تضعه في bruteforce_blacklist لمدة يوم وتسقط الاتصال](https://arabroot.io/content/images/2026/10/mikrotik-firewall-05-bruteforce.webp) كل اتصال جديد ينقل المصدر مرحلة، والمراحل بمدد متزايدة حتى لا يفلت المهاجم الصبور بسهولة وطبقنا القواعد كما هي في التوثيق، مع تغيير اسم قاعدة الإسقاط إلى الاسم الذي استخدمناه: ```text /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 بمفتاح صحيح، والمخرج سوف يكون كما يلي: ```text --- 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](https://manual.mikrotik.com/docs/getting-started/configuration-management/default-configurations?ref=arabroot.io)، أما CHR فهذا ما وجدناه فيه بعد أن كتبنا جدار IPv4 كاملاً: ```text [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](https://manual.mikrotik.com/docs/firewall-and-quality-of-service/user-guides/building-advanced-firewall?ref=arabroot.io) أطول قليلاً من IPv4، لأن IPv6 يحتاج ICMPv6 ليعمل أصلاً، ويحتاج منفذ DHCPv6 لاستلام النطاق من المزود: ```text /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` وبادئة تعرفها بها في السجل: ```text /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، والمخرج سوف يكون كما يلي: ```text 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 كما في [المقال الأول](https://arabroot.io/articles/mikrotik-%D9%88-routeros-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-%D8%A7%D9%88%D9%84-%D8%A7%D8%B9%D8%AF%D8%A7%D8%AF-%D8%A7%D9%85%D9%86/#safe-mode). - **كتابة in-interface=ether1 بدلاً من القائمة:** فإذا انتقلت إلى PPPoE بقيت الواجهة الجديدة دون حماية. - **نسيان IPv6:** جدار IPv4 كامل وجدار IPv6 فارغ يعني أن الباب مفتوح من الجهة الأخرى. - **Simple Queue لا يعمل مع FastTrack:** استثن الأجهزة التي تحدد سرعتها، أو أطفئ FastTrack إذا كانت الطوابير أهم لك من السرعة. - **توجيه منفذ دون قاعدة forward:** في الإعداد الافتراضي القاعدة `connection-nat-state=!dstnat` تسمح بما وجهته تلقائياً، ولكن إذا كتبت جداراً صارماً بنفسك فيجب أن تسمح بالحركة الموجهة في forward، كما ينبه [First Time Configuration](https://manual.mikrotik.com/docs/getting-started/first-time-configuration?ref=arabroot.io). - **جعل الراوتر سيرفر 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، وتحديد السرعة، وأكثر من مزود إنترنت. [![](https://arabroot.io/content/images/2026/10/mikrotik-basics-cover-cover.webp)دليلMikroTik وRouterOS للمبتدئين: أول إعداد آمنتعرف على أجهزة MikroTik وتراخيص RouterOS، ثم قم بتأمين جهازك من أول دخول حتى لا يصبح جزءاً من شبكة مخترقة.](https://arabroot.io/articles/mikrotik-%D9%88-routeros-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-%D8%A7%D9%88%D9%84-%D8%A7%D8%B9%D8%AF%D8%A7%D8%AF-%D8%A7%D9%85%D9%86/)[![](https://arabroot.io/content/images/2026/10/mikrotik-scenarios-cover-cover.webp)دليلMikroTik في الواقع: سيناريوهات عملية للبيت والمكتبكيف تبني على RouterOS ما تحتاجه فعلاً في البيت والمكتب، من شبكة ضيوف معزولة إلى الوصول الآمن من الخارج عبر WireGuard.](https://arabroot.io/articles/mikrotik-%D9%81%D9%8A-%D8%A7%D9%84%D9%88%D8%A7%D9%82%D8%B9-%D8%B4%D8%A8%D9%83%D8%A9-%D8%A7%D9%84%D8%B6%D9%8A%D9%88%D9%81-%D9%88vlan-%D9%88%D8%A7%D9%84vpn-%D9%88%D8%AA%D9%88%D8%AC%D9%8A%D9%87-%D8%A7%D9%84%D9%85%D9%86%D8%A7%D9%81%D8%B0/)[![](https://arabroot.io/content/images/2026/10/network-devices-cover-cover.webp)دليلأجهزة الشبكة في البيت والمكتب: ماذا يفعل كل جهاز؟نأخذ كل جهاز في شبكة البيت والمكتب على حدة، من المودم إلى ال Router وال Switch، ونعرف ماذا يفعل ولماذا تحتاجه.](https://arabroot.io/articles/%D8%A7%D9%84%D9%85%D9%88%D8%AF%D9%85-%D9%88%D8%A7%D9%84%D8%B1%D8%A7%D9%88%D8%AA%D8%B1-%D9%88%D8%A7%D9%84%D8%B3%D9%88%D9%8A%D8%AA%D8%B4-%D9%85%D8%A7-%D8%A7%D9%84%D9%81%D8%B1%D9%82-%D8%A8%D9%8A%D9%86%D9%87%D8%A7/)[![](https://arabroot.io/content/images/2026/10/bridge-mode-cover-cover.webp)دليلBridge Mode: متى تجعل راوتر المزود مجرد مودملماذا يفشل توجيه المنافذ عندما تضع Router خاصاً بك خلف جهاز المزود، وكيف يحل وضع الجسر مشكلة ال Double NAT.](https://arabroot.io/articles/%D9%88%D8%B6%D8%B9-%D8%A7%D9%84%D8%AC%D8%B3%D8%B1-bridge-mode-%D9%84%D8%B1%D8%A7%D9%88%D8%AA%D8%B1-%D8%A7%D9%84%D9%85%D8%B2%D9%88%D8%AF/)[![](https://arabroot.io/content/images/2026/10/nat-explained-cover-cover.webp)دليلما هو NAT؟ شرح ترجمة العناوين وتوجيه المنافذلماذا تخرج كل أجهزة بيتك بعنوان عام واحد، وكيف يترجم ال Router العناوين، ولماذا يفشل توجيه المنافذ خلف CGNAT.](https://arabroot.io/articles/%D9%85%D8%A7-%D9%87%D9%88-nat-%D8%B4%D8%B1%D8%AD-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/)[![](https://arabroot.io/content/images/2026/10/vpn-basics-cover-cover.webp)دليلما هو VPN؟ الشبكة الخاصة الافتراضية من المشكلة إلى الأنواعلماذا تحتاج شبكة خاصة افتراضية VPN، وكيف تغلف حزمك وتشفرها داخل نفق، وأي نوع منها يناسب فريقك.](https://arabroot.io/articles/%D9%85%D8%A7-%D9%87%D9%88-vpn-%D8%B4%D8%B1%D8%AD-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/) ## سجل التحديثات - أكتوبر 2026: كتابة المقال على RouterOS 7.24.5 (stable)، مع مخرجات وعدادات حقيقية من CHR يعمل في QEMU داخل Docker.