مشکل دقیقاً چیست؟

یکی از دردسرهای مهم مدیران شبکه زمانی اتفاق می‌افتد که یک MikroTik CHR روی VPS
بدون هیچ مشکلی کار می‌کند، سرویس‌هایی مانند WireGuard، EoIP، GRE، IPsec یا NAT
فعال هستند و ناگهان تصمیم می‌گیرید RouterOS را به نسخه جدید ارتقا دهید.
آپدیت انجام می‌شود، روتر Reboot می‌شود و بعد از بالا آمدن دیگر به IP عمومی آن
دسترسی ندارید.

در نگاه اول ممکن است تصور کنید RouterOS هنگام Upgrade تنظیمات را پاک کرده است؛
اما در بسیاری از موارد چنین اتفاقی نیفتاده است. ممکن است RouterOS کاملاً بالا
آمده باشد و حتی Configuration قبلی نیز سر جای خودش باشد، ولی سیستم‌عامل نتواند
Network Adapter مجازی ارائه‌شده توسط Hypervisor را همان‌طور که انتظار می‌رود
شناسایی یا استفاده کند.

این موضوع در CHR اهمیت بیشتری دارد، زیرا برخلاف یک روتر فیزیکی، کارت شبکه‌ای که
در RouterOS می‌بینید یک سخت‌افزار واقعی نیست. کارت شبکه توسط Hypervisor در اختیار
ماشین مجازی قرار می‌گیرد و RouterOS باید بتواند Driver و Virtual NIC مربوط به آن
را شناسایی کند.

MikroTik برای CHR محیط‌هایی مانند VMware، KVM/QEMU، Proxmox و Hyper-V را پشتیبانی
می‌کند و نوع کارت شبکه مجازی بسته به Hypervisor متفاوت است. در RouterOS v7 نیز
Fast Path برای Interfaceهای vmxnet3 و virtio-net
پشتیبانی می‌شود.

چرا بعد از آپدیت RouterOS شبکه CHR قطع می‌شود؟

یک دلیل واحد برای این مشکل وجود ندارد. عبارت «بعد از آپدیت شبکه قطع شد» فقط
زمان رخ دادن مشکل را مشخص می‌کند، نه علت آن را.

برای عیب‌یابی حرفه‌ای باید مشکل را به چند دسته تقسیم کنیم:

آیا این مشکل واقعاً در MikroTik CHR اتفاق افتاده است؟

بله. این موضوع صرفاً یک فرض تئوری نیست. در انجمن رسمی MikroTik گزارش‌هایی
منتشر شده که در آن کاربران پس از Upgrade نسخه‌های RouterOS، کارت‌های Ethernet
CHR را در بعضی محیط‌های مجازی از دست داده‌اند.

یکی از نمونه‌های شناخته‌شده مربوط به Upgrade به RouterOS 7.14 است. در گزارش‌های
کاربران، CHR روی VDSINA، XCP-ng و Vultr پس از Upgrade دیگر Interfaceهای Ethernet
را نشان نمی‌داد. در برخی گزارش‌ها بازگشت به نسخه قبلی باعث برگشتن شبکه شده بود.
در یکی از همان بحث‌ها نیز کاربر اعلام کرده که MikroTik مشکل را در محیط آزمایشگاهی
خود بازتولید کرده است.

این سابقه یک نکته مهم را نشان می‌دهد: وقتی شبکه دقیقاً بلافاصله بعد از Upgrade
ناپدید شده است، نباید بدون بررسی به سراغ تغییر IP، Gateway یا Firewall برویم.
اول باید مشخص کنیم آیا خود Virtual NIC هنوز توسط CHR دیده می‌شود یا خیر.

در سال 2026 نیز گزارش‌هایی درباره رفتارهای غیرمنتظره Interface در CHR روی
Proxmox/QEMU منتشر شده است؛ برای نمونه در یک گزارش RouterOS 7.23.1 روی Proxmox
پس از Upgrade با یک Interface مجازی غیرمنتظره و هشدار MAC مواجه شده است.

