تنظیم اینترنت پشتیبان در میکروتیک و آزمون Failover

مبنای این آموزش مستندات RouterOS با برچسب 7.26 در ۱۵ اکتبر ۲۰۲۶ است؛ این عدد نسخه آزمایش‌شده نت‌مسترز یا توصیه نصب یک انتشار مشخص نیست. نسخه نصب‌شده، نام رابط‌ها و گزینه‌های دستگاه خود را پیش از اجرا تطبیق دهید.

نمونه برای کارشناس مجاز روی روتر آزمایشی با فایروال و NAT سالم است. ether1 با 192.168.10.2/24 به دروازه ثابت 192.168.10.1 و ether2 با 192.168.20.2/24 به دروازه ثابت 192.168.20.1 متصل است. bridge-lan با 192.168.50.1/24 دروازه کاربران است. این سه شبکه هم‌پوشانی ندارند و هر اینترنت باید پیش از تغییر، جداگانه از یک کلاینت LAN بررسی شود. IPها صرفاً سناریوی آموزشی‌اند.

این تمرین IPv4 و فقط جدول main را پوشش می‌دهد؛ DHCP یا PPPoE با دروازه متغیر، PCC، VPN، ورود از اینترنت و IPv6 طرح جدا می‌خواهند. اگر دو مودم هم‌آدرس‌اند یا مسیر پویا دارید، ابتدا همان تعارض را حل کنید. برای انتخاب بین پشتیبان و تقسیم مصرف، راهنمای دو اینترنت در شرکت را ببینید؛ فرمان‌های این صفحه را با مثال PCC روی یک روتر ترکیب نکنید.

از تنظیمات بکاپ و Export بگیرید و از LAN یا کنسول دسترسی مدیریتی مستقل داشته باشید. مسیرهای پیش‌فرض، NAT هر دو خروجی و قواعد موجود را ثبت کنید. در Terminal با Ctrl+X وارد Safe Mode شوید؛ تغییرها را محدود نگه دارید و تا کنترل نتیجه، آن‌ها را نهایی نکنید.

/ip/address/print detail
/ip/route/print detail where dst-address=0.0.0.0/0
/ip/firewall/nat/print detail
/ip/firewall/filter/print detail

در این نمونه، NAT موجود باید LAN را روی هر دو ether1 و ether2 پوشش دهد و forward نیز خروج و پاسخ را مجاز بداند. NAT تازه را روی قاعده سالم تکرار نکنید. اگر تنها یک رابط عضو فهرست WAN است، قاعده مبتنی بر آن فهرست لزوماً خط دوم را پوشش نمی‌دهد. قواعد محافظ input و forward را برای راه‌اندازی پشتیبان خاموش نکنید.

مسیرهای پیش‌فرض قبلی را با شماره و مشخصات واقعی شناسایی کنید؛ دستور حذف همه مسیرها مناسب نیست. تمرین فرض می‌کند مسیر پیش‌فرض پویا و سیاست مسیریابی دیگری وجود ندارد. در شبکه دارای DHCP Client یا PPPoE، تولید خودکار مسیر و تغییر دروازه باید در طرح همان اتصال دیده شود.

برای مثال از 1.1.1.1 روی خط اول و 8.8.8.8 روی خط دوم استفاده می‌کنیم. ابتدا پاسخ ICMP هرکدام را از مسیر موردنظر بررسی کنید؛ دسترسی دائمی این آدرس‌ها تضمین نیست. در اجرا، مقصد مجاز و قابل اتکایی انتخاب کنید که خرابی موردنظر را نشان دهد. این مسیرهای /32 همه ترافیک به همان IP را به یک خط وابسته می‌کنند؛ آن‌ها را بدون بررسی به‌عنوان DNS اصلی کاربران هم انتخاب نکنید.

/ip/route
add dst-address=1.1.1.1/32 gateway=192.168.10.1 scope=10 comment="NM-FO-probe1"
add dst-address=8.8.8.8/32 gateway=192.168.20.1 scope=10 comment="NM-FO-probe2"
/ping address=1.1.1.1 count=5
/ping address=8.8.8.8 count=5

پاسخ مودم فقط رسیدن تا مودم را نشان می‌دهد. در این روش، مقصد پایش بیرون از آن است؛ با این حال پاسخ همان مقصد، سلامت DNS، وب یا برنامه شرکت را ثابت نمی‌کند. بسته‌های پایش تولید خود روترند؛ سیاست output و ورودی پاسخ‌ها نیز نباید آن‌ها را مسدود کند.

