چرا DHCP Relay در MikroTik کار نمی‌کند؟ آموزش تنظیم بین VLAN و DHCP Server

اگر کلاینت‌های یک VLAN در MikroTik آی‌پی نمی‌گیرند اما DHCP Server در شبکه دیگری سالم است، معمولاً DHCP Broadcast از مرز روتر عبور نمی‌کند یا Relay روی Interface اشتباه قرار گرفته است. روی Interface لایه ۳ همان VLAN یک /ip dhcp-relay بسازید، dhcp-server را به IP سرور واقعی و local-address را به IP همان VLAN تنظیم کنید؛ سپس مسیر رفت‌وبرگشت، Scope متناظر و UDP 67/68 را بررسی کنید. این راهنما برای RouterOS v7 و DHCPv4 است و به‌معنی فعال‌کردن DHCP Server جدید روی هر VLAN نیست.

سناریوی واقعی: VLAN 20 به DHCP Server مرکزی نمی‌رسد

فرض کنید روی MikroTik، شبکه کاربران 192.168.20.0/24 در Interface به نام vlan20 با Gateway 192.168.20.1 قرار دارد؛ شبکه مهمان 192.168.30.0/24 در vlan30 با Gateway 192.168.30.1 است و DHCP Server مرکزی با IP 10.10.10.10 در یک شبکه مسیریابی‌شده قرار دارد. کاربر VLAN 20 درخواست DHCPDISCOVER می‌فرستد، اما Broadcast عادی از روتر عبور نمی‌کند؛ Relay درخواست را برای سرور Unicast می‌کند و اطلاعات شبکه مبدأ را منتقل می‌کند تا Scope درست انتخاب شود.

در این مثال نام Interfaceها و IPها فرضی‌اند؛ قبل از کپی‌کردن دستورات با ساختار واقعی شبکه جایگزینشان کنید. اگر DHCP Server روی همان Broadcast Domain است، معمولاً Relay لازم نیست؛ اگر RouterOS خودش DHCP Server آن VLAN است، Relay اضافی ممکن است باعث رفتار غیرمنتظره شود.

اگر DHCP Server مرکزی را در دیتاسنتر یا بین چند شعبه اجرا می‌کنید، بین MikroTik و سرور باید مسیر دوطرفه و امن داشته باشید و DHCP را روی اینترنت عمومی بدون طراحی شبکه مناسب در معرض دسترس قرار ندهید. برای استقرار سرویس‌های مرکزی در یک محیط مجازی می‌توانید سرور مجازی آلمان NVMe وان‌سرور را بررسی کنید؛ برای سناریوهایی که کنترل سخت‌افزار و شبکه بیشتری لازم دارند، سرور اختصاصی OVH وان‌سرور گزینه مرتبط‌تری است.

پیش‌نیازها و تهیه نسخه پشتیبان

• دسترسی WinBox/SSH با سطح مجاز، ترجیحاً کنسول یا Safe Mode؛ تغییرات را در پنجره نگهداری انجام دهید.
• Interface لایه ۳ VLAN و IP Gateway آن باید از قبل وجود داشته باشد. روی سوئیچ Trunk و VLAN tagging را بررسی کنید.
• DHCP Server مرکزی باید Scope فعال برای هر Subnet، آدرس Router Option و مسیر برگشت به Gateway داشته باشد.
• نام Interface، IP DHCP Server، Ruleهای Firewall و NAT فعلی را ثبت کنید؛ اگر شبکه تولیدی است قبل از تغییر، Export محدود و امن بگیرید.

/export file=before-dhcp-relay
/interface vlan print detail
/ip address print detail
/ip dhcp-relay print detail
/ip dhcp-server print detail
/ip route print detail

در حالت درست، vlan20 باید IP 192.168.20.1/24 داشته باشد؛ هیچ DHCP Server محلی ناخواسته روی همان Interface فعال نباشد. در RouterOS v7، خروجی /export به‌صورت پیش‌فرض اطلاعات حساس را پنهان می‌کند؛ برای این سناریو از show-sensitive استفاده نکنید. فایل Export را از روتر به محل امن منتقل کنید و اطلاعات حساس را عمومی نکنید.

