Tutorial
MikroTik CAPsMAN: tsentraalne WiFi-seadistus
Seadista MikroTik CAPsMAN RouterOS 7-l, et hallata paljusid WiFi pääsupunkte keskselt: provisioonireeglid, konfiguratsiooniprofiilid ja mitme asukoha haldus.
Kokkuvõte MikroTik CAPsMAN muudab ühe RouterOS-i seadme juhtmevaba võrgu kontrolleriks, mis seadistab iga pääsupunkti ühest kohast. Selle asemel et logida igasse AP-sse SSID-i või parooli muutmiseks, redigeerid ühte profiili ja CAPsMAN lükkab selle kogu pargile. RouterOS 7-s on kontroller sisse ehitatud wifi paketti — lisandmoodulit pole vaja. See juhend läbib kogu ahela: luba manager, registreeri oma AP-d CAP-idena, ehita provisioonireeglid, turva juhtimiskanal ja skaleeri muster asukohtade ulatuses.

Mis On MikroTik CAPsMAN?
MikroTik CAPsMAN on RouterOS-i sisseehitatud juhtmevaba võrgu kontroller: Controlled Access Point system Manager, mis hoiab pääsupunktide grupi konfiguratsiooni ja provisioneerib igaühe automaatselt, kui see ühendub (MikroTiku dokumentatsioon — AP Controller (CAPsMAN)). Võrk jaguneb kaheks rolliks — manager (CAPsMAN), mis salvestab SSID-d, turbe- ja kanaliseaded, ning suvaline arv CAP-e, pääsupunktid, mis pakuvad tegelikku raadiokatet ja annavad oma konfiguratsiooni managerile üle.
Tasuks on ühtne tõeallikas WiFi jaoks: muuda külalisparool korra ja iga CAP pärib selle; lisa AP ja see provisioneerib end reeglite järgi, mille oled juba kirjutanud. Iga seade Level 4 või kõrgema litsentsiga saab toimida CAP-ina (MikroTiku dokumentatsioon — WiFi).
Samm 1 — Luba CAPsMAN manager
Vali seade, mis hakkab toimima kontrollerina — sageli peamine ruuter, ehkki seda saab majutada iga RouterOS 7 seade wifi paketiga. Kinnita, et pakett on olemas /system/package all, seejärel luba manager käsuga /interface/wifi/capsman/set enabled=yes. Määra package-path ja upgrade-policy, kui soovid, et CAP-id tõmbaksid kontrollerilt vastavad wifi paketid, nii et nende püsivara jääks joondatuks (MikroTiku dokumentatsioon — AP Controller (CAPsMAN)).
Kontroller kuulab nüüd CAP-e, kuid ei halda veel midagi — see tuleb Sammu 3 reeglitest. Pane tähele liidest, mida manager kuulab: CAP-id avastavad selle vaikimisi Layer 2 kaudu, nii et kontroller ja AP-d peaksid registreerimise ajal jagama sama levialadomeeni või olema selle poole sillatud.
Samm 2 — Muuda oma pääsupunktid CAP-ideks
Igal pääsupunktil anna selle raadiod kontrollerile üle. Luba CAP-režiim käsuga /interface/wifi/cap/set enabled=yes, loetle liidesed, mida AP peaks pakkuma, parameetritega slaves-datapath ja discovery-interfaces, ning määra caps-man-addresses, kui suunad kontrolleri poole IP järgi, mitte ei toetu Layer 2 avastamisele (MikroTiku dokumentatsioon — WiFi). Kui CAP leiab manageri, asendatakse tema kohalik raadiokonfiguratsioon sellega, mida CAPsMAN provisioneerib.
Riistvara loeb siin: CAP on täpselt nii hea kui tema raadio. Wi-Fi 6 ja Wi-Fi 7 AP-d nagu MikroTik hAP be lite sobivad suurepäraselt CAP-ideks, kuna CAPsMAN saab juhtida nende uuemaid raadioid tsentraalselt, ning riba- ja kanalihäälestus, mida tavaliselt teeksid seadmepõhiselt — nagu käsitletud meie juhendis WiFi 6 seadistamine MikroTik AX ruuteritel — muutub profiiliks, mille kirjutad korra.
Samm 3 — Ehita konfiguratsioonid ja provisioonireeglid
Siin CAPsMAN teenib oma koha. Konfiguratsiooni profiil määrab SSID-i, turbe (authentication-types, paroolifraas), riigi ja kanaliplaani; datapath otsustab, kuidas CAP-liiklus võrku jõuab — kohalikult AP-l sillatud või tunneldatud tagasi kontrollerisse. Provisioonireeglid seejärel sobitavad ühenduvaid CAP-e — raadio MAC-i, mudeli või identiteedi järgi — ja rakendavad õige konfiguratsiooni automaatselt (MikroTiku dokumentatsioon — AP Controller (CAPsMAN)). Kirjuta /interface/wifi/provisioning add action=create-dynamic-enabled ..., et uued AP-d seadistaksid end ise, mitte ei ootaks sinu järel.
Kuna CAP-liiklus tavaliselt maandub sillale, eeldab see samm, et su Layer 2 on korras; kui sildamine on sulle uus, katab meie MikroTiku silla seadistamise juhend aluspõhja. Ja siin on CAPsMANi aus piir: see tsentraliseerib WiFi ühe kontrolleri ulatuses. Kontrollerid ise — üks hoone, haru või tornisaidi kohta — on endiselt eraldi ruuterid, mida pead sünkroonis hoidma. Just seda teist kihti MKControlleri pargi konfiguratsioonihaldus lahendabki: lükka identne CAPsMANi profiil kõikidele kontrolleritele korraga ja kasuta toimingute ajalugu, et näha, kes mida ja millal muutis ning milline sait triivis.
Samm 4 — Eralda haldus-VLAN ja turva juurdepääs
Kohtle CAPsMANi juhtimiskanalit kui taristut, mitte tagantjärele mõttena. Kanna CAP-i-managerile liiklust eraldi haldus-VLAN-il, hoia see täielikult külalis- ja kliendi-SSID-idest eemal ning piira, millistel liidestel manager CAP-e vastu võtab. Haldus-VLAN takistab ka jutukal kliendivõrgul kunagi puudutamast tasandit, mis su raadioid juhib (MikroTiku kogukond — CAPsMAN haldus-VLAN-iga).
Tsentraliseeritud juhtimine lõikab mõlemas suunas: üks vale provisioonireegel ei riku ühte AP-d, vaid rikub need kõik korraga. Enne kui lükkad kanali- või turbemuudatuse kogu pargile, tahad varukoopiat, mille juurde saad tagasi pöörduda — ja viisi sisse pääseda, kui muudatus su välja lukustab. MKController hoiab igast seadmest igapäevaseid automaatseid binaarvarukoopiaid — viimased viis versiooni, pilves — ja laseb sul teha käsitsi varukoopia vahetult enne riskantset lükkamist, nii et halvast CAPsMANi lükkamisest saab ühe klikiga taastamine viimasesse teadaolevalt heasse olekusse, mitte sõit saiti konsoolikaabliga.
Samm 5 — Juuruta CAPsMAN igas asukohas
Üks kontroller ja käputäis CAP-e on pärastlõuna. Tõeline töö on kümnes koht — hotelli kõrvalhoone, teine torn, kliendi kämpus — igaüks oma kontrolleriga LTE või Starlinki ja Carrier-Grade NAT-i taga, ilma avaliku IP-ta, kuhu helistada, kui AP jääb vait. See on müür, mida üheasukohalised õpetused kunagi ei maini.
See on lugeja tõeline lahendatav ülesanne ja koht, kus juhtimistasand kõige rohkem loeb. MKController hoiab iga kontrolleri kättesaadavana turvalise väljamineva tunneli kaudu — ilma port forwardingu, ilma avaliku aadressita, nagu üksikasjalikult kirjeldatud meie juhendis MikroTiku kaugjuurdepääsust CGNAT-i taga (NATCloud) —, lükkab identsed CAPsMANi profiilid üle pargi ja jälgib iga saidi seadme kättesaadavust, nii et maas olev CAP ilmub nähtavale — ja Telegrami hoiatustega jõuab sinuni — enne, kui vastuvõtulaud helistab. WISP-id ja mitme asukoha operaatorid, kes käitavad MikroTik WiFi-d, kasutavad seda, et panna kakskümmend saiti tunduma ühe armatuurlauana.
Näpunäited
- Hoia kontroller ja CAP-id samal RouterOS 7 wifi paketi versioonil; mittevastavused põhjustavad CAP-ide kukkumist ja taasprovisioonimist tsüklites.
- Alusta
create-dynamic-enabledprovisioonimisega, et uued AP-d tuleksid võrku seadistatuna, seejärel pinguta mudelipõhisteks reegliteks, kui park kasvab. - Kasuta kohaliku sildamise datapath’e kõrge liiklusega saitide jaoks, et kliendiandmed ei teeks juuksenõela läbi kontrolleri.
- Nimeta SSID- ja turbeprofiilid otstarbe järgi („guest“, „staff“), mitte asukoha järgi, nii et üks profiil teenindab iga saiti identselt.
Halda WiFi-d, mitte ruuterite riiulit
CAPsMAN lahendab ühe AP-pargi ühest kontrollerist. Äri lahendab iga kontrolleri ühest kohast. MKController on see juhtimistasand: pargiülene konfiguratsiooni lükkamine, konfiguratsiooni audit ja ajalugu, automaatsed varukoopiad ning turvaline väljaminev juurdepääs CGNAT-i taga olevatele saitidele ilma avaliku IP või port forwardinguta, pluss kättesaadavuse jälgimine ja Telegrami hoiatused, mis toovad maas oleva CAP-i nähtavale enne, kui külaline märkab, et WiFi kadus. Operaatorid, kes käitavad MikroTik-i paljude saitide ulatuses, kasutavad seda, et hoida iga asukoht samal lehel ilma sõiduta.