RouterOS 7 و Container روی L009-IN؛ چه قابلیت‌هایی عملی‌اند و چه محدودیت‌هایی دارند؟

یکی از تفاوت‌های مهم MikroTik L009UiGS-2HaxD-IN با بسیاری از روترهای قدیمی‌تر میکروتیک، پشتیبانی رسمی از Container در RouterOS 7 است. این قابلیت باعث می‌شود بتوان بعضی سرویس‌های لینوکسی مانند Pi-hole یا یک MQTT Broker سبک را مستقیماً روی روتر اجرا کرد؛ بدون اینکه برای هر سرویس حتماً یک Raspberry Pi، Mini PC یا سرور جدا داشته باشید.

اما عبارت «Container Support» نباید این تصور را ایجاد کند که L009 یک سرور Docker کامل با منابع نامحدود است. این دستگاه پردازنده دو‌هسته‌ای IPQ-5018، رم 512MB و حافظه داخلی 128MB NAND دارد و RouterOS، Routing، Firewall، Wi-Fi و خود Containerها همگی از همین منابع استفاده می‌کنند. از طرف دیگر، معماری قابل استفاده برای Container روی L009 از دید RouterOS در کلاس ARM قرار می‌گیرد و هر Image دلخواهی الزاماً روی آن اجرا نمی‌شود. بنابراین Container روی L009 زمانی ارزشمند است که سرویس درست، Storage مناسب و محدودیت‌های سخت‌افزار را از ابتدا بشناسیم.

قبل از Container، سخت‌افزار L009-IN را درست بشناسیم

L009 برای RouterOS 7 نسبت به نسل‌هایی مانند RB2011 پلتفرم بسیار مدرن‌تری دارد. MikroTik در معرفی رسمی این خانواده، Container Support را یکی از قابلیت‌های دستگاه ذکر می‌کند و وجود USB 3.0 نیز دقیقاً در چنین سناریوهایی کاربرد پیدا می‌کند.

نکته مهم:

پردازنده IPQ-5018 از نظر سخت‌افزاری خانواده ARM مدرن‌تری است، اما در مشخصات جاری RouterOS، L009 در کلاس ARM قرار می‌گیرد. هنگام Pull یا Build کردن Container باید Image سازگار با معماری دستگاه انتخاب شود؛ صرف وجود نسخه ARM64 یک Image کافی نیست.

Container در RouterOS دقیقاً چیست؛ آیا Docker روی روتر نصب می‌شود؟

خیر. MikroTik یک پیاده‌سازی Container در RouterOS ارائه کرده که می‌تواند Imageهایی با فرمت رایج Registryهایی مانند Docker Hub، GCR و Quay را اجرا کند، اما شما Docker Engine معمول دسکتاپ یا سرور لینوکسی را روی L009 نصب نمی‌کنید.

مدیریت Container از منوی /container در RouterOS انجام می‌شود. Network از طریق VETH ساخته می‌شود، Volumeها با Mount تعریف می‌شوند و Image می‌تواند از Registry دریافت یا به‌صورت فایل از کامپیوتر Import شود.

پس تجربه کار با آن بیشتر شبیه «اجرای Container داخل RouterOS» است تا تبدیل L009 به یک Docker Host عمومی. این تفاوت برای انتخاب کاربرد بسیار مهم است.

Container روی L009 به‌صورت پیش‌فرض فعال نیست

حتی بعد از نصب Package مربوط به Container، قابلیت Container در Device Mode به‌صورت پیش‌فرض غیرفعال است. برای فعال‌سازی باید دستور زیر اجرا شود:

/system/device-mode/update container=yes

RouterOS سپس از شما تأیید فیزیکی می‌خواهد. یعنی باید در بازه اعلام‌شده روی خود دستگاه اقدام لازم را انجام دهید. این محدودیت امنیتی عمداً طراحی شده تا مهاجمی که فقط Remote Access به RouterOS پیدا کرده نتواند بدون دسترسی فیزیکی قابلیت Container را فعال کند.

نتیجه عملی:

اگر L009 در یک سایت راه دور نصب شده و دسترسی فیزیکی ندارید، فعال‌سازی اولیه Container را به بعد موکول نکنید. Device Mode برای این تغییر به تأیید فیزیکی نیاز دارد.