نشانه‌های از دست رفتن شبکه بعد از Upgrade

اگر یکی از موارد زیر را مشاهده می‌کنید، قبل از هر تغییر جدی بهتر است وضعیت
Network Interface را از Console بررسی کنید:

• WinBox با IP عمومی دیگر وصل نمی‌شود.
• SSH پاسخ نمی‌دهد.
• Ping به IP عمومی CHR شکست می‌خورد.
• WireGuard Handshake متوقف شده است.
• EoIP یا GRE دیگر بالا نمی‌آید.
• در WinBox فقط از MAC Address می‌توانید به روتر متصل شوید.
• در Console، Interface اصلی در فهرست Ethernet وجود ندارد.
• Interface وجود دارد ولی Running نیست.
• IP Address روی Interface دیگری قرار گرفته است.
• Default Route وجود ندارد.

اولین کاری که باید بعد از قطع شبکه انجام دهید

اگر VPS شما Console دارد، از طریق Console وارد MikroTik شوید. این مهم‌ترین
مزیت VPS در مقایسه با یک روتر فیزیکی بدون دسترسی Out-of-Band است.

اول از همه نسخه RouterOS را ببینید:

/system resource print

سپس Interfaceها را مشاهده کنید:

/interface print

اگر می‌خواهید فقط Ethernetها را ببینید:

/interface ethernet print

در این مرحله هنوز هیچ تنظیمی را تغییر ندهید. فقط پاسخ این سؤال را پیدا کنید:

اگر پاسخ «خیر» است، احتمالاً باید مشکل را در لایه Virtual NIC، Driver یا
سازگاری نسخه RouterOS با محیط مجازی بررسی کنید. اگر پاسخ «بله» است، سراغ IP،
Route و Gateway بروید.

بررسی کارت شبکه و Interface در MikroTik CHR

برای مشاهده Interfaceهای Ethernet:

/interface ethernet print detail

در یک CHR ساده ممکن است چیزی شبیه این ببینید:

Flags: X - disabled, R - running, S - slave
0 R ether1

حرف R یعنی Interface در وضعیت Running قرار دارد. اگر Interface
وجود دارد ولی R ندارد، موضوع فقط «وجود داشتن کارت شبکه» نیست؛ باید وضعیت Link
مجازی و تنظیمات Hypervisor بررسی شود.

اگر ether1 اصلاً وجود ندارد

اگر بعد از Upgrade دستور /interface ethernet print Interface
مورد انتظار را نشان نمی‌دهد، ساختن دستی یک Ethernet با دستور معمولی راه‌حل
واقعی نیست. Interface سخت‌افزاری مجازی توسط Hypervisor ارائه می‌شود و باید
Virtual NIC در سطح VM وجود داشته باشد.

بررسی IP Address بعد از آپدیت RouterOS

اگر Interface وجود دارد، IPهای RouterOS را بررسی کنید:

/ip address print detail

فرض کنید IP عمومی شما قبلاً روی ether1 بوده است اما بعد از Upgrade
یک Interface جدید مانند ether2 ایجاد شده یا ترتیب Interfaceها
تغییر کرده است. در این شرایط ممکن است IP هنوز روی Interface قبلی قرار داشته باشد.

برای مثال:

/ip address print

باید بررسی کنید که:

• IP عمومی روی Interface صحیح باشد.
• Prefix یا Subnet Mask درست باشد.
• IP به اشتباه روی Bridge قرار نگرفته باشد.
• Interface مربوطه Disabled نشده باشد.

بررسی Route و Gateway

اگر Interface و IP سالم هستند، Default Route را بررسی کنید:

/ip route print detail

در یک VPS معمولاً باید مسیر پیش‌فرضی شبیه این داشته باشید:

0.0.0.0/0 gateway=YOUR-GATEWAY

البته مقدار واقعی Gateway کاملاً به شبکه سرویس‌دهنده VPS بستگی دارد. بنابراین
نباید Gateway نمونه را کورکورانه روی سرور خود وارد کنید.

