MikroTik CAPsMAN central WiFi-styrning

Sammanfattning MikroTik CAPsMAN förvandlar en RouterOS-enhet till en trådlös controller som konfigurerar varje accesspunkt från ett enda ställe. I stället för att logga in på varje AP för att ändra ett SSID eller lösenord redigerar du en profil och CAPsMAN skickar ut den till hela flottan. I RouterOS 7 är controllern inbyggd i wifi-paketet — inget tillägg behövs. Den här guiden går igenom hela kedjan: aktivera hanteraren, registrera dina AP:er som CAP:ar, bygg provisioneringsregler, säkra styrkanalen och skala mönstret över flera platser.

Vad är MikroTik CAPsMAN?

MikroTik CAPsMAN är RouterOS inbyggda trådlösa controller: en Controlled Access Point system Manager som håller konfigurationen för en grupp accesspunkter och provisionerar var och en automatiskt när den ansluter (MikroTik-dokumentation — AP Controller (CAPsMAN)). Nätverket delas i två roller — hanteraren (CAPsMAN), som lagrar SSID:er, säkerhet och kanalinställningar, och valfritt antal CAP:ar, accesspunkterna som ger den faktiska radiotäckningen och lämnar upp sin konfiguration till hanteraren.

Vinsten är en enda källa till sanning för WiFi: ändra gästlösenordet en gång och varje CAP ärver det; lägg till en AP och den konfigurerar sig själv mot reglerna du redan skrivit. Vilken enhet som helst med en Level 4-licens eller högre kan fungera som CAP (MikroTik-dokumentation — WiFi).

Steg 1 — Aktivera CAPsMAN-hanteraren

Välj enheten som ska fungera som controller — ofta huvudroutern, även om vilken RouterOS 7-enhet som helst med wifi-paketet kan vara värd. Bekräfta att paketet finns under /system/package och aktivera sedan hanteraren med /interface/wifi/capsman/set enabled=yes. Ange en package-path och upgrade-policy om du vill att CAP:ar ska hämta matchande wifi-paket från controllern så att deras firmware hålls i linje (MikroTik-dokumentation — AP Controller (CAPsMAN)).

Controllern lyssnar nu efter CAP:ar men hanterar ännu ingenting — det kommer från reglerna i Steg 3. Notera gränssnittet som hanteraren lyssnar på: CAP:ar upptäcker den över Layer 2 som standard, så controller och AP:er bör dela en broadcast-domän under registreringen, eller vara bryggade mot en.

Steg 2 — Förvandla dina accesspunkter till CAP:ar

På varje accesspunkt lämnar du över dess radioenheter till controllern. Aktivera CAP-läge med /interface/wifi/cap/set enabled=yes, lista gränssnitten som AP:n ska erbjuda med slaves-datapath och discovery-interfaces, och ange caps-man-addresses om du pekar mot controllern via IP i stället för att förlita dig på Layer 2-upptäckt (MikroTik-dokumentation — WiFi). När CAP:en hittar hanteraren ersätts dess lokala radiokonfiguration av det som CAPsMAN provisionerar.

Hårdvaran spelar roll här: en CAP är bara så bra som dess radio. Wi-Fi 6- och Wi-Fi 7-AP:er som MikroTik hAP be lite blir utmärkta CAP:ar eftersom CAPsMAN kan driva deras nyare radioenheter centralt, och band- och kanaljusteringen du normalt gör per enhet — den typ som täcks i vår guide om att konfigurera WiFi 6 på MikroTik AX-routrar — blir en profil du skriver en gång.

Steg 3 — Skapa konfigurationer och provisioneringsregler

Det är här CAPsMAN gör sig förtjänt av sin plats. En configuration-profil definierar SSID, säkerhet (authentication-types, lösenfras), land och kanalplan; en datapath avgör hur CAP-trafik når nätverket — bryggad lokalt vid AP:n eller tunnlad tillbaka till controllern. Provisioneringsregler matchar sedan anslutande CAP:ar — via radio-MAC, modell eller identitet — och tillämpar rätt konfiguration automatiskt (MikroTik-dokumentation — AP Controller (CAPsMAN)). Skriv /interface/wifi/provisioning add action=create-dynamic-enabled ... så att nya AP:er konfigurerar sig själva i stället för att vänta på dig.