مرحله ۱: اطمینان از سالم‌بودن VLAN و مسیر DHCP Server

ابتدا با دستورهای زیر وجود Interface و آدرس IP و رسیدن به سرور را بررسی کنید. اگر Interface لایه ۳ هنوز ایجاد نشده، Relay را فعلاً نسازید؛ ابتدا تنظیمات Bridge VLAN Filtering، Tagged/Untagged و PVID را مطابق طراحی شبکه اصلاح کنید.

/interface vlan print detail
/ip address print where interface=vlan20
/ping 10.10.10.10 src-address=192.168.20.1 count=4
/ip route print detail

در حالت سالم، Interface فعال باشد و برای DHCP Server یک مسیر معتبر وجود داشته باشد. پاسخ ندادن Ping به‌تنهایی ثابت نمی‌کند UDP 67 بسته است؛ بعضی سرورها ICMP را فیلتر می‌کنند. اگر Route/Rule/VRF مشکل دارد، راهنمای عیب‌یابی Policy Routing در MikroTik را نیز بررسی کنید.

مرحله ۲: ساخت DHCP Relay برای VLAN 20

Relay را روی Interface دریافت‌کننده Broadcast کلاینت ایجاد کنید، نه روی Interface متصل به سرور. IP local-address باید آدرس معتبر و قابل‌دسترسی همان Relay باشد؛ در سناریوی معمول، IP Gateway همان VLAN انتخاب مناسبی است.

/ip dhcp-relay add name=relay-vlan20 interface=vlan20 dhcp-server=10.10.10.10 local-address=192.168.20.1 disabled=no
/ip dhcp-relay print detail where name="relay-vlan20"

در خروجی باید interface=vlan20، dhcp-server=10.10.10.10، local-address=192.168.20.1 و disabled=no دیده شود. اگر Relay از قبل وجود دارد، مورد تکراری نسازید؛ ابتدا تنظیمات همان مورد را اصلاح کنید. مقدار 0.0.0.0 برای local-address ممکن است انتخاب خودکار داشته باشد، اما در شبکه چند VLAN بهتر است آدرس مورد انتظار را صریح تعیین کنید.

مرحله ۳: افزودن Relay جداگانه برای VLAN دوم

هر Broadcast Domain که باید از DHCP Server مرکزی سرویس بگیرد، به Relay متناسب با Interface و IP همان شبکه نیاز دارد. برای VLAN 30 در مثال ما:

/ip dhcp-relay add name=relay-vlan30 interface=vlan30 dhcp-server=10.10.10.10 local-address=192.168.30.1 disabled=no
/ip dhcp-relay print detail

اگر تنها VLAN 20 مشکل دارد، اضافه‌کردن VLAN 30 ضرورتی ندارد؛ دستور دوم صرفاً الگوی گسترش است. در VRFهای غیرپیش‌فرض، تنظیم dhcp-server-vrf (در نسخه‌های پشتیبانی‌شده RouterOS v7) و Routeهای VRF نیز باید بررسی شود؛ تغییر کورکورانه VRF در شبکه Production توصیه نمی‌شود.

مرحله ۴: بررسی DHCP Server مرکزی و Scope

وجود Relay کافی نیست: DHCP Server باید Subnet معرفی‌شده توسط Relay را بشناسد و بتواند پاسخ را به آدرس Relay برگرداند. در Windows Server، Scope مربوط به 192.168.20.0/24 و 192.168.30.0/24 باید فعال باشد؛ Router Option معمولاً به‌ترتیب 192.168.20.1 و 192.168.30.1 است. روی Windows Server دارای نقش DHCP، با PowerShell مجاز بررسی کنید:

Get-DhcpServerv4Scope -ComputerName 10.10.10.10
Get-DhcpServerv4ScopeStatistics -ComputerName 10.10.10.10

در صورت وجود Windows DHCP Server و دسترسی لازم، خروجی باید Scope فعال و ظرفیت Lease مناسب را نشان دهد. همچنین Authorization سرور در Active Directory، DHCP Policies و فیلترهای MAC را بررسی کنید. جزئیات تشخیص Scope و Lease در مقاله رفع مشکل DHCP در Windows Server و نگرفتن IP کلاینت آمده است.