چرا Gateway مهم است؟

ممکن است CHR خودش IP داشته باشد، اما برای ارسال Packet به اینترنت نیازمند
Default Route باشد. اگر Route حذف شده باشد، نتیجه برای کاربر تقریباً همانند
قطع کامل شبکه دیده می‌شود.

برای آزمایش، ابتدا Gateway را Ping کنید:

/ping YOUR-GATEWAY count=5

اگر Gateway پاسخ نمی‌دهد، قبل از تست DNS یا سایت‌های اینترنتی باید مشکل
ارتباط Layer 2/Virtual Network یا تنظیمات Gateway را بررسی کنید.

بررسی ARP و ارتباط با Gateway

در VPSهای مختلف نحوه ارائه شبکه می‌تواند متفاوت باشد. بنابراین اگر IP و Route
درست هستند ولی Gateway پاسخ نمی‌دهد، جدول ARP را ببینید:

/ip arp print

در این قسمت باید بررسی شود که RouterOS برای Gateway یک Neighbor قابل مشاهده
دارد یا خیر.

اگر Provider از روش خاصی برای Routing، Routed IP یا Virtual MAC استفاده می‌کند،
هر تغییری در MAC Address یا Virtual NIC می‌تواند روی ارتباط اثر بگذارد.
به همین دلیل هنگام تغییر Virtual NIC نباید بدون اطلاع از توپولوژی شبکه VPS،
MAC یا Interface را دستکاری کرد.

آیا Firewall باعث قطع شبکه شده است؟

گاهی بعد از Upgrade تصور می‌شود که کارت شبکه خراب شده، در حالی که Interface،
IP و Route همگی سالم هستند و مشکل از Firewall است.

برای مشاهده Ruleها:

/ip firewall filter print stats

عددهای Packet و Byte به شما کمک می‌کنند بفهمید Ruleها در حال دریافت و Drop کردن
ترافیک هستند یا خیر.

همچنین NAT را بررسی کنید:

/ip firewall nat print stats

اگر CHR نقش Router یا Gateway دارد، یک تغییر در Interface می‌تواند باعث شود
Ruleای که قبلاً روی out-interface=ether1 بوده دیگر با ساختار جدید
شبکه مطابقت نداشته باشد.

مشکل VirtIO در MikroTik CHR چیست؟

VirtIO یک رابط شبکه مجازی پرکاربرد در محیط‌های KVM/QEMU و Proxmox است. MikroTik
در مستندات CHR، VirtIO را برای محیط‌های مجازی پشتیبانی‌شده معرفی کرده و RouterOS
v7 نیز Fast Path را برای virtio-net پشتیبانی می‌کند.

اما پشتیبانی از یک نوع Virtual NIC به این معنی نیست که هر ترکیب Hypervisor،
Kernel، تنظیمات VM و نسخه RouterOS الزاماً بدون مشکل کار می‌کند.

اگر بعد از Upgrade کارت VirtIO ناپدید شد، باید در پنل VPS بررسی کنید:

• Network Adapter هنوز به VM متصل است.
• مدل کارت شبکه به همان مدل قبلی تنظیم شده است.
• MAC Address ناخواسته تغییر نکرده است.
• Virtual Switch یا Bridge سرویس‌دهنده فعال است.
• VM واقعاً با همان Hardware Profile قبلی Boot شده است.

مشکل VMXNET3 در VMware و ESXi

اگر MikroTik CHR روی VMware یا ESXi اجرا می‌شود، VMXNET3 یکی از Interfaceهای
مناسب برای محیط VMware است. مستندات MikroTik استفاده از vmxnet3 را در CHR
پشتیبانی می‌کنند و Fast Path در RouterOS v7 برای آن فعال است.

بعد از Upgrade، اگر شبکه قطع شده است، در vSphere/ESXi بررسی کنید که Network
Adapter هنوز Connected باشد و به Port Group صحیح متصل شده باشد.

همچنین اگر Interface داخل RouterOS وجود دارد ولی Traffic عبور نمی‌کند، این موارد
را بررسی کنید:

• Connected بودن کارت شبکه.
• Connect at power on.
• Port Group صحیح.
• VLAN ID صحیح.
• MAC Address کارت شبکه.
• MTU در مسیر شبکه.

MikroTik همچنین درباره MTU در VMware نکات خاصی دارد؛ اگر MTU سمت ESXi تغییر کند،
Interfaceهایی که قبل از تغییر اضافه شده‌اند ممکن است محدودیت قبلی را حفظ کنند
و در بعضی سناریوها نیاز به اضافه‌کردن مجدد Interface باشد.

مشکل MikroTik CHR روی Proxmox و KVM

Proxmox معمولاً از KVM/QEMU استفاده می‌کند و VirtIO انتخاب متداولی برای کارت
شبکه VM است. در چنین محیطی اگر بعد از Upgrade شبکه قطع شد، دو طرف باید بررسی
شوند: هم RouterOS و هم تنظیمات VM.

در سمت Proxmox موارد زیر را بررسی کنید:

• مدل Network Device.
• Bridge مربوط به کارت شبکه.
• VLAN Tag.
• MAC Address.
• Firewall در سطح Datacenter، Node یا VM.
• وضعیت Link.

یک گزارش واقعی در انجمن MikroTik در سال 2026 نشان می‌دهد که پس از Upgrade
CHR روی Proxmox/QEMU، هشدار مربوط به MAC تکراری و یک Interface مجازی غیرمنتظره
دیده شده است. این مورد نشان می‌دهد که در عیب‌یابی CHR نباید فقط Configuration
داخل RouterOS را بررسی کرد و لایه Virtualization نیز اهمیت دارد.

چطور قبل از آپدیت RouterOS از قطع شبکه جلوگیری کنیم؟

مهم‌ترین اصل در Upgrade یک RouterOS مجازی این است که فرض کنید ممکن است Upgrade
موفقیت‌آمیز نباشد. این به معنی مشکل داشتن همه نسخه‌ها نیست؛ بلکه به این معنی است
که Router شما بخشی از زیرساخت شبکه است و باید برای سناریوی Recovery آماده باشید.

Backup و Export قبل از Upgrade

MikroTik توصیه می‌کند قبل از Upgrade فایل Backup و Export را ایجاد کرده و روی
Storage دیگری نگهداری کنید. مستندات رسمی نیز توضیح می‌دهند که System Backup
یک کپی باینری از Configuration است و شامل MAC Addressهای دستگاه نیز می‌شود.
همچنین توصیه شده Backup روی همان نسخه RouterOS بازیابی شود.

ساخت Backup

/system backup save name=before-upgrade

ساخت Export متنی

/export file=before-upgrade-export

Backup و Export دو کاربرد متفاوت دارند. Backup باینری برای Restore روی همان
محیط و نسخه مناسب‌تر است، در حالی که Export متنی برای مشاهده و انتقال بخش‌هایی
از Configuration بسیار کاربردی است.

مستندات MikroTik نیز این تفاوت را توضیح می‌دهند و اشاره می‌کنند که Export متنی
مواردی مانند Password کاربران سیستم، بعضی Certificateها و برخی دیتابیس‌ها را
در بر نمی‌گیرد.

اگر شبکه بعد از Upgrade قطع شد چگونه RouterOS را برگردانیم؟

اگر بعد از Upgrade متوجه شدید نسخه جدید با محیط مجازی شما سازگار نیست، اولین
گزینه منطقی بررسی امکان Rollback به نسخه‌ای است که قبلاً روی همان VPS بدون
مشکل کار می‌کرد.

اما Downgrade را نباید کورکورانه انجام دهید. ابتدا از Console وضعیت RouterOS،
Disk و Packageها را بررسی کنید.

در برخی مشکلات تاریخی CHR، کاربران با برگشت به نسخه قبلی توانسته‌اند Interface
شبکه را دوباره مشاهده کنند. نمونه شناخته‌شده آن گزارش‌های مربوط به RouterOS 7.14
و برخی Hypervisorها است.