چه Containerهایی روی L009 واقعاً کاربردی هستند؟

مهم‌ترین اصل این است که L009 را به‌عنوان Router دارای قابلیت اجرای سرویس‌های جانبی ببینیم، نه یک Server کوچک که Routing هم انجام می‌دهد. سرویس‌هایی که RAM، CPU و Disk I/O محدودی نیاز دارند، منطقی‌ترین گزینه‌ها هستند.

Pi-hole یکی از منطقی‌ترین سناریوهاست

MikroTik در مستندات رسمی Container یک راهنمای اختصاصی برای Pi-hole ارائه کرده است. ایده این است که Pi-hole داخل یک شبکه مجازی مجزا قرار بگیرد، از طریق VETH به RouterOS متصل شود و Clientهای شبکه از آن به‌عنوان DNS استفاده کنند.

ساختار پایه Network می‌تواند مشابه مثال زیر باشد:

/interface/veth/add name=veth1 address=172.17.0.2/24 gateway=172.17.0.1

/interface/bridge/add name=containers

/ip/address/add address=172.17.0.1/24 interface=containers

/interface/bridge/port/add bridge=containers interface=veth1

/ip/firewall/nat/add chain=srcnat action=masquerade src-address=172.17.0.0/24

این ساختار باعث می‌شود Container یک Interface شبکه مشخص داشته باشد و RouterOS همچنان روی Routing و Firewall آن کنترل داشته باشد. در شبکه Production بهتر است حتی همین Subnet نیز با Ruleهای مشخص محدود شود و Container دسترسی بیش از نیاز به LAN نداشته باشد.

این دستورات Template عمومی نیستند:

Subnet، NAT، DNS و Firewall باید با معماری واقعی شبکه شما هماهنگ شوند. دستورهای بالا فقط ساختار VETH و شبکه Container را نشان می‌دهند.

محدودیت اصلی فقط CPU نیست؛ Storage اهمیت بیشتری دارد

L009 فقط 128MB حافظه NAND داخلی دارد. این فضا برای RouterOS مناسب است، اما نباید آن را معادل SSD یک Server در نظر گرفت. MikroTik در مستندات Container صراحتاً توصیه می‌کند Container Volumeها روی Disk خارجی قرار بگیرند و از Built-in Storage برای این کار اجتناب شود.

خوشبختانه L009 یک USB 3.0 Type-A دارد. بنابراین می‌توان یک Storage خارجی مناسب را برای Root Directory، Temporary Extraction و Persistent Volumeهای Container استفاده کرد.

در مستندات فعلی MikroTik برای تجربه بهتر Container، Disk خارجی با حداقل حدود 100MB/s Sequential Read/Write و 10K Random IOPS توصیه شده است. به همین دلیل یک SSD مناسب معمولاً انتخاب مطمئن‌تری از یک Flash Drive ارزان و کند است.

/container/config/set registry-url=https://registry-1.docker.io tmpdir=disk1/tmp

USB 3.0 به‌تنهایی تضمین عملکرد نیست:

سرعت و پایداری به خود Disk، USB Enclosure و مصرف برق آن هم بستگی دارد. L009 برای USB حداکثر جریان مشخصی دارد؛ بنابراین قبل از اتصال Storage پرمصرف، مشخصات Enclosure و Disk بررسی شود.

512MB RAM در عمل یعنی چند Container؟

هیچ عدد رسمی وجود ندارد که بگوییم L009 دقیقاً باید یک، دو یا سه Container اجرا کند. اندازه Image نیز معیار خوبی نیست؛ مهم‌تر از حجم فایل، مقدار RAM و CPU مصرف‌شده در زمان اجرای واقعی سرویس است.

512MB RAM باید بین RouterOS، Routing Table، Firewall، Wireless، Queueها و Containerها تقسیم شود. یک L009 که فقط Gateway ساده یک دفتر کوچک است فضای آزاد بیشتری نسبت به دستگاهی دارد که هم‌زمان تعداد زیادی Firewall Rule، VPN، Queue و سرویس دیگر را اجرا می‌کند.

