802.1X, FreeRADIUS та динамічні VLAN: повний посібник

Інформатек Діджитал » Ресурси » 802.1X, FreeRADIUS та динамічні VLAN: повний посібник

Якщо ви керуєте дротовими або 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 та динамічні VLAN: основні поняття та компоненти

Стандарт 802.1X, простіше кажучи, є «гейткепером» вашої мережі: доки пристрій не пройде автентифікацію, порт або Wi-Fi не надасть йому доступу до легітимної мережі. Для досягнення справжньої сегментації вона поєднується з динамічним призначенням VLAN за допомогою атрибутів RADIUS , тому сервер вирішує, до якої VLAN буде призначено кожного клієнта після автентифікації.

У будь-якому розгортанні 802.1X завжди присутні три ключові компоненти, незалежно від того, чи використовуєте ви Omada, ExtremeCloud IQ чи універсальні комутатори:

• Прохач: клієнт, який хоче підключитися (ноутбук, мобільний телефон, «готовий» принтер тощо).
• Authenticator: мережеве обладнання, яке контролює доступ (комутатор, точка доступу або контролер Wi-Fi) та яке взаємодіє із сервером RADIUS.
• Сервер автентифікаціїзазвичай RADIUS, часто FreeRADIUS, який перевіряє облікові дані та визначає політику (дозволити, заборонити, додати до тієї чи іншої VLAN).

Магія динамічних VLAN поширюється у формі атрибутів RADIUS у протоколі Access-Accept . Для VLAN майже всі виробники розуміють комбінацію тунельно-подібних атрибутів:

• Тип тунелю = VLAN
• Тип тунельного середовища = IEEE-802
• Ідентифікатор приватної групи тунелю = "VLAN ID" (зазвичай число від 1 до 4095, хоча воно надсилається як текст)

Коли комутатор або точка доступу отримує запит на підтвердження доступу з цими атрибутами, якщо він підтримує 802.1X та динамічну 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 Пароль відкритого тексту: = "key10" Тип служби: = Користувач у фреймі, Тип тунелю: = VLAN, Тип середовища тунелю: = IEEE-802, Ідентифікатор приватної групи тунелю: = "10" employee20 Пароль відкритого тексту: = "key20" Тип служби: = Користувач у фреймі, Тип тунелю: = VLAN, Тип середовища тунелю: = IEEE-802, Ідентифікатор приватної групи тунелю: = "20"

З такою структурою FreeRADIUS повертатиме після запиту Access-Accept три атрибути тунелю, щоб NAS (комутатор або точка доступу) міг розмістити клієнта у VLAN 10 або 20, залежно від користувача. Головне, щоб мережеве обладнання підтримувало відповідний RFC та враховувало ці атрибути перед налаштованою VLAN доступу.

У деяких сценаріях, таких як інтеграція з ExtremeCloud IQ, критично важливо, щоб ці атрибути надсилалися саме в операторі Access-Accept , а не просто як "тунельовані" атрибути на інших фазах процесу EAP. У конфігураціях за замовчуванням FreeRADIUS може спочатку обробляти модуль eap , а потім модуль files (який зчитує файл користувачів). Це призводить до того, що контролер пропускає атрибути у відповідний момент.

Практичне рішення, яке виявилося корисним, полягає в коригуванні файлу /etc/freeradius/3.0/sites-enabled/default , перемістивши модуль files перед 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 (контролер + комутатори + точка доступу) дуже добре інтегрує 802.1X з динамічними VLAN, використовуючи як внутрішній RADIUS , так і делегуючи на зовнішній FreeRADIUS. Це дуже показовий приклад, оскільки весь робочий процес чітко видно.

Щоб використовувати вбудований у контролер Omada RADIUS, зазвичай виконується триетапний процес. Спочатку в глобальному меню контролера вмикається вбудований RADIUS шляхом вказівки IP-адреси (самого контролера) та активації опції « Туннельована відповідь » , щоб він правильно надсилав атрибути тунелю на пристрій доступу.

Потім, опинившись на певному сайті, перейдіть до Налаштування > Профіль > Профіль RADIUS , відредагуйте профіль та створіть внутрішніх користувачів RADIUS. Omada дозволяє встановити для кожного користувача ім'я, пароль та ідентифікатор VLAN , щоб під час автентифікації користувача контролер повертав атрибути VLAN до комутатора або точки доступу без використання зовнішнього сервера.

Нарешті, у розділі Налаштування > Аутентифікація > 802.1X увімкніть 802.1X, виберіть внутрішній профіль RADIUS та явно увімкніть опцію Призначення VLAN . У тому ж розділі виберіть порти комутатора, які потребуватимуть автентифікації 802.1X. Після збереження будь-який пристрій, що підключається до цих портів, потребуватиме автентифікації, і якщо обліковому запису призначено ідентифікатор VLAN, він буде автоматично розміщено в цій VLAN.

Якщо ми віддаємо перевагу централізації всього на зовнішньому сервері FreeRADIUS, Omada чудово підтримує цей сценарій. Першим кроком є ​​редагування файлу clients.conf на сервері FreeRADIUS, щоб авторизувати контролер (або діапазон, де розташовані комутатори/точки доступу) як клієнта RADIUS, вказавши IP-адресу або підмережу та спільний секретний ключ , який ми пізніше налаштуємо в Omada.