بازیابی MikroTik CHR از Console سرویس‌دهنده VPS

یکی از مهم‌ترین مزایای داشتن VPS مناسب برای MikroTik این است که قطع شدن Network
نباید الزاماً به معنی از دست رفتن کامل دسترسی باشد.

اگر پنل سرویس‌دهنده VPS یک Console مجازی، VNC، Serial Console یا KVM ارائه کند،
از همان مسیر وارد RouterOS شوید.

ترتیب بررسی پیشنهادی:

اگر Ping به Gateway موفق است ولی 1.1.1.1 جواب نمی‌دهد، باید Route، NAT یا سیاست
شبکه Provider بررسی شود. اگر Gateway هم جواب نمی‌دهد، مشکل احتمالاً قبل از
Internet Routing و در سطح Virtual Network یا Gateway است.

اگر اسم Interface بعد از آپدیت تغییر کرده باشد چه کنیم؟

در سناریوهای مجازی، تغییر سخت‌افزار مجازی یا ترتیب Interfaceها می‌تواند باعث
شود Configuration شما با Interface جدید تطبیق نداشته باشد.

مثلاً تصور کنید NAT شما چنین شرطی داشته است:

out-interface=ether1

اما WAN اکنون روی Interface دیگری قرار گرفته است. در این حالت اینترنت ممکن است
از خود RouterOS قابل دسترسی باشد ولی Clientهای پشت Router اینترنت نداشته باشند.

بنابراین پس از تغییر NIC، تمام بخش‌های وابسته به Interface را بررسی کنید:

• IP Address
• Default Route
• NAT
• Firewall Filter
• Mangle
• Policy Routing
• WireGuard
• EoIP
• Bridge
• DHCP Client یا DHCP Server

چگونه بفهمیم مشکل از Gateway VPS است؟

یک تست بسیار ساده انجام دهید. ابتدا IP خود Router را بررسی کنید، سپس Gateway
را Ping کنید و بعد یک IP اینترنتی را تست کنید.

MTU چگونه باعث می‌شود تصور کنیم شبکه CHR قطع شده است؟

همه مشکلات شبکه بعد از Upgrade به معنی Down بودن Interface نیستند. ممکن است
Packetهای کوچک عبور کنند اما Packetهای بزرگ یا ترافیک Tunnel دچار مشکل شوند.
این موضوع در سناریوهای WireGuard، EoIP، GRE، IPsec و VXLAN اهمیت بیشتری دارد.

اگر Ping معمولی کار می‌کند اما یک Tunnel پایدار نیست، MTU و MSS را بررسی کنید.
برای مشاهده Interface:

/interface ethernet print detail

همچنین در VMware، تنظیمات MTU در سطح ESXi و Virtual Switch نیز اهمیت دارد.
مستندات MikroTik برای ESXi درباره نحوه اعمال MTU و Interfaceهایی که قبل از تغییر
MTU اضافه شده‌اند توضیح داده‌اند.

اگر WireGuard بعد از آپدیت CHR قطع شد چه کنیم؟

اگر خود MikroTik از طریق IP عمومی قابل دسترسی است اما WireGuard دیگر Handshake
ندارد، ابتدا نباید Interface شبکه را مقصر بدانیم.

ابتدا Peerها را بررسی کنید:

/interface wireguard print
/interface wireguard peers print detail

سپس وضعیت Handshake را بررسی کنید:

/interface wireguard peers print stats

اگر Last Handshake به‌روزرسانی نمی‌شود، موارد زیر را بررسی کنید:

• Public Keyها
• Endpoint Address
• Endpoint Port
• Allowed Address
• Firewall Input
• UDP Port
• NAT
• Route
• زمان سیستم

اگر کل Internet CHR نیز قطع است، ابتدا Network پایه را درست کنید و سپس سراغ
WireGuard بروید. بررسی VPN قبل از اصلاح WAN معمولاً فقط باعث پیچیده‌تر شدن
عیب‌یابی می‌شود.