در نسخه‌های جدید RouterOS 7 می‌توان برای Containerها Memory Limit تعریف کرد و حتی CPU Coreهای قابل استفاده را مشخص کرد. این قابلیت‌ها برای جلوگیری از مصرف کنترل‌نشده منابع مفید هستند، اما جای Capacity Planning را نمی‌گیرند.

روش مناسب:

ابتدا فقط یک سرویس سبک راه‌اندازی کنید، RAM و CPU روتر را در Peak Traffic بررسی کنید و سپس درباره Container بعدی تصمیم بگیرید. تعداد Container معیار ظرفیت نیست؛ مصرف واقعی آن‌ها معیار است.

یک تفاوت مهم: Container روی L009 بله، RouterOS Apps نه

در نسخه‌های جدید RouterOS مفهومی به نام Apps نیز اضافه شده است. Apps یک Catalog ساده‌تر برای Deployment سرویس‌های از پیش تعریف‌شده است و می‌تواند بخشی از تنظیمات Container، Network و Firewall را خودکار انجام دهد.

اما طبق الزامات فعلی MikroTik، App System برای معماری‌های ARM64 و x86 در نظر گرفته شده است. L009 در RouterOS در گروه ARM قرار دارد؛ بنابراین نباید پشتیبانی L009 از Container را با پشتیبانی از App Catalog یکی بدانیم.

روی L009 مسیر عملی همچنان استفاده مستقیم از /container، VETH، Mount، Environment Variable و Image سازگار با ARM است.

اشتباه رایج:

اگر در مستندات جدید RouterOS گزینه /app را می‌بینید، فرض نکنید هر روتر دارای Container Support الزاماً App Catalog را هم اجرا می‌کند. Architecture Requirements این دو قابلیت یکسان نیست.

Container را داخل همان LAN کاربران رها نکنید

VETH در RouterOS مانند یک Interface شبکه عمل می‌کند و می‌تواند وارد Bridge یا ساختار Routing شود. از نظر طراحی، بهتر است Container یک Subnet یا VLAN مشخص داشته باشد و ارتباط آن با LAN توسط Firewall کنترل شود.

مثلاً یک Pi-hole معمولاً باید درخواست DNS Clientها را دریافت کند و بتواند DNS بالادستی را Query کند؛ اما دلیلی ندارد به تمام Interfaceهای مدیریتی، دوربین‌ها یا تجهیزات حساس شبکه دسترسی آزاد داشته باشد.

همین اصل درباره MQTT Broker نیز صدق می‌کند. اگر فقط تجهیزات IoT باید به Broker متصل شوند، Ruleهای Firewall را بر همان اساس محدود کنید. Container نباید به راهی برای دور زدن Segmentation شبکه تبدیل شود.

ریسک امنیتی Container را جدی بگیرید

هشدار MikroTik درباره Container بسیار صریح است. اجرای Image شخص ثالث Attack Surface دستگاه را افزایش می‌دهد و امنیت Router تا حدی به امنیت همان نرم‌افزاری وابسته می‌شود که داخل Container اجرا کرده‌اید.

بنابراین Image ناشناس فقط به این دلیل که در Docker Hub وجود دارد انتخاب مناسبی نیست. منبع Image، نگهداری پروژه، نسخه مورد استفاده و Vulnerabilityهای شناخته‌شده باید بررسی شوند.

همچنین فقط Portهایی را به LAN یا Internet باز کنید که واقعاً مورد نیاز هستند. Management RouterOS و Management Container نیز نباید مستقیماً از WAN در دسترس قرار بگیرند.

سناریوی فرضی؛ L009 به‌عنوان Gateway دفتر و Pi-hole

فرض کنید L009-IN Gateway یک دفتر کوچک است. VLAN کارکنان، Guest و IoT روی RouterOS مدیریت می‌شوند و هدف این است که DNS Filtering نیز بدون خرید یک Mini PC جداگانه راه‌اندازی شود.

در این سناریو یک SSD خارجی از طریق USB به L009 متصل می‌شود. Pi-hole روی Storage خارجی قرار می‌گیرد، یک VETH و Subnet مجزا برای Container تعریف می‌شود و فقط درخواست DNS از VLANهای مورد نظر توسط Firewall اجازه عبور پیدا می‌کند.

