رفع مشکل نگرفتن IP بعد از فعال‌سازی DHCP Snooping در MikroTik RouterOS | راهنمای کامل عیب‌یابی
میکروتیک

رفع مشکل نگرفتن IP بعد از فعال‌سازی DHCP Snooping در MikroTik RouterOS | راهنمای کامل عیب‌یابی

رفع مشکل نگرفتن IP بعد از فعال‌سازی DHCP Snooping در MikroTik RouterOS | راهنمای کامل عیب‌یابی

اگر بعد از فعال‌سازی DHCP Snooping روی میکروتیک، کلاینت‌ها دیگر IP نمی‌گیرند یا آدرس‌های عجیب 169.254.x.x دریافت می‌کنند، این مقاله دقیقاً برای شماست. DHCP Snooping یکی از مهم‌ترین ویژگی‌های امنیتی Layer 2 در RouterOS است که از شبکه در برابر Rogue DHCP Server محافظت می‌کند، اما اگر پیکربندی آن اشتباه باشد، می‌تواند باعث قطع کامل سرویس DHCP شود.

⚠️ هشدار مهم: DHCP Snooping به‌صورت پیش‌فرض تمام پورت‌های bridge را untrusted در نظر می‌گیرد. اگر پورت متصل به DHCP Server را trusted نکنید، تمام پاسخ‌های DHCP (DHCPOFFER و DHCPACK) حذف می‌شوند و هیچ کلاینتی IP نخواهد گرفت.

DHCP Snooping چیست و چرا باعث مشکل می‌شود؟

DHCP Snooping یک ویژگی امنیتی Layer 2 است که در RouterOS از نسخه 6.43 به بعد در bridge پشتیبانی می‌شود. این ویژگی پورت‌های bridge را به دو دسته تقسیم می‌کند [citation:8]:

🔹 Trusted (قابل اعتماد): پورت‌هایی که DHCP Server معتبر به آن‌ها متصل است. پاسخ‌های DHCP از این پورت‌ها عبور می‌کنند.

🔹 Untrusted (غیرقابل اعتماد): پورت‌های کلاینت که به‌صورت پیش‌فرض همه پورت‌ها در این دسته قرار می‌گیرند. پاسخ‌های DHCP از این پورت‌ها حذف می‌شوند.

مشکل اصلی اینجاست: اگر پورت متصل به DHCP Server (یا روتر بالادستی که IP می‌دهد) را trusted نکنید، تمام بسته‌های DHCPOFFER و DHCPACK حذف می‌شوند. نتیجه این می‌شود که کلاینت درخواست DHCPDISCOVER می‌فرستد، اما هیچ پاسخی دریافت نمی‌کند و مجبور می‌شود به آدرس خودکار 169.254.x.x (APIPA) پناه ببرد.

علائم و نشانه‌های مشکل DHCP Snooping

🔹 کلاینت‌ها آدرس 169.254.x.x می‌گیرند به‌جای IP معتبر

🔹 کلاینت‌ها اصلاً IP نمی‌گیرند و وضعیت DHCP Client در حالت searching باقی می‌ماند

🔹 در لاگ روتر پیام‌های مربوط به DHCP Snooping مشاهده می‌شود

🔹 فقط کلاینت‌هایی که مستقیم به روتر وصل هستند IP می‌گیرند، ولی کلاینت‌های متصل به سوییچ نه

🔹 تجهیزات IPTV یا برخی دستگاه‌های خاص IP نمی‌گیرند در حالی که کامپیوترها مشکلی ندارند [citation:20]

۵ روش تشخیص و رفع مشکل DHCP Snooping در MikroTik

روش ۱: بررسی Trusted بودن پورت DHCP Server (مهم‌ترین راه‌حل)

اولین و شایع‌ترین دلیل مشکل، trusted نبودن پورت uplink است. دستور زیر را در ترمینال RouterOS اجرا کنید تا وضعیت فعلی را ببینید:

/interface bridge port print where trusted=yes

اگر خروجی خالی بود، یعنی هیچ پورتی trusted نیست. حالا باید پورت متصل به DHCP Server یا روتر بالادستی را trusted کنید. فرض کنید پورت uplink شما ether1 است:

/interface bridge port set [find interface=ether1] trusted=yes

