הגדרת WiFi מרכזית עם CAPsMAN של MikroTik

תקציר CAPsMAN של MikroTik הופך התקן RouterOS יחיד לבקר אלחוטי שמגדיר כל נקודת גישה ממקום אחד. במקום להתחבר לכל AP כדי לשנות SSID או סיסמה, אתם עורכים פרופיל אחד ו-CAPsMAN דוחף אותו לכל הצי. ב-RouterOS 7 הבקר מובנה בחבילת ה-wifi — ללא תוסף. מדריך זה עובר על השרשרת המלאה: הפעלת המנהל, רישום נקודות הגישה שלכם כ-CAPs, בניית כללי הקצאה, אבטחת ערוץ הבקרה, והרחבת התבנית על פני אתרים.

מהו CAPsMAN של MikroTik?

CAPsMAN של MikroTik הוא הבקר האלחוטי המובנה של RouterOS: Controlled Access Point system Manager שמחזיק את התצורה עבור קבוצת נקודות גישה ומקצה כל אחת מהן אוטומטית ברגע שהיא מתחברת (תיעוד MikroTik — AP Controller (CAPsMAN)). הרשת מתפצלת לשני תפקידים — המנהל (CAPsMAN), שמאחסן הגדרות SSID, אבטחה וערוצים, וכל מספר של CAPs, נקודות הגישה שמספקות את כיסוי הרדיו בפועל ומעבירות את התצורה שלהן כלפי מעלה אל המנהל.

התמורה היא מקור אמת יחיד עבור WiFi: שנו את סיסמת האורחים פעם אחת וכל CAP יורש אותה; הוסיפו AP והוא מקצה את עצמו מול הכללים שכבר כתבתם. כל התקן עם רישיון Level 4 ומעלה יכול לשמש כ-CAP (תיעוד MikroTik — WiFi).

שלב 1 — הפעילו את מנהל ה-CAPsMAN

בחרו את ההתקן שישמש כבקר — לרוב הנתב הראשי, אם כי כל התקן RouterOS 7 עם חבילת ה-wifi יכול לארח אותו. ודאו שהחבילה קיימת תחת /system/package, ואז הפעילו את המנהל באמצעות /interface/wifi/capsman/set enabled=yes. הגדירו package-path ו-upgrade-policy אם ברצונכם ש-CAPs ימשכו חבילות wifi תואמות מהבקר כדי שהקושחה שלהם תישאר מיושרת (תיעוד MikroTik — AP Controller (CAPsMAN)).

הבקר מאזין כעת ל-CAPs אך עדיין לא מנהל דבר — זה מגיע מהכללים בשלב 3. שימו לב לממשק שעליו המנהל מאזין: CAPs מגלים אותו דרך Layer 2 כברירת מחדל, ולכן הבקר ונקודות הגישה צריכים לחלוק תחום שידור (broadcast domain) במהלך הרישום, או להיות מגושרים אל אחד כזה.

שלב 2 — הפכו את נקודות הגישה שלכם ל-CAPs

בכל נקודת גישה, מסרו את הרדיו שלה לבקר. הפעילו מצב CAP באמצעות /interface/wifi/cap/set enabled=yes, פרטו את הממשקים שה-AP צריך להציע באמצעות slaves-datapath ו-discovery-interfaces, והגדירו caps-man-addresses אם אתם מפנים אל הבקר לפי IP במקום להסתמך על גילוי Layer 2 (תיעוד MikroTik — WiFi). ברגע שה-CAP מוצא את המנהל, תצורת הרדיו המקומית שלו מוחלפת בכל מה ש-CAPsMAN מקצה.

החומרה חשובה כאן: CAP טוב רק כמו הרדיו שלו. נקודות גישה Wi-Fi 6 ו-Wi-Fi 7 כמו MikroTik hAP be lite הן CAPs מצוינות מכיוון ש-CAPsMAN יכול להניע את הרדיו החדש שלהן באופן מרכזי, וכיוונון הפס והערוץ שבדרך כלל הייתם עושים לכל התקן בנפרד — מהסוג המכוסה במדריך שלנו על הגדרת WiFi 6 בנתבי MikroTik AX — הופך לפרופיל שאתם כותבים פעם אחת.

שלב 3 — בנו תצורות וכללי הקצאה

כאן CAPsMAN מוכיח את ערכו. פרופיל תצורה (configuration) מגדיר את ה-SSID, האבטחה (authentication-types, סיסמה), המדינה ותוכנית הערוצים; datapath מחליט כיצד תעבורת ה-CAP מגיעה לרשת — מגושרת מקומית ב-AP או מנותבת בתוך מנהרה בחזרה לבקר. כללי הקצאה (provisioning) מתאימים אז את ה-CAPs המתחברים — לפי MAC של הרדיו, דגם או זהות — ומחילים את התצורה הנכונה אוטומטית (תיעוד MikroTik — AP Controller (CAPsMAN)). כתבו /interface/wifi/provisioning add action=create-dynamic-enabled ... כך שנקודות גישה חדשות יגדירו את עצמן במקום לחכות לכם.