این استفاده با فلسفه سخت‌افزاری L009 هماهنگ است؛ سرویس نسبتاً سبک است و مستقیماً به شبکه کمک می‌کند. حالا اگر بخواهیم کنار Pi-hole یک Database سنگین، داشبورد گرافیکی پرمصرف و چند سرویس دیگر نیز اجرا کنیم، Router کم‌کم به Server تبدیل می‌شود و مزیت Consolidation می‌تواند به ریسک پایداری تبدیل شود.

این انتخاب برای چه کسانی مناسب است؟

Container روی L009-IN برای مدیر شبکه یا دفتر کوچکی مناسب است که یک یا چند سرویس سبک و نزدیک به زیرساخت شبکه نیاز دارد؛ برای مثال DNS Filtering، MQTT یا یک Utility کوچک که مصرف منابع آن قابل کنترل است. وجود USB 3.0 و 512MB RAM باعث شده L009 نسبت به Routerهای قدیمی MikroTik گزینه عملی‌تری برای چنین پروژه‌هایی باشد.

در مقابل، اگر سرویس برای کسب‌وکار حیاتی است، RAM زیادی می‌خواهد، Database دارد، دائماً روی Disk می‌نویسد یا چند Application باید هم‌زمان اجرا شوند، بهتر است Server، Mini PC، VM Host یا پلتفرم Container مستقل در نظر گرفته شود. Router باید قبل از هر چیز Router باقی بماند.

برای بررسی سایر مدل‌های این برند نیز می‌توانید تجهیزات MikroTik را بر اساس معماری CPU، RAM، Storage و نقش شبکه مقایسه کنید.

نقاط قوت و محدودیت‌های Container روی L009-IN

چک‌لیست قبل از راه‌اندازی Container روی L009

اشتباهات رایج هنگام استفاده از Container روی L009

استفاده از NAND داخلی برای همه Volumeها:
این حافظه محدود است و MikroTik نیز استفاده از Storage خارجی را برای Container توصیه می‌کند.

Download کردن Image بدون بررسی Architecture:
هر Image موجود در Docker Hub الزاماً Build سازگار با ARM دستگاه ندارد.

تبدیل L009 به Server:
وجود Container Support به این معنی نیست که CPU دو‌هسته‌ای و 512MB RAM برای هر Application کافی هستند.

قرار دادن Container در LAN بدون Firewall:
Container باید مانند یک Host مستقل و بالقوه آسیب‌پذیر مدیریت شود.

انتظار App Catalog روی L009:
Container Support و RouterOS Apps الزامات معماری متفاوتی دارند.

اجرای سرویس حیاتی بدون مسیر جایگزین:
اگر Restart Router باعث توقف یک سرویس کسب‌وکاری مهم می‌شود، باید بررسی کنید آیا اصلاً محل مناسبی برای آن سرویس انتخاب کرده‌اید یا خیر.

جمع‌بندی؛ Container روی L009 قابلیت واقعی است، اما جای Server را نمی‌گیرد

پشتیبانی Container در L009-IN یک قابلیت تبلیغاتی صرف نیست. معماری ARM، RouterOS 7، رم 512MB و USB 3.0 واقعاً اجازه می‌دهند سرویس‌های لینوکسی سبک مثل Pi-hole یا MQTT Broker در کنار وظایف شبکه اجرا شوند. VETH نیز امکان می‌دهد این سرویس‌ها به‌صورت کنترل‌شده وارد Routing و Firewall شوند.

در مقابل، محدودیت‌های دستگاه مشخص‌اند: فقط 512MB RAM، CPU دو‌هسته‌ای، 128MB NAND و منابعی که باید با خود RouterOS تقسیم شوند. به همین دلیل Database سنگین، چند Application پرمصرف یا سرویس‌های حیاتی سازمانی بهتر است روی Server یا Host مستقل اجرا شوند.

اگر Container را به‌عنوان یک قابلیت جانبی برای تکمیل نقش Router ببینید، L009 دستگاه انعطاف‌پذیری است. اگر انتظار شما یک Docker Server کوچک است، سخت‌افزار مناسب دیگری لازم دارید. برای انتخاب تجهیزات شبکه متناسب با معماری واقعی پروژه نیز بهتر است نقش Router، سرویس‌های جانبی و ظرفیت آینده از ابتدا جداگانه تعریف شوند.