Eftersom CAP-trafik vanligtvis landar på en bridge förutsätter det här steget att din Layer 2 är ren; om bryggning är nytt för dig täcker vår guide för MikroTik-bryggkonfiguration grunderna. Och här är den ärliga begränsningen med CAPsMAN: den centraliserar WiFi inom räckhåll för en controller. Controllerarna själva — en per byggnad, per filial, per mastplats — är fortfarande separata routrar som du måste hålla synkroniserade. Det andra lagret är precis det som MKControllers flottkonfigurationshantering sköter: skicka ut en identisk CAPsMAN-profil till varje controller på en gång, och använd Action History för att se vem som ändrade vad, när, och vilken plats som avvek.

Steg 4 — Separera ett hanterings-VLAN och säkra åtkomsten

Behandla CAPsMAN-styrkanalen som infrastruktur, inte som en eftertanke. Bär trafiken mellan CAP och hanterare på ett dedikerat hanterings-VLAN, håll den helt borta från gäst- och klient-SSID:er, och begränsa vilka gränssnitt hanteraren accepterar CAP:ar på. Ett hanterings-VLAN hindrar också ett pratsamt klientnätverk från att någonsin röra planet som styr dina radioenheter (MikroTik-community — CAPsMAN med hanterings-VLAN).

Centraliserad styrning skär åt båda hållen: en felaktig provisioneringsregel bryter inte en AP, den bryter alla på en gång. Innan du rullar ut en kanal- eller säkerhetsändring flottövergripande vill du ha en säkerhetskopia att återgå till — och en väg in om ändringen låser ut dig. MKController tar dagliga automatiska binära säkerhetskopior av varje enhet — de fem senaste versionerna, i molnet — och låter dig ta en manuell precis före en riskabel utrullning, så att en felaktig CAPsMAN-utrullning blir en återställning med ett klick till det senaste kända fungerande läget i stället för en bilresa till platsen med en konsolkabel.

Steg 5 — Rulla ut CAPsMAN på alla platser

En controller och en handfull CAP:ar är en eftermiddag. Det verkliga jobbet är den tionde platsen — en hotellannex, ett andra torn, ett kundcampus — var och en med sin egen controller bakom LTE eller Starlink och Carrier-Grade NAT, utan någon publik IP att ringa upp när en AP tystnar. Det är väggen som tutorials för en enda plats aldrig nämner.

Det här är läsarens verkliga uppgift att lösa, och där kontrollplanet betyder mest. MKController håller varje controller nåbar via en säker utgående tunnel — ingen portvidarebefordran, ingen publik adress, som beskrivs i vår guide om MikroTik fjärrhantering bakom CGNAT (NATCloud) — skickar ut identiska CAPsMAN-profiler över flottan, och spårar varje plats enhetstillgänglighet, så att en nedsläckt CAP dyker upp — och, med Telegram-aviseringar, når dig — innan receptionen ringer. WISP:ar och multisite-operatörer som driver MikroTik WiFi använder det för att få tjugo platser att kännas som en enda instrumentpanel.

Tips

• Håll controller och CAP:ar på samma RouterOS 7 wifi-paketversion; avvikelser får CAP:ar att tappa anslutningen och omprovisioneras i loopar.
• Börja med create-dynamic-enabled-provisionering så att nya AP:er kommer online färdigkonfigurerade, och skärp sedan till regler per modell när flottan växer.
• Använd datapaths med lokal bryggning för högtrafikerade platser så att klientdata inte gör en U-sväng genom controllern.
• Namnge SSID- och säkerhetsprofiler efter syfte (“gäst”, “personal”) inte efter plats, så att en profil betjänar varje plats identiskt.

Hantera WiFi, inte en rackfull routrar

CAPsMAN löser en AP-flotta från en controller. En verksamhet löser varje controller från ett enda ställe. MKController är det kontrollplanet: flottövergripande konfigurationsutrullning, konfigurationsrevision och historik, automatiska säkerhetskopior, och säker utgående åtkomst till platser bakom CGNAT utan publik IP eller portvidarebefordran, plus tillgänglighetsövervakning och Telegram-aviseringar som lyfter fram en nedsläckt CAP innan en gäst märker att WiFi:n försvann. Operatörer som driver MikroTik över många platser använder det för att hålla varje plats på samma sida utan bilresan.

Starta din kostnadsfria MKController-provperiod