/ip/route
add dst-address=0.0.0.0/0 gateway=1.1.1.1 distance=1 target-scope=11 check-gateway=ping disabled=yes comment="NM-FO-main"
add dst-address=0.0.0.0/0 gateway=8.8.8.8 distance=2 target-scope=11 check-gateway=ping disabled=yes comment="NM-FO-backup"

scope=10 مسیر پایش و target-scope=11 مسیر پیش‌فرض، حل بازگشتی دروازه را در این مثال ممکن می‌کنند؛ بسته‌ها واقعاً به مودم مربوط می‌روند و مقصد پایش نقش مودم را نمی‌گیرد. distance کمتر، خط اول را در حالت سالم ترجیح می‌دهد. همین مقادیر را به همه مسیرهای شبکه تعمیم ندهید.

در IP → Routes، دو مسیر NM-FO-main و NM-FO-backup را بررسی و فعال کنید؛ سپس فقط مسیرهای پیش‌فرض قدیمیِ ثبت‌شده و متعارض را غیرفعال کنید. این جابه‌جایی را با مدیریت محلی و در زمان مجاز انجام دهید. تا وقتی یک مسیر قدیمی با اولویت برابر یا بهتر باقی است، نتیجه ممکن است متعلق به همان مسیر باشد. مسیرهای connected و مسیرهای /32 پایش را دست نزنید.

/ip/route/print detail where comment~"NM-FO-"

در حالت سالم، مسیر اصلی باید active باشد و immediate-gw به 192.168.10.1 روی ether1 برسد. پشتیبانِ سالم می‌تواند به‌علت distance بالاتر انتخاب نشده باشد؛ غیرفعال‌بودن انتخاب آن به‌تنهایی نشانه خرابی نیست. DNS کاربران باید روی خط دوم هم قابل دسترس باشد؛ پاسخ IP را از حل نام جدا بررسی کنید.

زمان تشخیص و وصل‌شدن مجدد را در همین محیط اندازه بگیرید؛ عدد ثابتی برای همه شبکه‌ها وجود ندارد. نمونه با سالم‌شدن پایش، خط دارای distance کمتر را دوباره ترجیح می‌دهد و تأخیر اختصاصی برای تثبیت خط ندارد. خط ناپایدار ممکن است رفت‌وبرگشت ایجاد کند؛ سیاست بازگشت و معیار چندمقصدی برای محیط عملیاتی باید جدا طراحی و سنجیده شوند.

اتصال فعلی ممکن است NAT و وضعیت مربوط به خروجی قبلی را نگه دارد. تغییر IP عمومی، به‌ویژه برای تماس، VPN یا برنامه حساس به IP، می‌تواند اتصال دوباره بخواهد. جدول Connection Tracking را برای بهترشدن ظاهری آزمون به‌صورت سراسری پاک نکنید؛ آزمون اتصال تازه و ادامه نشست قبلی را جدا ثبت کنید. FastTrack و شتاب‌دهی موجود نیز در آزمون نشست‌های واقعی لحاظ شوند.

در طرح چندمقصدی باید هر مقصد به خط خودش وابسته باشد و معلوم شود خرابی چند مقصد چه تصمیمی ایجاد می‌کند؛ صرف افزودن چند ping سیاست قابل اتکا نمی‌سازد. نمونه رسمی MikroTik راه چند مقصد با مسیرهای هم‌اولویت را نشان می‌دهد. معیار تصمیم را پیش از افزودن مقصدها مشخص کنید و خرابی هر مقصد و کل خط را جدا بسنجید.

برای برگشت، از دسترسی محلی مسیرهای پیش‌فرض قبلی را مطابق ثبت اولیه فعال و دو پیش‌فرض NM-FO را غیرفعال کنید. پس از بازیابی ارتباط، فقط دو مسیر پایش همین تمرین را حذف کنید و DNS و برنامه‌ها را دوباره بسنجید. اگر نتیجه پذیرفته شد، با Ctrl+X از Safe Mode خارج شوید و تنظیم و نتیجه واقعی آزمون را ثبت کنید. برای توزیع مصرف هم‌زمان، آموزش PCC سناریوی مستقلی دارد.