จัดการ WiFi รวมศูนย์ด้วย MikroTik CAPsMAN

สรุป MikroTik CAPsMAN เปลี่ยนอุปกรณ์ RouterOS หนึ่งเครื่องให้เป็น wireless controller ที่ตั้งค่า access point ทุกตัวจากจุดเดียว แทนที่จะต้องล็อกอินเข้าแต่ละ AP เพื่อเปลี่ยน SSID หรือรหัสผ่าน คุณแก้ profile เดียวแล้ว CAPsMAN จะส่งค่านั้นไปยังทั้งฟลีต ใน RouterOS 7 ตัว controller ถูกฝังอยู่ในแพ็กเกจ wifi อยู่แล้ว ไม่ต้องติดตั้งส่วนเสริมใดๆ คู่มือนี้พาไปตลอดทั้งสาย เปิดใช้งาน manager, ลงทะเบียน AP ของคุณเป็น CAP, สร้างกฎ provisioning, รักษาความปลอดภัยของ control channel และขยายรูปแบบนี้ไปทุกไซต์

MikroTik CAPsMAN คืออะไร

MikroTik CAPsMAN คือ wireless controller ที่มีมาในตัวของ RouterOS เป็นระบบ Controlled Access Point system Manager ที่เก็บการตั้งค่าของกลุ่ม access point ไว้ และ provision แต่ละตัวโดยอัตโนมัติเมื่อเชื่อมต่อเข้ามา (MikroTik Documentation — AP Controller (CAPsMAN)) เครือข่ายแบ่งออกเป็นสองบทบาท คือ manager (CAPsMAN) ซึ่งเก็บการตั้งค่า SSID, security และ channel และ CAP จำนวนเท่าใดก็ได้ ซึ่งเป็น access point ที่ให้สัญญาณวิทยุจริง และมอบการตั้งค่าของตัวเองขึ้นไปให้ manager

ผลตอบแทนคือแหล่งความจริงเดียวสำหรับ WiFi เปลี่ยนรหัสผ่าน guest ครั้งเดียวแล้ว CAP ทุกตัวสืบทอดค่านั้น เพิ่ม AP หนึ่งตัวแล้วมัน provision ตัวเองตามกฎที่คุณเขียนไว้แล้ว อุปกรณ์ใดก็ตามที่มี license ระดับ 4 ขึ้นไปสามารถทำหน้าที่เป็น CAP ได้ (MikroTik Documentation — WiFi)

ขั้นตอนที่ 1 — เปิดใช้งาน CAPsMAN manager

เลือกอุปกรณ์ที่จะทำหน้าที่ controller มักเป็นเราเตอร์หลัก แม้ว่าอุปกรณ์ RouterOS 7 เครื่องใดที่มีแพ็กเกจ wifi ก็โฮสต์ได้ ตรวจสอบว่ามีแพ็กเกจอยู่ภายใต้ /system/package แล้วเปิดใช้งาน manager ด้วย /interface/wifi/capsman/set enabled=yes ตั้งค่า package-path และ upgrade-policy หากต้องการให้ CAP ดึงแพ็กเกจ wifi ที่ตรงกันจาก controller เพื่อให้เฟิร์มแวร์สอดคล้องกัน (MikroTik Documentation — AP Controller (CAPsMAN))

ตอนนี้ controller รอฟัง CAP อยู่ แต่ยังไม่ได้จัดการอะไรเลย ส่วนนั้นมาจากกฎในขั้นตอนที่ 3 สังเกต interface ที่ manager รอฟังอยู่ โดยค่าเริ่มต้น CAP จะค้นพบมันผ่าน Layer 2 ดังนั้น controller และ AP ควรอยู่ใน broadcast domain เดียวกันระหว่างการลงทะเบียน หรือถูก bridge เข้าหากัน

ขั้นตอนที่ 2 — แปลง access point ของคุณให้เป็น CAP

บนแต่ละ access point มอบสัญญาณวิทยุให้ controller เปิดใช้งาน CAP mode ด้วย /interface/wifi/cap/set enabled=yes ระบุ interface ที่ AP ควรเสนอขึ้นไปด้วย slaves-datapath และ discovery-interfaces และตั้งค่า caps-man-addresses หากคุณชี้ไปยัง controller ด้วย IP แทนที่จะพึ่งการค้นพบผ่าน Layer 2 (MikroTik Documentation — WiFi) เมื่อ CAP พบ manager แล้ว การตั้งค่าวิทยุ local ของมันจะถูกแทนที่ด้วยสิ่งที่ CAPsMAN provision ให้