اگر DHCP Server نیز MikroTik است، تنظیم relay در /ip dhcp-server و Pool/Network متناسب با Subnet را طبق مستندات رسمی DHCP RouterOS بررسی کنید؛ نمونه Windows Server را عیناً روی DHCP Server میکروتیک اعمال نکنید.

مرحله ۵: عیب‌یابی Firewall، UDP 67/68 و NAT

DHCPv4 از UDP 67 برای سمت سرور و UDP 68 برای سمت کلاینت استفاده می‌کند. روی روتر، درخواست Broadcast به خود Relay می‌رسد و سپس بسته‌های Unicast به سرور ارسال می‌شوند؛ بنابراین بسته به توپولوژی، Ruleهای input، output، forward و Firewall سرور باید متناسب با مسیر واقعی بررسی شوند. برای رفع مشکل، Firewall را کامل خاموش نکنید و Rule عمومی accept برای همه شبکه‌ها نسازید.

/ip firewall filter print detail
/ip firewall filter print stats
/ip firewall nat print detail
/ip firewall raw print detail

Counterهای Ruleهای Drop را هنگام Renew کلاینت مشاهده کنید. اگر یک Rule خاص جلوی DHCP Relay را می‌گیرد، تنها اجازه لازم با Source/Destination مشخص و UDP 67/68 را در جای درست زنجیره تعریف کنید. روی DHCP Server هم Firewall ورودی و مسیر برگشت را بررسی کنید. NAT نامناسب ممکن است تشخیص Subnet یا برگشت پاسخ را مختل کند؛ به‌جای خاموش‌کردن کلی NAT، مسیر و Match Rule را مستند و اصلاح کنید.

مرحله ۶: Packet Capture و تشخیص نقطه قطع ارتباط

برای جداسازی مشکل VLAN، Relay، مسیر یا سرور، هم‌زمان با اجرای Renew روی یک کلاینت آزمایشی ترافیک UDP 67/68 را در Interface VLAN و سمت سرور مشاهده کنید. در RouterOS ابزار Packet Sniffer وجود دارد؛ فیلترها را مطابق نسخه RouterOS و Interface واقعی تنظیم کنید. ابتدا خروجی‌های کم‌هزینه و وضعیت Relay را ببینید:

/ip dhcp-relay print detail
/log print where topics~"dhcp"
/tool sniffer quick ip-protocol=udp port=67,68

نتیجه را این‌طور بخوانید: اگر DHCPDISCOVER در سمت VLAN دیده نمی‌شود، مشکل احتمالاً قبل از Relay (Client، Switch، Trunk، VLAN tagging) است. اگر DISCOVER به Relay می‌رسد ولی در مسیر سرور دیده نمی‌شود، Interface/Relay/Route/Firewall را بررسی کنید. اگر درخواست به سرور می‌رسد ولی OFFER بازنمی‌گردد، Scope، Authorization، ACL و مسیر برگشت را بررسی کنید. اگر OFFER به Relay می‌رسد اما به کلاینت تحویل نمی‌شود، VLAN سمت کاربر و Ruleهای محلی را بازبینی کنید. Packet Capture می‌تواند داده حساس شبکه را نشان دهد؛ فایل را عمومی نکنید.

مرحله ۷: تست دریافت IP و Verify نهایی

روی یک کلاینت آزمایشی Windows، Lease را Renew کنید؛ اگر اتصال از راه دور است و احتمال قطع مدیریت وجود دارد، ابتدا روش دسترسی جایگزین آماده کنید:

ipconfig /release
ipconfig /renew
ipconfig /all
ping 192.168.20.1

در حالت درست، کلاینت VLAN 20 یک IP از محدوده 192.168.20.0/24، Gateway برابر 192.168.20.1 و DHCP Server مورد انتظار دریافت کند؛ آدرس 169.254.x.x نشانه نبود Lease معتبر است. بعد از Renew، در DHCP Server وجود Lease جدید را تأیید کنید و دسترسی DNS/Internet را جداگانه تست کنید؛ دریافت IP به‌تنهایی به معنی سالم‌بودن تمام مسیر شبکه نیست.

