MikroTik CAPsMAN central WiFi-opsætning

Resumé MikroTik CAPsMAN gør én RouterOS-enhed til en trådløs controller, der konfigurerer hvert access point fra ét sted. I stedet for at logge ind på hvert AP for at ændre en SSID eller adgangskode redigerer du én profil, og CAPsMAN skubber den ud til hele flåden. I RouterOS 7 er controlleren indbygget i wifi-pakken — ingen tilføjelse nødvendig. Denne guide gennemgår hele kæden: aktivér manageren, tilmeld dine AP’er som CAPs, byg provisioneringsregler, sikr kontrolkanalen, og skalér mønsteret på tværs af lokationer.

Hvad er MikroTik CAPsMAN?

MikroTik CAPsMAN er RouterOS’ indbyggede trådløse controller: en Controlled Access Point system Manager, der holder konfigurationen for en gruppe access points og provisionerer hvert enkelt automatisk, når det forbinder (MikroTik-dokumentation — AP Controller (CAPsMAN)). Netværket deles op i to roller — manageren (CAPsMAN), som lagrer SSID’er, sikkerhed og kanalindstillinger, og et vilkårligt antal CAPs, de access points, der leverer den faktiske radiodækning og overlader deres konfiguration til manageren.

Gevinsten er én sandhedskilde for WiFi: skift gæsteadgangskoden én gang, og hvert CAP arver den; tilføj et AP, og det provisionerer sig selv mod de regler, du allerede har skrevet. Enhver enhed med en Level 4-licens eller højere kan fungere som et CAP (MikroTik-dokumentation — WiFi).

Trin 1 — Aktivér CAPsMAN-manageren

Vælg den enhed, der skal fungere som controller — ofte hovedrouteren, selvom enhver RouterOS 7-enhed med wifi-pakken kan hoste den. Bekræft, at pakken er til stede under /system/package, og aktivér derefter manageren med /interface/wifi/capsman/set enabled=yes. Sæt en package-path og upgrade-policy, hvis du vil have CAPs til at hente matchende wifi-pakker fra controlleren, så deres firmware forbliver afstemt (MikroTik-dokumentation — AP Controller (CAPsMAN)).

Controlleren lytter nu efter CAPs, men administrerer endnu ingenting — det kommer fra reglerne i Trin 3. Bemærk det interface, manageren lytter på: CAPs opdager det over Layer 2 som standard, så controller og AP’er bør dele et broadcast-domæne under tilmeldingen, eller være bridget mod ét.

Trin 2 — Gør dine access points til CAPs

På hvert access point overlader du dets radioer til controlleren. Aktivér CAP-tilstand med /interface/wifi/cap/set enabled=yes, list de interfaces, AP’et skal tilbyde, med slaves-datapath og discovery-interfaces, og sæt caps-man-addresses, hvis du peger på controlleren via IP i stedet for at forlade dig på Layer 2-opdagelse (MikroTik-dokumentation — WiFi). Når CAP’et finder manageren, erstattes dets lokale radiokonfiguration af det, CAPsMAN provisionerer.

Hardware betyder noget her: et CAP er kun så godt som sin radio. Wi-Fi 6- og Wi-Fi 7-AP’er som MikroTik hAP be lite er fremragende CAPs, fordi CAPsMAN kan styre deres nyere radioer centralt, og den bånd- og kanaltuning, du normalt ville lave pr. enhed — den slags, der er dækket i vores guide til konfiguration af WiFi 6 på MikroTik AX-routere — bliver en profil, du skriver én gang.

Trin 3 — Byg konfigurationer og provisioneringsregler

Det er her, CAPsMAN gør sig fortjent til sin plads. En konfigurations-profil definerer SSID, sikkerhed (authentication-types, adgangssætning), land og kanalplan; en datapath afgør, hvordan CAP-trafik når netværket — bridget lokalt på AP’et eller tunneleret tilbage til controlleren. Provisioneringsregler matcher derefter forbindende CAPs — via radio-MAC, model eller identitet — og anvender den rette konfiguration automatisk (MikroTik-dokumentation — AP Controller (CAPsMAN)). Skriv /interface/wifi/provisioning add action=create-dynamic-enabled ..., så nye AP’er selv konfigurerer sig i stedet for at vente på dig.