ฮาร์ดแวร์มีความสำคัญในจุดนี้ CAP ดีได้เท่าที่วิทยุของมันดี AP แบบ Wi-Fi 6 และ Wi-Fi 7 อย่าง MikroTik hAP be lite เป็น CAP ที่ยอดเยี่ยม เพราะ CAPsMAN สามารถขับเคลื่อนวิทยุรุ่นใหม่เหล่านั้นจากศูนย์กลางได้ และการปรับ band และ channel ที่ปกติคุณต้องทำทีละอุปกรณ์ อย่างที่ครอบคลุมในคู่มือการตั้งค่า WiFi 6 บนเราเตอร์ MikroTik AX ของเรา กลายเป็น profile ที่คุณเขียนเพียงครั้งเดียว

ขั้นตอนที่ 3 — สร้าง configuration และกฎ provisioning

นี่คือจุดที่ CAPsMAN แสดงคุณค่าของมัน configuration profile กำหนด SSID, security (authentication-types, passphrase), country และแผน channel ส่วน datapath ตัดสินว่า traffic ของ CAP จะไปถึงเครือข่ายอย่างไร ผ่าน bridge ในเครื่องที่ AP หรือ tunnel กลับมาที่ controller จากนั้นกฎ provisioning จะจับคู่ CAP ที่เชื่อมต่อเข้ามา ด้วย MAC ของวิทยุ, รุ่น หรือ identity แล้วใช้ configuration ที่ถูกต้องโดยอัตโนมัติ (MikroTik Documentation — AP Controller (CAPsMAN)) เขียน /interface/wifi/provisioning add action=create-dynamic-enabled ... เพื่อให้ AP ใหม่ตั้งค่าตัวเองแทนที่จะรอคุณ

เนื่องจาก traffic ของ CAP มักลงเอยบน bridge ขั้นตอนนี้ถือว่า Layer 2 ของคุณสะอาดอยู่แล้ว หากการทำ bridge เป็นเรื่องใหม่สำหรับคุณ คู่มือการตั้งค่า bridge บน MikroTik ของเราครอบคลุมพื้นฐานไว้ และนี่คือขีดจำกัดที่แท้จริงของ CAPsMAN มันรวมศูนย์ WiFi ภายในระยะที่ controller หนึ่งตัวเอื้อมถึง ตัว controller เอง หนึ่งตัวต่อหนึ่งอาคาร ต่อสาขา ต่อไซต์เสาสัญญาณ ยังคงเป็นเราเตอร์แยกกันที่คุณต้องคอยรักษาให้ sync กัน ชั้นที่สองนั้นแหละคือสิ่งที่การจัดการการตั้งค่าฟลีตของ MKController จัดการให้ ส่ง CAPsMAN profile ที่เหมือนกัน ไปยังทุก controller พร้อมกัน และใช้ ประวัติการดำเนินการ เพื่อดูว่าใครเปลี่ยนอะไร เมื่อไร และไซต์ไหนคลาดเคลื่อนไป

ขั้นตอนที่ 4 — แยก management VLAN และรักษาความปลอดภัยการเข้าถึง

ปฏิบัติกับ control channel ของ CAPsMAN ในฐานะโครงสร้างพื้นฐาน ไม่ใช่เรื่องรอง นำ traffic ระหว่าง CAP กับ manager ไปไว้บน management VLAN เฉพาะ กันมันออกจาก SSID ของ guest และ client อย่างสิ้นเชิง และจำกัดว่า manager จะรับ CAP บน interface ใดบ้าง management VLAN ยังหยุดไม่ให้เครือข่าย client ที่จอแจไปแตะระนาบที่ควบคุมวิทยุของคุณได้ (MikroTik community — CAPsMAN with management VLAN)

การควบคุมแบบรวมศูนย์มีสองด้าน กฎ provisioning ที่ผิดหนึ่งข้อไม่ได้ทำให้ AP ตัวเดียวเสีย แต่ทำให้ทั้งหมดเสียพร้อมกัน ก่อนที่คุณจะส่งการเปลี่ยน channel หรือ security ไปทั้งฟลีต คุณต้องมี backup ที่ย้อนกลับได้ และมีทางเข้าเผื่อการเปลี่ยนแปลงล็อกคุณออกไป MKController เก็บ backup แบบ binary อัตโนมัติรายวัน ของทุกอุปกรณ์ ห้าเวอร์ชันล่าสุดบนคลาวด์ และให้คุณสร้าง backup ด้วยมือได้ทันทีก่อนการส่งที่เสี่ยง เพื่อให้การส่ง CAPsMAN ที่ผิดพลาดกลายเป็นการกู้คืนคลิกเดียวสู่สถานะที่ดีล่าสุดที่รู้จัก แทนที่จะต้องขับรถไปที่ไซต์พร้อมสาย console

