RouterOS konténerek: Docker MikroTikon

Összefoglaló A MikroTik RouterOS v7 közvetlenül a routeren tud Docker-kompatibilis konténereket futtatni, így a DNS-szűrés, a felügyeleti ügynökök és a kis hálózati szolgáltatások a routing sík mellett élnek egy különálló doboz helyett. Ez az útmutató a hardver- és architektúrakövetelményeket, a container device-mode biztonságos engedélyezését, a veth és bridge hálózat NAT-tal történő felépítését, az első konténer telepítését és a konténerek flottaszintű kezelését tárgyalja. A RouterOS 7.23 (2026. május) bővítette a futásra kész konténeralkalmazások katalógusát, így ez gyakorlatias lehetőséget kínál ISP-knek és laborépítőknek egyaránt.

Mik Azok a Konténerek a MikroTik RouterOS-en?

A MikroTik RouterOS konténerei a Linux konténerek MikroTik-féle megvalósítása, amely lehetővé teszi egy RouterOS v7 eszköz számára, hogy izolált, Docker-kompatibilis alkalmazás-image-eket futtasson közvetlenül a routeren. Docker Hub, GCR, Quay és más registry-k image-eivel működnek, és bár a RouterOS a docker parancs helyett saját CLI-szintaxist használ, az alapvető viselkedés ugyanaz — image lehúzása, hálózat adása, tároló csatolása és futtatása. (MikroTik dokumentáció)

Egy ISP vagy egy labor számára ez azt jelenti, hogy a kis, hálózathoz közeli szolgáltatások a routing sík mellé helyezhetők: egy Pi-hole vagy AdGuard DNS-szűrő, egy felügyeleti ügynök, egy fordított proxy vagy egy IoT-híd. A 2026. május 25-i RouterOS 7.23 stabil kiadás hosszú listányi futásra kész alkalmazást adott hozzá — köztük a paperless-ngx, nextcloud, lorawan-stack, birdnet-go és olyan Docker-kezelő felületeket, mint a portainer és a dockge — egy új network-outgoing-access kapcsolóval együtt, amely megakadályozza, hogy egy konténer kimenő forgalmat kezdeményezzen. (RouterOS 7.23 changelog)

Követelmények és Hardver

A container csomag az arm, arm64 és x86 architektúrákkal kompatibilis, és mindenekelőtt telepíteni kell. Egy távoli image lehúzása sok szabad helyet igényel, ezért a MikroTik az eszköz belső flash-memóriája helyett külső tárolót ajánl. (MikroTik dokumentáció)

Tervezzen külső adathordozót USB-n, SATA-n vagy NVMe-n, a RouterOS által támogatott fájlrendszerrel formázva. A MikroTik legalább 100 MB/s szekvenciális átviteli sebességre és 10K véletlenszerű IOPS-re képes lemezt javasol — a lassabb lemezek kínosan hosszúvá teszik az image kibontását. Kerülje a konténerkötetek beépített tárolóra helyezését, amely kicsi és a konténerek írási mintázatai alatt elhasználódik. A nagyon korlátozott flash-sel rendelkező eszközök távoli lehúzás helyett előre elkészített image-eket használjanak a csatlakoztatott lemezen.

A container device-mode Biztonságos Engedélyezése

A konténerek alapértelmezetten le vannak tiltva, és jó okkal fizikai hozzáférést igényelnek a bekapcsoláshoz. Engedélyezze a funkciót a következővel:

/system/device-mode/update container=yes

A RouterOS ezután arra vár, hogy megerősítse a reset gomb megnyomásával vagy hideg újraindítással. A fizikai megerősítés kapuja szándékos biztonsági kontroll: amint a konténer mód be van kapcsolva, a konténerek távolról hozzáadhatók, indíthatók és eltávolíthatók, és egy rosszindulatú image kapaszkodóvá válhat a routeren. A MikroTik nyíltan fogalmaz ezzel kapcsolatban — ha a RouterOS eszközét feltörik, a konténerek triviálissá teszik a rosszindulatú szoftver telepítését, és a harmadik féltől származó image-ekre nincs biztonsági garancia.

Kezelje a konténereket gazdálkodó routert pontosan annyira biztonságosnak, mint a rajta futtatott legkevésbé megbízható image-et. Csak olyan image-eket telepítsen, amelyekben megbízik, tartsa az eszközt tűzfal mögött, és olvassa el device-mode biztonsági üzemeltetési útmutatónkat, mielőtt ezt éles környezetben engedélyezné.