Fordi CAP-trafik som regel lander på en bridge, forudsætter dette trin, at dit Layer 2 er rent; hvis bridging er nyt for dig, dækker vores guide til MikroTik bridge-konfiguration grundlaget. Og her er den ærlige grænse for CAPsMAN: den centraliserer WiFi inden for én controllers rækkevidde. Controllerne selv — én pr. bygning, pr. filial, pr. tårnlokation — er stadig separate routere, du skal holde synkroniseret. Det andet lag er præcis det, MKControllers flådekonfigurationsstyring håndterer: skub en identisk CAPsMAN-profil til hver controller på én gang, og brug Handlingshistorik til at se, hvem der ændrede hvad, hvornår, og hvilken lokation der drev afsted.

Trin 4 — Adskil et management-VLAN og sikr adgangen

Behandl CAPsMAN-kontrolkanalen som infrastruktur, ikke en eftertanke. Kør CAP-til-manager-trafik på et dedikeret management-VLAN, hold den helt væk fra gæste- og klient-SSID’er, og begræns hvilke interfaces manageren vil acceptere CAPs på. Et management-VLAN forhindrer også et snakkesaligt klientnetværk i nogensinde at røre det plan, der styrer dine radioer (MikroTik-community — CAPsMAN med management-VLAN).

Centraliseret kontrol skærer begge veje: én forkert provisioneringsregel ødelægger ikke ét AP, den ødelægger dem alle på én gang. Før du skubber en kanal- eller sikkerhedsændring ud over hele flåden, vil du have en backup, du kan rulle tilbage til — og en vej ind, hvis ændringen låser dig ude. MKController tager daglige automatiske binære backups af hver enhed — de sidste fem versioner, i skyen — og lader dig tage en manuel én lige før en risikabel udrulning, så en dårlig CAPsMAN-udrulning bliver til en gendannelse med ét klik til den senest kendte gode tilstand i stedet for en køretur til lokationen med et konsolkabel.

Trin 5 — Udrul CAPsMAN på tværs af alle lokationer

Én controller og en håndfuld CAPs er en eftermiddag. Det egentlige arbejde er det tiende sted — en hotelfløj, et andet tårn, en klientcampus — hver med sin egen controller bag LTE eller Starlink og Carrier-Grade NAT, uden nogen offentlig IP at ringe ind til, når et AP bliver tavst. Det er den mur, enkelt-lokation-tutorials aldrig nævner.

Dette er læserens egentlige job-to-be-done, og hvor kontrolplanet betyder mest. MKController holder hver controller tilgængelig via en sikker udgående tunnel — ingen portviderstilling, ingen offentlig adresse, som beskrevet i vores guide til MikroTik fjernadministration bag CGNAT (NATCloud) — skubber identiske CAPsMAN-profiler ud på tværs af flåden og sporer hver lokations enhedstilgængelighed, så et nedbrudt CAP dukker op — og, med Telegram-advarsler, når dig — før receptionen ringer. WISP’er og operatører med flere lokationer, der kører MikroTik WiFi, bruger det til at få tyve lokationer til at føles som ét dashboard.

Tips

• Hold controller og CAPs på samme RouterOS 7 wifi-pakkeversion; uoverensstemmelser får CAPs til at droppe og re-provisionere i sløjfer.
• Start med create-dynamic-enabled-provisionering, så nye AP’er kommer online konfigureret, og stram derefter til pr.-model-regler, efterhånden som flåden vokser.
• Brug lokal-bridging-datapaths til lokationer med meget trafik, så klientdata ikke laver hårnålesving gennem controlleren.
• Navngiv SSID- og sikkerhedsprofiler efter formål (“gæst”, “personale”) ikke efter placering, så én profil betjener hver lokation identisk.

Administrér WiFi, ikke et rack af routere

CAPsMAN løser én AP-flåde fra én controller. En virksomhed løser hver controller fra ét sted. MKController er det kontrolplan: flådedækkende konfigurationsudrulning, konfigurationsaudit og historik, automatiske backups og sikker udgående adgang til lokationer bag CGNAT uden offentlig IP eller portviderstilling, plus tilgængelighedsovervågning og Telegram-advarsler, der afslører et nedbrudt CAP, før en gæst opdager, at WiFi’en faldt ud. Operatører, der kører MikroTik på tværs af mange lokationer, bruger det til at holde hver placering på samme side uden køreturen.

Start din gratis MKController-prøveperiode