📌 نکته: فقط پورت‌هایی که DHCP Server معتبر به آن‌ها متصل است باید trusted باشند. هرگز پورت‌های کلاینت را trusted نکنید، چون هدف DHCP Snooping همین است که پاسخ‌های DHCP از پورت‌های کلاینت را مسدود کند [citation:8][citation:13].

روش ۲: بررسی فعال بودن DHCP Snooping روی Bridge

مطمئن شوید که DHCP Snooping واقعاً روی bridge فعال شده است. دستور زیر را اجرا کنید:

/interface bridge print detail where dhcp-snooping=yes

اگر خروجی خالی بود، DHCP Snooping فعال نیست. برای فعال‌سازی روی bridge (مثلاً bridge1):

/interface bridge set bridge1 dhcp-snooping=yes

نکته مهم: در RouterOS، DHCP Snooping در سطح bridge فعال می‌شود، نه در سطح پورت. اما trusted/untrusted در سطح پورت تنظیم می‌شود [citation:8].

روش ۳: بررسی تداخل با Hardware Offloading و VLAN

در برخی مدل‌های میکروتیک (به‌ویژه CRS1xx و CRS2xx)، DHCP Snooping با Hardware Offloading و VLAN Filtering تداخل دارد. اگر از VLAN استفاده می‌کنید و DHCP کار نمی‌کند، ممکن است مشکل از اینجا باشد [citation:18].

🔹 در CRS3xx و CRS5xx، DHCP Snooping به‌صورت کامل در سخت‌افزار پشتیبانی می‌شود.

🔹 در CRS1xx و CRS2xx، باید مطمئن شوید که بسته‌های DHCP با تگ VLAN صحیح ارسال می‌شوند.

🔹 در سایر دستگاه‌ها، اگر VLAN روی bridge تنظیم شده باشد، ممکن است DHCP Snooping به‌درستی کار نکند.

راه‌حل موقت: Hardware Offloading را روی bridge غیرفعال کنید و تست کنید که آیا مشکل حل می‌شود یا خیر:

/interface bridge set bridge1 hw-offload=no

⚠️ توجه: غیرفعال کردن Hardware Offloading باعث افزایش بار CPU می‌شود. این کار را فقط برای تست انجام دهید و در صورت حل مشکل، به‌دنبال راه‌حل پایدارتر (ارتقاء RouterOS یا تغییر مدل سوییچ) باشید.

روش ۴: بررسی Bridge Filter به‌جای DHCP Snooping

در برخی مدل‌های قدیمی‌تر میکروتیک (مثل RB2011) که DHCP Snooping در سخت‌افزار پشتیبانی نمی‌شود، می‌توانید از Bridge Filter استفاده کنید [citation:17]. این روش بار CPU بیشتری دارد اما مشکل را حل می‌کند:

/interface bridge filter
add action=drop chain=forward mac-protocol=ip ip-protocol=udp dst-port=67 out-bridge=bridge1 out-interface=!ether1

این قانون باعث می‌شود پاسخ‌های DHCP (پورت 67) از هر پورتی به‌جز پورت uplink (ether1) حذف شوند. به‌جای ether1 نام پورت uplink خود را قرار دهید.

روش ۵: بررسی لاگ‌ها و تشخیص Rogue DHCP Server

RouterOS هنگام شناسایی DHCP Server غیرمجاز روی پورت untrusted، رویداد را در لاگ ثبت می‌کند. برای بررسی:

/log print where topics~"dhcp"

اگر در لاگ پیام‌هایی مانند dhcp-snooping: untrusted port received DHCP reply مشاهده کردید، یعنی یک DHCP Server غیرمجاز روی پورت untrusted فعال است. این دقیقاً همان چیزی است که DHCP Snooping باید مسدود کند [citation:8].

📌 نکته: اگر DHCP Snooping درست کار کند، باید پاسخ‌های DHCP از پورت‌های untrusted مسدود شوند و تنها پورت trusted اجازه عبور داشته باشد. اگر برعکس عمل می‌کند، احتمالاً پورت‌ها را جابه‌جا تنظیم کرده‌اید.

چرا DHCP Snooping با Option 82 مشکل ایجاد می‌کند؟