Далі, повернувшись до Omada, створіть зовнішній профіль RADIUS у меню Налаштування > Профілі > Профіль RADIUS , де ви вводите IP-адресу FreeRADIUS, порт автентифікації (зазвичай 1812) та спільний пароль. У налаштуваннях 802.1X контролера виберіть цей зовнішній профіль і знову ввімкніть призначення VLAN , позначивши порти або SSID, які ви хочете захистити.

Подальшу перевірку можна виконати з самого контролера: у меню Інструменти > Термінал відкрийте консоль комутатора з увімкненим 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 , щоб модуль files оброблявся перед eap , оскільки XIQ очікує саме ці атрибути в Accept.

Наполегливо рекомендується вимкнути EAP-MD5 та використовувати такі методи, як PEAP/EAP-TLS . Після зміни файлу конфігурації EAP перезапустіть службу за допомогою команди ` systemctl restart freeradius`, щоб застосувати зміни. З цього моменту сервер буде готовий відповідати на запити, надіслані точками доступу, якими керує XIQ.

Щодо Extreme Cloud, є два відповідні типи облікових записів: безкоштовний обліковий запис Connect , який дозволяє базове керування до десяти пристроїв, але не підтримує розширені правила класифікації для динамічних VLAN, та версія Pilot , яка пропонує 90-денну пробну версію та дозволяє використовувати повний набір профілів і правил на основі атрибутів RADIUS.

Використовуючи обліковий запис Pilot, створіть нову мережеву політику в меню «Налаштування > Мережеві політики», назвіть її та для спрощення виберіть «Тільки Wi-Fi». На другому кроці визначте SSID, зазвичай як мережу Enterprise з WPA2 або WPA3, та пов’яжіть групу RADIUS . Під час створення цієї групи додайте FreeRADIUS як зовнішній сервер, вказавши його IP-адресу, секретний ключ та порти 1812/1813.

Далі налаштовуються профілі користувачів , які на практиці є профілями доступу, пов'язаними з різними VLAN (наприклад, VLAN10 та VLAN20). Існує профіль за замовчуванням, який буде призначено клієнтам, RADIUS яких не повертає атрибути тунелю, але для динамічних VLAN правила призначення визначаються на основі значення Tunnel-Private-Group-ID та інших атрибутів RADIUS.

Правила просто говорять: «якщо ідентифікатор приватної групи тунелю (Tunnel-Private-Group-ID), що надходить від Accept, дорівнює 10, призначити профілю користувача VLAN 10»; якщо він дорівнює 20, призначити профілю користувача VLAN 20 тощо. ExtremeCloud IQ на практиці застосовує ці правила до розміщення клієнта у VLAN, яка відповідає атрибуту, надісланому від FreeRADIUS.

Нарешті, вам потрібно надати доступ до цих VLAN на дротовій стороні точки доступу, налаштувавши профіль точки доступу в XIQ таким чином, щоб порт висхідного каналу дозволяв усі налаштовані VLAN та підтримував власну VLAN (зазвичай VLAN 1). Після того, як усе збережено та політика мережі застосовано до точок доступу, ви можете скористатися інструментом RADIUS Test , інтегрованим у 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) та спільний пароль.

Далі облікові записи налаштовуються у файлі users , визначаючи, наприклад, двох користувачів: одного для 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 комутатора або точки доступу за замовчуванням. Ця закономірність чітко видно в журналах 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 на основі груп, організаційних одиниць або певних атрибутів, знову генеруючи 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` або еквівалентних, перевіряючи, чи повідомляє пристрій щось на кшталт «ігнорування атрибутів тунелю» або «динамічне призначення VLAN вимкнено». Тільки коли виробник підтримує цю функцію і вона ввімкнена, користувач, підключений до фізичного порту у VLAN 4 за замовчуванням, фактично опиниться у VLAN 2 після автентифікації як «carlos» або хто завгодно.

Також точаться класичні дебати щодо доцільності використання динамічних VLAN у сценаріях віддаленого робочого столу (RDP) . Коли автентифікація машини відбувається під час запуску Windows, а потім автентифікація користувача під час входу в систему, зміна VLAN, викликана входом користувача, може перервати поточні сеанси RDP або спричинити проблеми з DNS, оскільки порт перемикається з VLAN «машини» на VLAN «користувача». Багато адміністраторів вирішили підтримувати одну VLAN для всіх станів у цих випадках або призначати одну й ту саму VLAN як на рівні машини, так і на рівні користувача, мінімізуючи зміни сегментів.

Зрештою, на рівні розширеної інтеграції зростає інтерес до зв'язування FreeRADIUS з Azure AD для визначення VLAN на основі членства в групах у хмарі. Наразі немає офіційного власного модуля, який би здійснював прямий пошук груп для VLAN в Azure AD, а обхідні шляхи включають зовнішні скрипти, виклики API Microsoft Graph та деякі налаштування. Це динамічна сфера, і якщо потрібне стабільне та підтримуване рішення, ця логіка часто делегується комерційному NAC або іншому проміжному компоненту.

Завдяки ефективному поєднанню 802.1X, FreeRADIUS та динамічного призначення VLAN можна досягти точної сегментації мережі без необхідності використання громіздких рішень NAC. Це ідеально узгоджується з надійною стратегією безпеки корпоративних технологій : від контролерів, таких як Omada або ExtremeCloud IQ, до комутаторів середнього класу, все може зробити свій внесок, якщо дотримуються атрибутів тунелю, запити LDAP/AD ретельно керуються, а також чітко визначено, коли динамічно переміщувати користувачів з однієї VLAN до іншої на основі їхньої ідентичності, ролі або типу пристрою, до якого вони підключаються.