اگر EoIP بعد از Upgrade کار نمی‌کند

EoIP به ارتباط IP بین دو نقطه نیاز دارد. بنابراین ابتدا باید IP Reachability
را بررسی کنید.

اگر هر دو MikroTik یکدیگر را Ping نمی‌کنند، بررسی EoIP را متوقف کنید و ابتدا
Routing و Firewall را اصلاح کنید.

اگر Ping برقرار است اما EoIP بالا نمی‌آید، Tunnel و تنظیمات مربوط به آن را
بررسی کنید:

/interface eoip print detail

همچنین اگر Tunnel از مسیر خاصی عبور می‌کند، MTU را فراموش نکنید.

چه زمانی باید مشکل را با VPS Provider مطرح کنیم؟

اگر Interface در RouterOS وجود ندارد، اما Virtual NIC در پنل VPS فعال است و
Configuration نیز تغییر نکرده، موضوع می‌تواند در لایه Hypervisor یا Driver
باشد.

در چنین شرایطی اطلاعات زیر را برای پشتیبانی سرویس‌دهنده ارسال کنید:

• نسخه RouterOS قبل از Upgrade
• نسخه RouterOS بعد از Upgrade
• نوع Hypervisor در صورت مشخص بودن
• مدل Virtual NIC
• MAC Address
• Screenshot یا خروجی /interface print
• Screenshot تنظیمات Network Adapter در پنل VPS
• زمان دقیق وقوع مشکل

این اطلاعات بسیار بهتر از این پیام است که فقط بگویید «بعد از آپدیت اینترنت
قطع شده است»، زیرا Provider می‌تواند سریع‌تر مشخص کند مشکل از VM، Network
Bridge یا RouterOS است.

روش امن برای Upgrade MikroTik CHR روی VPS

یک روش عملی برای محیط Production این است که Upgrade را مانند یک تغییر زیرساختی
انجام دهید، نه یک کلیک ساده روی Update.

MikroTik در اطلاعیه‌های انتشار نسخه‌های جدید نیز بر گرفتن Backup و Export قبل از
Upgrade، اطمینان از عدم قطع برق و وجود فضای کافی برای Packageها تأکید می‌کند.

چک‌لیست کامل عیب‌یابی قطع شدن شبکه CHR بعد از آپدیت

یک نکته مهم درباره نسخه‌های جدید RouterOS در سال ۲۰۲۶

در زمان تهیه این مقاله، چرخه انتشار RouterOS بسیار فعال است. در سپتامبر ۲۰۲۶
نسخه‌های 7.24.2، 7.24.3 و سپس 7.24.4 منتشر شده‌اند و در کنار آن شاخه
Long-term نیز نسخه‌های جدید خود را دریافت کرده است. بنابراین توصیه نمی‌شود
صرفاً به دلیل اینکه یک نسخه «جدیدتر» است، آن را بلافاصله روی CHRهای Production
نصب کنید.

این موضوع به معنی بد بودن نسخه جدید نیست؛ بلکه برای یک Router مجازی Production
باید سازگاری نسخه جدید با Hypervisor، Virtual NIC، VPNها و Configuration واقعی
خودتان را نیز در نظر بگیرید.

برای نمونه، نسخه 7.24.4 در 16 سپتامبر 2026 منتشر شده و یک اصلاح مشخص مربوط به
مشکل Firmware مودم LTE معرفی‌شده در 7.24.3 داشته است. این مورد مستقیماً مربوط
به CHR عمومی نیست، اما نشان می‌دهد که حتی نسخه‌های Stable نیز ممکن است در
انتشارهای پشت سر هم نیاز به اصلاح داشته باشند.

همچنین صفحه رسمی Changelog MikroTik نشان می‌دهد که شاخه Long-term و Stable
به‌صورت جداگانه نگهداری می‌شوند؛ در نتیجه انتخاب Channel مناسب برای محیط
Production موضوع مهمی است.

آیا همیشه باید RouterOS را Downgrade کنیم؟