ขั้นตอนที่ 5 — ใช้งาน CAPsMAN ในทุกไซต์

controller หนึ่งตัวกับ CAP ไม่กี่ตัวคืองานบ่ายเดียว งานจริงคือสถานที่ที่สิบ อาคารต่อเติมของโรงแรม เสาสัญญาณต้นที่สอง วิทยาเขตของลูกค้า แต่ละที่มี controller ของตัวเองอยู่หลัง LTE หรือ Starlink และ Carrier-Grade NAT โดยไม่มี IP สาธารณะให้เข้าถึงเมื่อ AP เงียบหายไป นั่นคือกำแพงที่บทช่วยสอนแบบไซต์เดียวไม่เคยพูดถึง

นี่คืองานที่ต้องทำจริงของผู้อ่าน และเป็นจุดที่ control plane สำคัญที่สุด MKController ทำให้ controller ทุกตัวเข้าถึงได้ผ่าน tunnel ขาออกที่ปลอดภัย ไม่ต้องทำ port forwarding ไม่ต้องมี address สาธารณะ ตามที่อธิบายไว้ในคู่มือการจัดการ MikroTik ระยะไกลเบื้องหลัง CGNAT (NATCloud) ของเรา ส่ง CAPsMAN profile ที่เหมือนกันไปทั้งฟลีต และติดตาม ความพร้อมใช้งานของอุปกรณ์ ของแต่ละไซต์ เพื่อให้ CAP ที่ล่มปรากฏขึ้น และด้วยการแจ้งเตือนผ่าน Telegram ก็ถึงมือคุณ ก่อนที่พนักงานหน้าเคาน์เตอร์จะโทรมา WISP และผู้ให้บริการหลายไซต์ที่รัน MikroTik WiFi ใช้มันเพื่อทำให้ยี่สิบไซต์รู้สึกเหมือนแดชบอร์ดเดียว

เคล็ดลับ

• รักษา controller และ CAP ให้อยู่บนแพ็กเกจ wifi ของ RouterOS 7 เวอร์ชันเดียวกัน ความไม่ตรงกันทำให้ CAP หลุดและ re-provision วนซ้ำ
• เริ่มด้วย provisioning แบบ create-dynamic-enabled เพื่อให้ AP ใหม่ออนไลน์มาพร้อมตั้งค่าแล้ว จากนั้นค่อยรัดกุมขึ้นเป็นกฎแบบต่อรุ่นเมื่อฟลีตโตขึ้น
• ใช้ datapath แบบ bridge ในเครื่องสำหรับไซต์ที่ traffic สูง เพื่อไม่ให้ข้อมูล client วิ่งอ้อมผ่าน controller
• ตั้งชื่อ profile ของ SSID และ security ตามวัตถุประสงค์ (“guest”, “staff”) ไม่ใช่ตามสถานที่ เพื่อให้ profile เดียวใช้ได้เหมือนกันในทุกไซต์

จัดการ WiFi ไม่ใช่แร็คของเราเตอร์

CAPsMAN แก้ปัญหา AP ฟลีตหนึ่งจาก controller หนึ่งตัว ธุรกิจแก้ปัญหา controller ทุกตัว จากที่เดียว MKController คือ control plane นั้น การส่งการตั้งค่าทั้งฟลีต การตรวจสอบและประวัติการตั้งค่า การสำรองข้อมูลอัตโนมัติ และการเข้าถึงไซต์ที่อยู่หลัง CGNAT อย่างปลอดภัยผ่านช่องทางขาออกโดยไม่ต้องมี IP สาธารณะหรือ port forwarding พร้อมการมอนิเตอร์ความพร้อมใช้งานและการแจ้งเตือนผ่าน Telegram ที่เผยให้เห็น CAP ที่ล่มก่อนที่ guest จะสังเกตว่า WiFi หลุด ผู้ให้บริการที่รัน MikroTik ในหลายไซต์ใช้มันเพื่อให้ทุกสถานที่อยู่บนหน้าเดียวกันโดยไม่ต้องขับรถไป

เริ่มทดลองใช้ MKController ฟรี