خطاهای رایج و راه‌حل دقیق هرکدام

Relay روی Interface اشتباه قرار گرفته است

Relay باید روی VLAN کاربران باشد، نه Interface سرور. در /ip dhcp-relay print detail نام Interface را با /interface vlan print detail تطبیق دهید؛ به‌ویژه در Bridge VLAN Filtering مطمئن شوید Interface VLAN به Bridge صحیح متصل است.

local-address اشتباه یا غیرقابل‌دسترسی است

سرور DHCP ممکن است بر اساس اطلاعات Relay، Scope نامناسب انتخاب کند یا نتواند پاسخ را برگرداند. IP مورد استفاده را با IP واقعی Gateway آن VLAN تطبیق دهید و Route برگشت را بررسی کنید.

Scope فعال نیست یا Pool تمام شده است

اگر DHCP Server درخواست را می‌بیند ولی Offer نمی‌دهد، وضعیت Scope، Lease، Exclusion و Policies را بررسی کنید. در Windows DHCP Server، Scope غیرفعال یا تمام‌شدن آدرس‌های قابل تخصیص را اصلاح کنید؛ بدون تحلیل، Leaseهای کاربران را حذف نکنید.

فایروال یا VRF مسیر پاسخ را قطع می‌کند

Ruleهای Drop، NAT، Policy Routing و VRF را بررسی کنید. اگر DHCP Server در VRF دیگری است، علاوه بر مسیر سرور، پارامتر dhcp-server-vrf و مسیرهای بازگشت را با نسخه RouterOS تطبیق دهید. برای تغییرات چندمسیره از چک‌لیست راه‌اندازی و عیب‌یابی تجهیزات شبکه کمک بگیرید.

امنیت، Rollback و Recovery

در شبکه تولیدی، تغییرات را با Safe Mode و Backup/Export انجام دهید و DHCP Server ناشناس را روی VLAN کاربران فعال نکنید. برای جلوگیری از Rogue DHCP، سیاست‌های DHCP Snooping در سوئیچ‌های پشتیبانی‌شده را جداگانه بررسی کنید. برای Rollback، اگر Relay جدید را فقط برای این آزمایش ساخته‌اید، ابتدا آن را Disable کنید و پس از Verify از روی روتر حذف کنید؛ اگر Relay از قبل وجود داشته، مقادیر قبلی Interface/Server/Local Address را از Export بازگردانید:

/ip dhcp-relay disable [find where name="relay-vlan20"]
/ip dhcp-relay print detail

این دستور تنها Relay با نام نمونه را غیرفعال می‌کند. اگر از نام دیگری استفاده کرده‌اید آن را جایگزین کنید. Rollback تنظیم DHCP روی سرور مرکزی جدا از MikroTik است؛ Scope یا Ruleهای Firewall را فقط مطابق نسخه پشتیبان خود برگردانید. پس از بازگشت، با Renew روی یک کلاینت آزمایشی، وضعیت پیشین را کنترل کنید.

چک‌لیست نهایی مدیر شبکه

• VLAN tagging و Interface لایه ۳ سالم است؛ Gateway VLAN IP معتبر دارد.
• Relay فقط روی VLAN موردنیاز قرار دارد و DHCP Server/Local Address درست‌اند.
• سرور مرکزی Scope فعال و Pool کافی برای Subnet معرفی‌شده دارد.
• Route رفت‌وبرگشت، Firewall و UDP 67/68 بررسی شده‌اند؛ NAT نامناسب وجود ندارد.
• Packet Capture زنجیره DISCOVER/OFFER/REQUEST/ACK را نشان می‌دهد و کلاینت Lease درست گرفته است.
• مقادیر قبلی ثبت شده‌اند و مسیر Rollback تست شده است.

منبع فنی اصلی: MikroTik RouterOS DHCP Server & DHCP Relay Manual. دستورات بر اساس DHCPv4 در RouterOS v7 نوشته شده‌اند؛ برای DHCPv6 Relay از مسیر و پورت‌های متفاوت استفاده می‌شود و این تنظیمات را نباید به آن تعمیم داد.