DHCP Option 82 (Relay Agent Information) یک ویژگی مکمل DHCP Snooping است که اطلاعات پورت و سوییچ را به درخواست‌های DHCP اضافه می‌کند. این ویژگی برای ISPها و شبکه‌های بزرگ مفید است، اما در برخی سناریوها می‌تواند مشکل‌ساز شود [citation:8].

مشکلات رایج Option 82:

🔹 برخی دستگاه‌های IPTV یا سرویس‌های خاص با Option 82 سازگار نیستند و IP نمی‌گیرند [citation:20]

🔹 اگر DHCP Server با Option 82 سازگار نباشد، ممکن است درخواست را رد کند

🔹 در برخی نسخه‌های RouterOS، باگ‌هایی در نحوه اضافه کردن Option 82 وجود دارد که باعث حذف بسته‌ها می‌شود

برای غیرفعال کردن Option 82 (در حالی که DHCP Snooping فعال بماند):

/interface bridge set bridge1 add-dhcp-option82=no

جمع‌بندی و توصیه نهایی

مشکل نگرفتن IP بعد از فعال‌سازی DHCP Snooping در MikroTik معمولاً به یکی از این دلایل است:

راه‌حل ۱: پورت متصل به DHCP Server را trusted کنید

راه‌حل ۲: فعال بودن DHCP Snooping روی bridge را بررسی کنید

راه‌حل ۳: در صورت استفاده از VLAN، تداخل Hardware Offloading را بررسی کنید

راه‌حل ۴: در دستگاه‌های قدیمی از Bridge Filter استفاده کنید

راه‌حل ۵: لاگ‌ها را بررسی کنید تا Rogue DHCP Server را شناسایی کنید

نکته مهم: اگر مشکل با Option 82 دارید، آن را غیرفعال کنید

سوالات متداول (FAQ)

چرا بعد از فعال کردن DHCP Snooping کلاینت‌ها IP نمی‌گیرند؟

چون به‌صورت پیش‌فرض تمام پورت‌ها untrusted هستند و پاسخ‌های DHCP از پورت DHCP Server نیز حذف می‌شود. باید پورت uplink را trusted کنید [citation:8][citation:13].

آیا DHCP Snooping روی همه مدل‌های میکروتیک کار می‌کند؟

از RouterOS 6.43 به بعد روی bridge پشتیبانی می‌شود. اما فقط CRS3xx و CRS5xx به‌صورت کامل در سخت‌افزار پشتیبانی می‌کنند. در مدل‌های قدیمی‌تر ممکن است نیاز به Bridge Filter داشته باشید [citation:17][citation:18].

تفاوت trusted و untrusted در DHCP Snooping چیست؟

Trusted: پورتی که DHCP Server معتبر به آن متصل است و پاسخ‌های DHCP از آن عبور می‌کنند. Untrusted: پورت‌های کلاینت که پاسخ‌های DHCP از آن‌ها مسدود می‌شوند [citation:8].

آیا DHCP Snooping با DHCP Relay تداخل دارد؟

خیر، اما باید پورت متصل به DHCP Relay را trusted کنید. همچنین در برخی سناریوهای پیچیده، ممکن است نیاز به تنظیمات اضافی داشته باشید [citation:18].

چطور بفهمم Rogue DHCP Server در شبکه دارم؟

از دستور /log print where topics~”dhcp” استفاده کنید. اگر پیام‌های untrusted port received DHCP reply مشاهده کردید، یعنی یک DHCP Server غیرمجاز فعال است [citation:8].

🛠 مشکل DHCP یا RouterOS خود را به ما بسپارید

اگر در تنظیمات DHCP Snooping یا RouterOS با چالش مواجه شده‌اید، تیم فنی ایرانیکاسرور آماده کمک است. کافیست درخواست خود را ثبت کنید تا کارشناسان ما در سریع‌ترین زمان بررسی کنند.

🔹 ثبت درخواست کانفیگ و رفع مشکل

📞 تماس با پشتیبانی: 021-91302460 | ایرانیکاسرور

🎯 چالش آموزشی
مباحثی که در این مقاله یاد گرفتید را در عمل پیاده‌سازی کنید و نتیجه را با ما به اشتراک بگذارید.
شروع چالش

💬 دیدگاه‌ها 0

هنوز دیدگاهی ثبت نشده است. اولین نفری باشید که نظر می‌دهید!

✍️ دیدگاه خود را بنویسید