A Konténerhálózat Felépítése

A konténereknek virtuális interfészre, bridge-re és NAT-ra van szükségük az internet eléréséhez. Az alábbi minta a Docker „bridge” hálózatát tükrözi. Először hozzon létre egy veth interfészt és egy bridge-et, amely megosztja annak gateway címét:

/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

Egy veth sok konténert szolgálhat ki, és további veth/bridge párok létrehozása lehetővé teszi a konténercsoportok egymástól való elszigetelését. Ha új a RouterOS bridging-ben, bridge-konfigurációs útmutatónk elmagyarázza az alapul szolgáló modellt. Ezután adjon hozzá egy masquerade szabályt, hogy a kimenő konténerforgalom lefordításra kerüljön — a teljes képet a NAT-konfigurációs útmutatóban találja:

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

Az Első Konténer Telepítése

Irányítsa a registry-t és az ideiglenes kibontási könyvtárat a külső lemezére, majd adja hozzá az image-et. Az alábbi Pi-hole példa a kanonikus a MikroTik dokumentációjából:

/container/config/set registry-url=https://registry-1.docker.io tmpdir=disk1/tmp
/container/add remote-image=pihole/pihole interface=veth1 root-dir=disk1/images/pihole name=pihole logging=yes

A konténer hozzáadása elindítja a letöltést és a kibontást, de nem futtatja. Ellenőrizze a folyamatot a /container/print paranccsal, és várjon, amíg status=stopped, majd indítsa el:

/container/start pihole

Végül tegye közzé a szolgáltatást egy port továbbításával a routerről a veth címre:

/ip firewall nat add action=dst-nat chain=dstnat dst-address=192.168.88.1 dst-port=80 protocol=tcp to-addresses=172.17.0.2 to-ports=80

A Pi-hole most a router LAN IP-jén válaszol. A DNS-szűrés ilyen módon történő futtatása alternatívája a RouterOS natív blokklistáinak — ha a konténer nélküli utat részesíti előnyben, lásd RouterOS adlist útmutatónkat.

Konténerek Kezelése Egy Flottán

Egyetlen konténer egyetlen routeren egyszerű. Egy ISP valódi üzemeltetési kérdése a konzisztencia: ugyanaz az image, ugyanaz a veth- és NAT-séma, ugyanaz a tárolási elrendezés és ugyanazok a start-on-boot és memóriakorlátok minden eszközön. A RouterOS megadja az alapelemeket — a start-on-boot=yes túléli az újraindításokat, a memory-high vagy a memory-max pedig konténerenként korlátozza a RAM-ot, hogy egy elszabadult szolgáltatás ne éheztesse ki a routing síkot:

/container/config/set memory-high=200M
/container/set pihole start-on-boot=yes

A nehéz rész ennek azonos módon történő elvégzése több tucat vagy több száz távoli routeren, majd annak bizonyítása, hogy mindegyik valóban újra elindult egy újraindítás után — különösen, amikor az eszköz CGNAT mögött ül, és nem lehet egyszerűen elérni a nyilvános IP-jét.

Tippek

• Tartson minden konténerkötetet a külső lemezen; soha ne a belső NAND-on.
• Használjon külön veth/bridge párt a nem megbízható konténerek megbízhatóaktól való elszigetelésére.
• Állítson be memory-max értéket mindenre, amiben nem bízik teljesen, hogy a router válaszkész maradjon.
• Tiszta tesztkörnyezethez, mielőtt az élest megérintené, futtassa ugyanazokat az image-eket egy virtualizált CHR példányon, mielőtt fizikai routerekre telepítené.

Tegye Meg a Következő Lépést

A konténerek egy MikroTik routert apró alkalmazás-gazdagéppé alakítanak, de az ilyen gazdagépek flottájához orkesztráció kell. Az MKController központilag sablonosítja a RouterOS-konfigurációt, alkalmazza azt a leltárában lévő minden eszközre, és nyomon követi az eltéréseket, így láthatja, melyik router tért el — a NATCloudon keresztül pedig eléri a CGNAT mögötti eszközöket, hogy megerősítse, egy konténer újraindult-e a karbantartás után. Ez áthidalja a szakadékot egyetlen konténer kézi konfigurálása és a konténerek megbízható üzemeltetése között egy egész ISP-hálózaton.

Kezdje el ingyenes MKController próbaverzióját