- 802.1X ร่วมกับ FreeRADIUS ช่วยให้คุณสามารถกำหนด VLAN แบบไดนามิกโดยใช้แอตทริบิวต์ RADIUS มาตรฐานได้
- คอนโทรลเลอร์อย่าง Omada และ ExtremeCloud IQ ผสานรวม FreeRADIUS ได้เป็นอย่างดีเพื่อแยกผู้ใช้แบบใช้สายและแบบ Wi-Fi
- ข้อผิดพลาดในการสืบค้น LDAP, วิธีการ EAP ที่ไม่ปลอดภัย หรือสวิตช์ที่ตั้งค่าไม่ถูกต้อง จะทำให้การกำหนด VLAN ล้มเหลว
- การวางแผนนโยบายและการทดสอบที่ดีจะช่วยป้องกันปัญหาที่เกิดขึ้นกับ RDP อุปกรณ์รุ่นเก่า และสภาพแวดล้อมแบบไฮบริด

หากคุณจัดการเครือข่ายแบบมีสายหรือ Wi-Fi และต้องการแยกการรับส่งข้อมูลตามประเภทผู้ใช้โดยไม่ต้องใช้โซลูชัน NAC ที่มีราคาแพง การใช้802.1X, FreeRADIUS และการกำหนด VLAN แบบไดนามิกอย่าง มีประสิทธิภาพ เป็นหนึ่งในวิธีที่มีประสิทธิภาพที่สุดที่คุณสามารถทำได้ และคุ้มค่าที่จะทำความเข้าใจว่าสิ่งนี้สอดคล้องกับสถาปัตยกรรม Zero Trust อย่างไร หากนำไปใช้อย่างถูกต้อง จะช่วยให้คุณตัดสินใจได้ว่าอุปกรณ์แต่ละเครื่องจะเชื่อมต่อกับเครือข่ายใด โดยพิจารณาจากว่าอุปกรณ์นั้นเป็นใคร มาจากที่ใด หรืออยู่ในกลุ่มไดเร็กทอรีใด โดยไม่ต้องสร้าง SSID ทุกที่หรือผูกติดกับผู้จำหน่ายรายเดียว
ในบทความนี้ เราจะอธิบายรายละเอียดว่าชิ้นส่วนทั้งหมดประกอบเข้าด้วยกันอย่างไร: บทบาทของ 802.1X, การกำหนดค่า FreeRADIUS ทั่วไป, คุณสมบัติ RADIUS สำหรับ VLAN, การผสานรวมกับตัวควบคุม Wi-Fi และสวิตช์ , ตัวอย่างในโลกแห่งความเป็นจริง (Omada, ExtremeCloud IQ, สวิตช์แบบคลาสสิก), ปัญหาทั่วไป และแม้แต่หัวข้อขั้นสูง เช่น Azure AD และคุณสมบัติที่ไม่ถูกต้องใน LDAP เป้าหมายคือเพื่อให้คุณมีความเข้าใจที่ชัดเจนและนำไปใช้ได้จริง และสามารถปรับใช้สิ่งที่คุณเรียนรู้ในที่นี้กับโครงสร้างพื้นฐานของคุณเอง ไม่ว่าจะเป็นขนาดเล็กหรือขนาดใหญ่
802.1X และ Dynamic VLANs: แนวคิดพื้นฐานและส่วนประกอบต่างๆ
มาตรฐาน 802.1X นั้นกล่าวโดยง่ายก็คือ ทำหน้าที่เป็นผู้เฝ้าประตูของเครือข่ายของคุณ: จนกว่าอุปกรณ์จะตรวจสอบสิทธิ์เสร็จสิ้น พอร์ตหรือ Wi-Fi จะไม่อนุญาตให้เข้าถึงเครือข่ายที่ถูกต้อง เพื่อให้เกิดการแบ่งส่วนอย่างแท้จริง จึงต้องนำมาใช้ร่วมกับการกำหนด VLAN แบบไดนามิกโดยใช้แอตทริบิวต์ RADIUSเพื่อให้เซิร์ฟเวอร์เป็นผู้กำหนด VLAN ที่เหมาะสมให้กับไคลเอนต์แต่ละรายหลังจากตรวจสอบสิทธิ์เสร็จสิ้น
ในการติดตั้งใช้งาน 802.1X ใดๆ ก็ตาม จะมีส่วนประกอบหลักสามอย่างที่มักปรากฏอยู่เสมอ ไม่ว่าคุณจะใช้ Omada, ExtremeCloud IQ หรือสวิตช์ทั่วไปก็ตาม:
- ผู้ร้องขอ: อุปกรณ์ไคลเอ็นต์ที่ต้องการเชื่อมต่อ (แล็ปท็อป โทรศัพท์มือถือ เครื่องพิมพ์ที่พร้อมใช้งาน ฯลฯ)
- Authenticatorอุปกรณ์เครือข่ายที่ควบคุมการเข้าถึง (สวิตช์, AP หรือตัวควบคุม Wi-Fi) และสื่อสารกับเซิร์ฟเวอร์ RADIUS
- เซิร์ฟเวอร์การรับรองความถูกต้องโดยปกติแล้ว รัศมีโดยส่วนใหญ่จะเป็น FreeRADIUS ซึ่งจะตรวจสอบข้อมูลประจำตัวและกำหนดนโยบาย (อนุญาต ปฏิเสธ จัดอยู่ใน VLAN ใด VLAN หนึ่ง)
ความมหัศจรรย์ของ VLAN แบบไดนามิกนั้นอยู่ในรูปแบบของแอตทริบิวต์ RADIUS ภายในโปรโตคอล Access-Acceptสำหรับ VLAN นั้น ผู้ผลิตเกือบทุกรายเข้าใจถึงการรวมกันของแอตทริบิวต์ที่คล้ายกับอุโมงค์:
- ประเภทอุโมงค์ = VLAN
- อุโมงค์-ตัวกลาง-ประเภท = IEEE-802
- รหัสกลุ่มส่วนตัวอุโมงค์ = "รหัส VLAN" (โดยปกติจะเป็นตัวเลขระหว่าง 1 ถึง 4095 แม้ว่าจะส่งเป็นข้อความก็ตาม)
เมื่อสวิตช์หรือ AP ได้รับ Access-Accept ที่มีคุณสมบัติเหล่านี้ หากอุปกรณ์นั้นรองรับ 802.1X และ Dynamic VLAN อุปกรณ์จะกำหนดพอร์ตหรือเซสชัน Wi-Fi ให้กับVLAN ที่ระบุโดย RADIUS โดยไม่สนใจ VLAN หรือ SSID เริ่มต้นของพอร์ต (เว้นแต่ว่า RADIUS จะไม่ส่งข้อมูลใดๆ ในกรณีนี้ อุปกรณ์จะใช้การกำหนดค่าภายในเครื่อง)
การกำหนดค่า FreeRADIUS สำหรับ VLAN แบบไดนามิก
FreeRADIUS คือเซิร์ฟเวอร์ RADIUS แบบโอเพนซอร์สที่เป็นแบบอย่างที่ดีที่สุด สามารถติดตั้งได้บนระบบ Linux ทั่วไปแม้แต่ฮาร์ดแวร์ขนาดเล็กมาก เช่น NanoPi NEO หรือ Raspberry Pi และด้วยการกำหนดค่าที่เหมาะสม ก็สามารถรองรับสภาพแวดล้อมที่ต้องการประสิทธิภาพสูงได้ สำหรับ VLAN แบบไดนามิก มีสองส่วนสำคัญคือ การกำหนดผู้ใช้/กลุ่ม และการจัดวางโมดูลในห่วงโซ่การประมวลผลอย่างถูกต้อง
ในการติดตั้งแบบง่ายๆ ผู้ใช้ทดสอบสามารถกำหนดได้โดยตรงใน ไฟล์ ผู้ใช้ FreeRADIUS โดยกำหนด VLAN ที่พวกเขาควรได้รับ ไฟล์ทั่วไปใน Debian/Ubuntu จะอยู่ที่ /etc/freeradius/3.0/usersและรายการ VLAN จะมีลักษณะดังนี้ (แบบย่อและเขียนใหม่):
employee10 Cleartext-Password := "key10" Service-Type := Framed-User, Tunnel-Type := VLAN, Tunnel-Medium-Type := IEEE-802, Tunnel-Private-Group-Id := "10" employee20 Cleartext-Password := "key20" Service-Type := Framed-User, Tunnel-Type := VLAN, Tunnel-Medium-Type := IEEE-802, Tunnel-Private-Group-Id := "20"
ด้วยโครงสร้างนี้ FreeRADIUS จะส่งคืนค่าแอตทริบิวต์ของอุโมงค์ทั้งสามค่าหลังจากได้รับ Access-Accept เพื่อให้NAS (สวิตช์หรือ AP) สามารถจัดวางไคลเอ็นต์ลงใน VLAN 10 หรือ 20ได้ ขึ้นอยู่กับผู้ใช้ สิ่งสำคัญคืออุปกรณ์เครือข่ายต้องรองรับ RFC ที่เกี่ยวข้องและเคารพแอตทริบิวต์เหล่านี้ก่อน VLAN การเข้าถึงที่กำหนดค่าไว้
ในบางสถานการณ์ เช่น การผสานรวมกับ ExtremeCloud IQ จำเป็นอย่างยิ่งที่จะต้องส่งแอตทริบิวต์เหล่านี้อย่างแม่นยำในคำสั่ง Access-Acceptและไม่ใช่เพียงแค่แอตทริบิวต์ที่ "ส่งผ่าน" ในขั้นตอนอื่นๆ ของกระบวนการ EAP ในการกำหนดค่าเริ่มต้น FreeRADIUS อาจประมวลผล โมดูล eap ก่อน จากนั้นจึง ประมวลผลโมดูล ไฟล์ (ซึ่งอ่านไฟล์ผู้ใช้) ซึ่งทำให้คอนโทรลเลอร์พลาดแอตทริบิวต์ในเวลาที่เหมาะสม
วิธีแก้ปัญหาที่ได้ผลดีคือการปรับ ไฟล์ /etc/freeradius/3.0/sites-enabled/default โดยย้าย โมดูลไฟล์ ไป ไว้ก่อนeapภายใน บล็อก authorize ด้วยวิธีนี้ FreeRADIUS จะโหลดแอตทริบิวต์ผู้ใช้แบบคงที่ (รวมถึง VLAN) ก่อน แล้วจึงจัดการ EAP ดังนั้นเมื่อสร้าง Access-Accept สุดท้าย แอตทริบิวต์ของอุโมงค์จะถูกรวมไว้ใน ตำแหน่งที่คอนโทรลเลอร์คาด หวัง
อีกหนึ่งการปรับแต่งที่แนะนำคือ การปิดใช้งานวิธีการ EAP ที่ไม่แข็งแรง เช่นEAP-MD5ซึ่งไม่ได้ออกแบบมาสำหรับสภาพแวดล้อมการใช้งานจริง โดยการแก้ไขไฟล์/etc/freeradius/3.0/mods-enabled/eap และคอมเมนต์หรือลบส่วนของ MD5 ออก FreeRADIUS จะหยุดให้บริการวิธีการนี้ ควรเน้นการตั้งค่าไปที่วิธีการที่แข็งแกร่งกว่า เช่น EAP-TLS (ใบรับรอง) หรือPEAP กับ MSCHAPv2จะดีกว่า
การกำหนด VLAN ด้วย Omada: RADIUS ภายในและ FreeRADIUS ภายนอก
ระบบนิเวศ Omada ของ TP-Link (คอนโทรลเลอร์ + สวิตช์ + AP) ผสานรวม 802.1X กับ VLAN แบบไดนามิกได้อย่างลงตัว ทั้งโดยใช้RADIUS ภายในและโดยการมอบหมายงานไปยัง FreeRADIUS ภายนอก ตัวอย่างนี้แสดงให้เห็นอย่างชัดเจนเพราะขั้นตอนการทำงานทั้งหมดสามารถมองเห็นได้อย่างชัดเจน
โดยทั่วไปแล้ว การใช้งาน RADIUS ที่ติดตั้งมาในคอนโทรลเลอร์ Omada จะต้องทำตามกระบวนการสามขั้นตอน ขั้นแรก ในเมนูหลักของคอนโทรลเลอร์ จะต้องเปิดใช้ งาน RADIUS โดยระบุที่อยู่ IP (ของคอนโทรลเลอร์เอง) และเปิดใช้งาน ตัวเลือกTunneled Replyเพื่อให้ส่งแอตทริบิวต์ของอุโมงค์ไปยังอุปกรณ์เข้าถึงได้อย่างถูกต้อง
จากนั้น เมื่อเข้าไปที่ไซต์ที่ต้องการแล้ว ให้ไปที่การตั้งค่า > โปรไฟล์ > โปรไฟล์ RADIUSแก้ไขโปรไฟล์ และสร้างผู้ใช้ RADIUS ภายใน สำหรับผู้ใช้แต่ละราย Omada อนุญาตให้คุณตั้งชื่อ รหัสผ่าน และ VLAN IDเพื่อที่เมื่อผู้ใช้ยืนยันตัวตน ตัวควบคุมจะส่งคืนค่าแอตทริบิวต์ VLAN ไปยังสวิตช์หรือ AP โดยไม่ต้องผ่านเซิร์ฟเวอร์ภายนอก
สุดท้ายนี้ ในการตั้งค่า > การตรวจสอบสิทธิ์ > 802.1Xให้เปิดใช้งาน 802.1X เลือกโปรไฟล์ RADIUS ภายใน และเปิดใช้งานตัว เลือก การกำหนด VLAN อย่างชัดเจน ในส่วนเดียวกัน ให้เลือกพอร์ตสวิตช์ที่ต้องการการตรวจสอบสิทธิ์ 802.1X หลังจากบันทึกแล้ว อุปกรณ์ใดๆ ที่เชื่อมต่อกับพอร์ตเหล่านี้จะต้องตรวจสอบสิทธิ์ และหากบัญชีมีการกำหนด VLAN ID ไว้ ระบบจะจัดให้อยู่ใน VLAN นั้นโดยอัตโนมัติ
หากเราต้องการรวมศูนย์ทุกอย่างไว้บนเซิร์ฟเวอร์ FreeRADIUS ภายนอก Omada ก็รองรับสถานการณ์นี้ได้อย่างสมบูรณ์แบบ ขั้นตอนแรกคือการแก้ไข ไฟล์ clients.confบนเซิร์ฟเวอร์ FreeRADIUS เพื่ออนุญาตให้คอนโทรลเลอร์ (หรือช่วงที่สวิตช์/AP ตั้งอยู่) เป็นไคลเอ็นต์ RADIUS โดยระบุที่อยู่ IP หรือซับเน็ต และรหัสลับร่วมที่เราจะกำหนดค่าใน Omada ในภายหลัง
ถัดไป กลับไปที่ Omada สร้างโปรไฟล์ RADIUS ภายนอก จากการตั้งค่า > โปรไฟล์ > โปรไฟล์ RADIUSโดยป้อนที่อยู่ IP ของ FreeRADIUS พอร์ตการตรวจสอบสิทธิ์ (โดยปกติคือ 1812) และรหัสผ่านที่ใช้ร่วมกัน ในการตั้งค่า 802.1X ของคอนโทรลเลอร์ ให้เลือกโปรไฟล์ภายนอกนี้และเปิดใช้งานการกำหนด VLAN อีกครั้ง โดยทำเครื่องหมายพอร์ตหรือ SSID ที่คุณต้องการปกป้อง
สามารถตรวจสอบเพิ่มเติมได้จากตัวควบคุมเอง: ในTools > Terminalให้เปิดคอนโซลเชื่อมต่อกับสวิตช์ที่เปิดใช้งาน 802.1X แล้วเรียกใช้คำสั่งshow dot1x auth-stateหากทุกอย่างทำงานได้อย่างถูกต้อง คุณจะเห็นพอร์ตที่ได้รับการตรวจสอบสิทธิ์และ VLAN ที่กำหนดโดย RADIUS (ตัวอย่างเช่น พอร์ต 1/0/1 ได้รับการตรวจสอบสิทธิ์และเชื่อมโยงกับ VLAN 2)
VLAN แบบไดนามิกบน Wi-Fi ด้วย FreeRADIUS และ ExtremeCloud IQ
อีกตัวอย่างที่ครอบคลุมมากคือเครือข่าย Wi-Fi ที่จัดการโดยExtremeCloud IQ (XIQ)โดยใช้ FreeRADIUS เป็นเซิร์ฟเวอร์ตรวจสอบสิทธิ์ ในกรณีนี้ VLAN แบบไดนามิกจะถูกกำหนดให้กับไคลเอ็นต์ Wi-Fi โดยพิจารณาจากคุณลักษณะของอุโมงค์ที่ส่งคืนโดย FreeRADIUS เป็นหลัก
ขั้นแรก FreeRADIUS เตรียมพร้อมที่จะส่งแอตทริบิวต์ทั้งสามนั้นใน Access-Accept เช่นเดียวกับที่ผ่านมา ได้แก่ รายการใน/etc/freeradius/3.0/usersที่มีผู้ใช้และ VLAN ของพวกเขา และการตั้งค่าในsites-enabled/defaultเพื่อให้ โมดูล ไฟล์ถูกประมวลผลก่อนeapเนื่องจาก XIQ คาดหวังแอตทริบิวต์เหล่านั้นใน Accept อย่างถูกต้อง
ขอแนะนำอย่างยิ่งให้ปิดใช้งาน EAP-MD5 และใช้วิธีการอื่น เช่นPEAP/EAP-TLSแทน หลังจากแก้ไขไฟล์การกำหนดค่า EAP แล้ว ให้รีสตาร์ทบริการด้วยคำสั่ง ` systemctl restart freeradius`เพื่อให้การเปลี่ยนแปลงมีผล จากนั้นเซิร์ฟเวอร์จะพร้อมตอบสนองต่อคำขอที่ส่งมาจากจุดเชื่อมต่อที่จัดการโดย XIQ
ในส่วนของระบบคลาวด์ Extreme มีบัญชีใช้งานสองประเภทที่สำคัญ ได้แก่บัญชี Connect ฟรี ซึ่งอนุญาตให้จัดการอุปกรณ์ได้สูงสุดสิบเครื่อง แต่ไม่รองรับกฎการจัดประเภทขั้นสูงสำหรับ VLAN แบบไดนามิก และ เวอร์ชัน Pilotซึ่งมีให้ทดลองใช้งาน 90 วัน และเปิดใช้งานชุดโปรไฟล์และกฎทั้งหมดตามคุณลักษณะ RADIUS
ใช้บัญชี Pilot สร้างนโยบายเครือข่าย ใหม่ จากเมนู "กำหนดค่า > นโยบายเครือข่าย" ตั้งชื่อนโยบาย และเลือก "เฉพาะ Wi-Fi" เพื่อความสะดวก ในขั้นตอนที่สอง กำหนด SSID โดยทั่วไปจะเป็นเครือข่ายระดับองค์กรที่มี WPA2 หรือ WPA3 และเชื่อมโยงกลุ่ม RADIUSเมื่อสร้างกลุ่มนี้ ให้เพิ่ม FreeRADIUS เป็นเซิร์ฟเวอร์ภายนอก โดยระบุที่อยู่ IP รหัสลับ และพอร์ต 1812/1813
ถัดไป คือการกำหนดค่าโปรไฟล์ผู้ใช้ซึ่งในทางปฏิบัติคือโปรไฟล์การเข้าถึงที่เชื่อมโยงกับ VLAN ต่างๆ (ตัวอย่างเช่น VLAN10 และ VLAN20) จะมีโปรไฟล์เริ่มต้นที่จะถูกกำหนดให้กับไคลเอ็นต์ที่ RADIUS ไม่ส่งค่าแอตทริบิวต์อุโมงค์กลับมา แต่สำหรับ VLAN แบบไดนามิก กฎการกำหนดจะถูกกำหนดตาม ค่า Tunnel-Private-Group-IDและแอตทริบิวต์ RADIUS อื่นๆ
กฎระบุไว้อย่างง่ายๆ ว่า: "ถ้า Tunnel-Private-Group-ID ที่ส่งมาจาก Accept คือ 10 ให้กำหนด User Profile VLAN เป็น 10"; ถ้าเป็น 20 ให้กำหนด User Profile VLAN เป็น 20 และอื่นๆ ExtremeCloud IQ จะแปลงกฎเหล่านี้ในทางปฏิบัติโดยการวางไคลเอ็นต์ไว้ในVLAN ที่ตรงกับแอตทริบิวต์ที่ส่งมาจาก FreeRADIUS
สุดท้าย คุณต้องอนุญาตการเข้าถึง VLAN เหล่านี้ทางฝั่งเครือข่ายแบบมีสายของ AP โดยการปรับโปรไฟล์ AP ใน XIQ เพื่อให้พอร์ตอัปลิงก์อนุญาต VLAN ที่กำหนดค่าไว้ทั้งหมดและคงไว้ซึ่ง VLAN ดั้งเดิม (โดยปกติคือ VLAN 1) เมื่อบันทึกทุกอย่างและนำนโยบายเครือข่ายไปใช้กับ AP แล้ว คุณสามารถใช้ เครื่องมือ ทดสอบ RADIUSที่รวมอยู่ใน XIQ เพื่อตรวจสอบว่าสามารถเข้าถึง FreeRADIUS ได้และเซิร์ฟเวอร์ส่งคืนแอตทริบิวต์ VLAN ที่คาดหวังสำหรับผู้ใช้แต่ละราย
Omada SDN พร้อม FreeRADIUS: VLAN สำหรับเครือข่ายแบบมีสายและไร้สาย
โซลูชัน SDN ของ Omada ยังช่วยให้คุณสามารถกำหนด VLAN แบบไดนามิกพร้อมกันได้ทั้งในเครือ ข่าย แบบมีสายและไร้สายโดยใช้ RADIUS ภายนอก เช่น FreeRADIUS ซึ่งช่วยลดความจำเป็นในการสร้าง SSID ที่แตกต่างกันหลายรายการ หรือใช้ PVID แบบคงที่บนพอร์ตสวิตช์
โครงสร้างเครือข่ายทั่วไปประกอบด้วยคอนโทรลเลอร์ Omada, จุดเชื่อมต่อ EAP, สวิตช์ JetStream และเซิร์ฟเวอร์ FreeRADIUS ที่ทำงานบน Linux เพื่อให้อุปกรณ์เครือข่ายสามารถส่งคำขอตรวจสอบสิทธิ์ไปยังเซิร์ฟเวอร์ได้ จะ ต้องแก้ไขไฟล์ clients.confโดยตั้งค่าไคลเอ็นต์ให้ใช้ช่วงเครือข่าย Omada (ตัวอย่างเช่น 192.168.0.0/24) และรหัสผ่านที่ใช้ร่วมกัน
ถัดไป จะทำการตั้งค่าบัญชีใน ไฟล์ ผู้ใช้โดยกำหนดตัวอย่างเช่น ผู้ใช้สองคน: คนหนึ่งสำหรับ VLAN10 และอีกคนสำหรับ VLAN20 พร้อมด้วยแอตทริบิวต์ Tunnel-Type, Tunnel-Medium-Type และ Tunnel-Private-Group-Id ที่เกี่ยวข้อง ใน WPA-Enterprise มักจะมีการแก้ไข ไฟล์ การกำหนดค่า EAPเพื่อปรับวิธีการให้เข้ากับประเภทของไคลเอ็นต์ (ตัวอย่างเช่น EAP-PEAP สำหรับแล็ปท็อป Windows)
จากตัวควบคุม Omada ในส่วนการตรวจสอบสิทธิ์ ให้สร้างโปรไฟล์ RADIUSที่ชี้ไปยัง FreeRADIUS และเลือก ตัวเลือก "เปิดใช้งานการกำหนด VLAN สำหรับเครือข่ายไร้สาย"การดำเนินการนี้จะช่วยให้เมื่อไคลเอ็นต์ตรวจสอบสิทธิ์ผ่าน WPA-Enterprise แล้ว Omada จะสอบถามเซิร์ฟเวอร์ RADIUS และวางอุปกรณ์ไว้ใน VLAN ที่ได้รับจากเซิร์ฟเวอร์ แทนที่จะเป็น VLAN แบบคงที่ของ SSID
นอกจากนี้ยังจำเป็นต้องกำหนดค่าอินเทอร์เฟซ VLAN ของเครือข่ายในการตั้งค่า > เครือข่ายแบบมีสาย > LANโดยสร้างอินเทอร์เฟซเชิงตรรกะสองรายการสำหรับ VLAN10 และ VLAN20 พร้อมเกตเวย์ IP ที่เกี่ยวข้อง ตัวอย่างเช่น ด้วยวิธีนี้ เมื่อไคลเอนต์อยู่ใน VLAN10 จะได้รับที่อยู่ IP ภายในช่วงของ VLAN นั้นและเช่นเดียวกันสำหรับ VLAN20
ในส่วนของการเชื่อมต่อไร้สาย จะมีการสร้าง SSID โดยใช้WPA-Enterpriseซึ่งชี้ไปยังโปรไฟล์ RADIUS เมื่อไคลเอ็นต์เชื่อมต่อและตรวจสอบสิทธิ์ เช่น ใช้ test10 ผู้ใช้จะได้รับที่อยู่ IP จาก VLAN10 หากใช้ test20 พวกเขาจะได้รับการกำหนดให้เป็น VLAN20 โดยไม่ต้องสร้าง SSID เฉพาะสำหรับแต่ละกรณี
ในส่วนของการเชื่อมต่อแบบใช้สาย ตรรกะจะคล้ายกัน แต่ใช้802.1X แบบ Port-Basedโดยเปิดใช้งาน 802.1X ในส่วนที่เกี่ยวข้องของคอนโทรลเลอร์ เลือกประเภท "Port Based" เปิดใช้งาน "VLAN Assignment" และทำเครื่องหมายพอร์ตที่ต้องการการตรวจสอบสิทธิ์ จากนั้น จึงใช้ โปรไฟล์พอร์ต กับพอร์ตเหล่านั้น โดยเพิ่ม VLAN10 และ VLAN20 เป็นเครือข่ายที่ไม่ติดแท็ก ตรวจสอบให้แน่ใจว่าโหมดควบคุม 802.1X ถูกตั้งค่าเป็น "Auto" เพื่อให้สวิตช์เริ่มต้นการเจรจาเมื่อตรวจพบไคลเอ็นต์
ดังนั้น ด้วยการตั้งค่า RADIUS เพียงครั้งเดียวและโปรไฟล์เพียงไม่กี่รายการ Omada SDN จึงมั่นใจได้ว่าผู้ใช้ทั้งแบบใช้สายและ Wi-Fi จะอยู่ในVLAN ที่ตรงกับข้อมูลประจำตัว ของตน โดยไม่ต้องสร้างเครือข่ายเพิ่มหรือปรับแต่งการตั้งค่าของแต่ละพอร์ตด้วยตนเอง
ตัวอย่างการใช้งานจริง ข้อผิดพลาดที่พบบ่อย และเคล็ดลับการตั้งค่า
การใช้งาน FreeRADIUS และ VLAN แบบไดนามิกไม่ได้ราบรื่นเสมอไป: ปัญหาที่เกิดขึ้นซ้ำๆ หลายอย่างเกิดขึ้นเมื่อเปลี่ยนจากการทดสอบในห้องปฏิบัติการไปสู่สภาพแวดล้อมจริง โดยเฉพาะอย่างยิ่งเมื่อต้องจัดการกับไดเร็กทอรี LDAP/AD รูปแบบชื่อผู้ใช้ และนโยบายที่ซับซ้อนดังนั้นการจัดการความเสี่ยงด้านความปลอดภัยทางไซเบอร์ ที่ดี จึงช่วยลดเหตุการณ์ต่างๆ ได้
ข้อผิดพลาดที่พบได้บ่อยมากอย่างหนึ่งคือ เมื่อเซิร์ฟเวอร์สร้างคำสั่งค้นหา LDAP โดยใช้แอตทริบิวต์ %{ชื่อผู้ใช้} เนื่องจากข้อมูลมาถึงในรูปแบบ RADIUS ในหลายกรณีของ Windows รูปแบบจะมาในรูปแบบนี้ โดเมน\ผู้ใช้โดยมีการเข้ารหัสเครื่องหมายแบ็กสแลชเป็น 5cหากเทมเพลต LDAP ถูกสร้างขึ้นด้วย uid=%{User-Name}ผลลัพธ์ของคำสั่งค้นหาจะมีลักษณะประมาณนี้ uid=DOMINIO\5cusuarioซึ่งแทบจะไม่ตรงกับ uid จริงในโครงสร้าง LDAP และส่งผลให้ไม่มีผลลัพธ์ใดๆ เลย
หมายความว่าแอตทริบิวต์ของผู้ใช้ รวมถึง ค่า VLAN หรือกลุ่ม ที่จะแมป ไม่พบในไดเร็กทอรีดังนั้นเซิร์ฟเวอร์จึงไม่เพิ่ม Tunnel-Private-Group-Id และไคลเอ็นต์จะยังคงอยู่ใน VLAN เริ่มต้นของสวิตช์หรือ AP รูปแบบนี้สามารถมองเห็นได้อย่างชัดเจนในบันทึกของ FreeRADIUS: การสืบค้น LDAP ด้วย uid "domain\5user" และผลการค้นหาว่างเปล่า
วิธีแก้ปัญหาที่ใช้ได้ผลจริงคือ การเปลี่ยนการใช้%{User-Name}เป็น%{Stripped-User-Name}ในเทมเพลตการสืบค้น LDAP ในการตั้งค่า FreeRADIUS ตัวอย่างเช่น:
ถ้า ("%{ldap:ldap:///dc=example,dc=com?uid?sub?(|(uid=%{Stripped-User-Name})(macAddress=%{Calling-Station-Id}))}") { ... }
ด้วยวิธีนี้ FreeRADIUS จะใช้ชื่อผู้ใช้ที่ "สะอาด" โดยไม่มีโดเมนหรือเครื่องหมายทับ และการค้นหาก็จะสำเร็จอีกครั้ง ทันทีที่ LDAP ส่งคืนรายการที่ถูกต้อง เซิร์ฟเวอร์ก็สามารถใช้ตรรกะในการกำหนด VLAN ตามกลุ่ม หน่วยองค์กร (OU) หรือคุณลักษณะเฉพาะ สร้างTunnel-Type, Tunnel-Medium-Type และ Tunnel-Private-Group-Id ขึ้นมาใหม่ ใน Access-Accept
อีกกรณีที่น่าสนใจเกิดขึ้นกับสวิตช์บางตัว เมื่อมีการกำหนดค่า VLAN แบบคงที่บนพอร์ต ร่วมกับการกำหนดค่า 802.1X แบบไดนามิก ตัวอย่างเช่น การกำหนดพอร์ต 17 ให้เป็น VLAN 4 แบบคงที่ ในขณะเดียวกันก็พยายามบังคับให้ผู้ใช้เฉพาะรายหนึ่งใช้ VLAN 2 โดยใช้ RADIUS หากอุปกรณ์ไม่เคารพคุณสมบัติของอุโมงค์ หรือฟังก์ชัน VLAN แบบไดนามิกถูกปิดใช้งาน ไม่ว่าอะไรจะเกิดขึ้นใน RADIUS พอร์ตนั้นก็จะยังคงมองเห็นทราฟฟิกเป็น VLAN 4 อยู่ดี
ในสถานการณ์เหล่านี้ สิ่งสำคัญคือต้องตรวจสอบเอกสารประกอบของสวิตช์เพื่อเปิดใช้งานการสนับสนุนการกำหนด VLAN ผ่าน RADIUS อย่างชัดเจน และทำการดีบักโดยใช้คำสั่งเช่น ` show dot1x`หรือคำสั่งที่เทียบเท่า ตรวจสอบว่าอุปกรณ์รายงานข้อความใดๆ เช่น "ignoring tunnel attributes" หรือ "dynamic vlan assignment disabled" หรือไม่ เฉพาะเมื่อผู้ผลิตสนับสนุนและเปิดใช้งานแล้ว ผู้ใช้ที่เชื่อมต่อกับพอร์ตทางกายภาพใน VLAN 4 โดยค่าเริ่มต้น จะไปอยู่ใน VLAN 2 หลังจากตรวจสอบสิทธิ์ในฐานะ "carlos" หรือใครก็ตาม
นอกจากนี้ ยังมีการถกเถียงกันอย่างคลาสสิกเกี่ยวกับความเหมาะสมของการใช้VLAN แบบไดนามิกในสถานการณ์การเข้าถึงระยะไกล (RDP)เมื่อมีการตรวจสอบสิทธิ์เครื่องในระหว่างการเริ่มต้นระบบ Windows และจากนั้นตรวจสอบสิทธิ์ผู้ใช้ในระหว่างการเข้าสู่ระบบ การเปลี่ยนแปลง VLAN ที่เกิดจากการเข้าสู่ระบบของผู้ใช้ อาจขัดจังหวะเซสชัน RDP ที่กำลังดำเนินอยู่ หรือทำให้เกิดปัญหา DNS เนื่องจากพอร์ตจะเปลี่ยนจาก VLAN "เครื่อง" ไปยัง VLAN "ผู้ใช้" ผู้ดูแลระบบหลายคนจึงเลือกที่จะใช้ VLAN เดียวสำหรับทุกสถานะในกรณีเหล่านี้ หรือกำหนด VLAN เดียวกันทั้งในระดับเครื่องและระดับผู้ใช้ เพื่อลดการเปลี่ยนแปลงเซ็กเมนต์ให้น้อยที่สุด
สุดท้ายนี้ ในระดับการบูรณาการขั้นสูง มีความสนใจเพิ่มมากขึ้นในการเชื่อมโยง FreeRADIUS กับAzure ADเพื่อกำหนด VLAN โดยอิงจากการเป็นสมาชิกกลุ่มในระบบคลาวด์ ปัจจุบัน ยังไม่มีโมดูลดั้งเดิมอย่างเป็นทางการที่ทำการค้นหากลุ่มโดยตรงสำหรับ VLAN ใน Azure AD และวิธีแก้ปัญหาชั่วคราวเกี่ยวข้องกับการใช้สคริปต์ภายนอก การเรียกใช้ Microsoft Graph API และการปรับแต่งบางอย่าง เป็นเรื่องที่มีการเปลี่ยนแปลงอยู่ตลอดเวลา และหากต้องการโซลูชันที่เสถียรและได้รับการสนับสนุน ตรรกะนี้มักจะถูกมอบหมายให้กับ NAC เชิงพาณิชย์หรือส่วนประกอบตัวกลางอื่น ๆ
ด้วยการผสานรวม 802.1X, FreeRADIUS และการกำหนด VLAN แบบไดนามิกอย่างมีประสิทธิภาพ ทำให้สามารถแบ่งส่วนเครือข่ายได้อย่างละเอียดโดยไม่จำเป็นต้องใช้โซลูชัน NAC ที่ยุ่งยาก ซึ่งสอดคล้องกับ กลยุทธ์ ด้านความปลอดภัยทางเทคโนโลยีขององค์กร อย่างแข็งแกร่ง : ตั้งแต่คอนโทรลเลอร์อย่าง Omada หรือ ExtremeCloud IQ ไปจนถึงสวิตช์ระดับกลาง ทุกอย่างสามารถมีส่วนร่วมได้หากมีการเคารพคุณสมบัติของอุโมงค์ การจัดการการสืบค้น LDAP/AD อย่างรอบคอบ และมีความชัดเจนว่าเมื่อใดควรย้ายผู้ใช้จาก VLAN หนึ่งไปยังอีก VLAN หนึ่งแบบไดนามิกตามตัวตน บทบาท หรือประเภทของอุปกรณ์ที่เชื่อมต่อ