خیر. اگر بعد از Upgrade شبکه قطع شد، ابتدا باید علت را مشخص کنید. ممکن است
مشکل فقط یک Route اشتباه، Interface اشتباه، Firewall یا Gateway باشد و
Downgrade هیچ ضرورتی نداشته باشد.

Downgrade زمانی منطقی‌تر می‌شود که شواهد نشان دهد نسخه جدید با محیط مشخص
Virtualization شما مشکل دارد؛ مثلاً Interface مجازی در نسخه قبلی وجود داشته
اما بعد از Upgrade ناپدید شده و با بازگشت به نسخه قبلی دوباره ظاهر می‌شود.

این دقیقاً با برخی گزارش‌های تاریخی CHR سازگار است که کاربران در آنها با
برگشت به نسخه قبلی، کارت Ethernet را دوباره مشاهده کرده‌اند.

Safe Mode چه کمکی می‌کند؟

Safe Mode بیشتر برای جلوگیری از Lock شدن خودخواسته RouterOS هنگام تغییر
Configuration مفید است. اگر در حال تغییر Route، Firewall یا Interface هستید
و ارتباط خودتان را قطع کنید، Safe Mode می‌تواند تغییرات را در صورت قطع غیرعادی
Session برگرداند.

در CLI می‌توان با Ctrl+X وارد Safe Mode شد. مستندات MikroTik
توضیح می‌دهند که تغییرات انجام‌شده در Safe Mode در صورت پایان غیرعادی Session
می‌توانند به حالت قبلی برگردند.

البته Safe Mode جای Backup را نمی‌گیرد و برای مشکلاتی که خود Driver یا
Virtual NIC را تحت تأثیر قرار داده‌اند، راه‌حل محسوب نمی‌شود.

چرا Backup تنها کافی نیست؟

فرض کنید قبل از Upgrade یک Backup عالی دارید، اما بعد از Upgrade کارت شبکه
دیگر توسط RouterOS شناسایی نمی‌شود. Restore کردن Configuration در چنین وضعیتی
لزومی ندارد مشکل را حل کند، چون مشکل ممکن است در لایه Virtual Hardware باشد.

به همین دلیل Recovery واقعی برای CHR باید سه بخش داشته باشد:

سؤالات متداول درباره قطع شدن شبکه MikroTik CHR بعد از آپدیت

جمع‌بندی؛ قبل از اینکه بگویید «آپدیت MikroTik شبکه را خراب کرد»

وقتی MikroTik CHR روی VPS بعد از Upgrade دیگر از طریق اینترنت قابل دسترسی نیست،
بهترین کار این نیست که بلافاصله Configuration را پاک کنید یا Router را دوباره
نصب کنید.

ابتدا از Console وارد شوید و یک مسیر منطقی برای عیب‌یابی داشته باشید:

• آیا RouterOS کاملاً Boot شده است؟
• آیا Virtual NIC در RouterOS دیده می‌شود؟
• آیا Interface در وضعیت Running است؟
• آیا IP روی Interface صحیح قرار دارد؟
• آیا Default Route وجود دارد؟
• آیا Gateway پاسخ می‌دهد؟
• آیا اینترنت از خود CHR قابل دسترسی است؟
• آیا Firewall ترافیک را Drop می‌کند؟
• آیا مدل NIC در Hypervisor تغییر کرده است؟
• آیا مشکل فقط مربوط به WireGuard، EoIP یا Tunnel است؟

این تفکیک باعث می‌شود مشخص شود مشکل واقعاً یک Regression مربوط به RouterOS
است یا فقط یک Configuration mismatch که هم‌زمان با Upgrade خودش را نشان داده
است.

از طرف دیگر، تجربه مشکلات گزارش‌شده در نسخه‌های مختلف CHR نشان می‌دهد که
برای یک MikroTik مجازی Production، داشتن Backup، Export، Console،
Snapshot و برنامه Recovery بسیار مهم‌تر از این است که صرفاً همیشه
آخرین نسخه RouterOS را نصب کنیم.