מכיוון שתעבורת ה-CAP בדרך כלל נוחתת על bridge, שלב זה מניח שה-Layer 2 שלכם נקי; אם גישור הוא חדש לכם, מדריך הגדרת ה-bridge של MikroTik שלנו מכסה את היסודות. והנה המגבלה הכנה של CAPsMAN: הוא מרכז WiFi בטווח של בקר יחיד. הבקרים עצמם — אחד לכל בניין, לכל סניף, לכל אתר מגדל — עדיין נתבים נפרדים שעליכם לשמור מסונכרנים. השכבה השנייה הזו היא בדיוק מה שניהול תצורת הצי של MKController מטפל בו: דחפו פרופיל CAPsMAN זהה לכל בקר בבת אחת, והשתמשו ב-היסטוריית פעולות כדי לראות מי שינה מה, מתי, ואיזה אתר סטה.

שלב 4 — הפרידו VLAN ניהול ואבטחו את הגישה

התייחסו לערוץ הבקרה של CAPsMAN כתשתית, לא כמחשבה שלאחר מעשה. העבירו את תעבורת ה-CAP-אל-מנהל על VLAN ניהול ייעודי, הרחיקו אותה לחלוטין מ-SSIDs של אורחים ולקוחות, והגבילו באילו ממשקים המנהל יקבל CAPs. VLAN ניהול גם מונע מרשת לקוחות רועשת אי-פעם לגעת במישור ששולט ברדיו שלכם (קהילת MikroTik — CAPsMAN עם VLAN ניהול).

בקרה מרכזית חותכת לשני הכיוונים: כלל הקצאה שגוי אחד לא שובר AP אחד, הוא שובר את כולם בבת אחת. לפני שאתם דוחפים שינוי ערוץ או אבטחה לכל הצי, אתם רוצים גיבוי שאפשר לחזור אליו — ודרך פנימה אם השינוי נועל אתכם בחוץ. MKController שומר גיבויים בינאריים אוטומטיים יומיים של כל התקן — חמש הגרסאות האחרונות, בענן — ומאפשר לכם לקחת גיבוי ידני ממש לפני דחיפה מסוכנת, כך שדחיפת CAPsMAN גרועה הופכת לשחזור בלחיצה אחת למצב התקין האחרון הידוע במקום נסיעה לאתר עם כבל קונסולה.

שלב 5 — הריצו את CAPsMAN בכל אתר

בקר אחד וקומץ CAPs זה עניין של אחר צהריים. העבודה האמיתית היא המתחם העשירי — אגף מלון, מגדל שני, קמפוס לקוח — כל אחד עם הבקר שלו מאחורי LTE או Starlink ו-Carrier-Grade NAT, ללא IP ציבורי להתקשר אליו כשה-AP משתתק. זה הקיר שמדריכי אתר-יחיד לעולם לא מזכירים.

זו העבודה-שצריך-להיעשות האמיתית של הקורא, וכאן מישור הבקרה חשוב ביותר. MKController שומר על כל בקר נגיש דרך מנהרה יוצאת מאובטחת — ללא port forwarding, ללא כתובת ציבורית, כמפורט במדריך שלנו על ניהול מרחוק של MikroTik מאחורי CGNAT (NATCloud) — דוחף פרופילי CAPsMAN זהים על פני הצי, ועוקב אחר זמינות ההתקנים של כל אתר, כך ש-CAP מושבת מופיע — ובאמצעות התראות Telegram, מגיע אליכם — לפני שהדלפק הקדמי מתקשר. WISPs ומפעילים מרובי-אתרים שמריצים MikroTik WiFi משתמשים בו כדי לגרום לעשרים אתרים להרגיש כמו לוח מחוונים אחד.

טיפים

• שמרו את הבקר ואת ה-CAPs על אותה גרסת חבילת wifi של RouterOS 7; אי-התאמות גורמות ל-CAPs לנשור ולהתקצות מחדש בלולאות.
• התחילו עם הקצאת create-dynamic-enabled כך שנקודות גישה חדשות עולות מוגדרות, ואז הדקו לכללים לפי דגם ככל שהצי גדל.
• השתמשו ב-datapaths של גישור מקומי עבור אתרים עתירי תעבורה כך שנתוני הלקוח לא יעברו הלוך ושוב (hairpin) דרך הבקר.
• תנו שם לפרופילי SSID ואבטחה לפי מטרה (“guest”, “staff”) ולא לפי מיקום, כך שפרופיל אחד משרת כל אתר באופן זהה.

נהלו WiFi, לא מדף של נתבים

CAPsMAN פותר צי AP אחד מבקר אחד. עסק פותר כל בקר ממקום אחד. MKController הוא מישור הבקרה הזה: דחיפת תצורה לכל הצי, ביקורת והיסטוריה של תצורות, גיבויים אוטומטיים, וגישה יוצאת מאובטחת לאתרים מאחורי CGNAT ללא IP ציבורי או port forwarding, בתוספת ניטור זמינות והתראות Telegram שחושפות CAP מושבת לפני שאורח מבחין שה-WiFi נפל. מפעילים שמריצים MikroTik על פני אתרים רבים משתמשים בו כדי לשמור כל מיקום על אותו עמוד ללא הנסיעה.

התחילו ניסיון חינם של MKController