802.1X, FreeRADIUS i dynamiczne sieci VLAN: kompletny przewodnik

Informatec Digital » Zasoby » 802.1X, FreeRADIUS i dynamiczne sieci VLAN: kompletny przewodnik

Jeśli zarządzasz sieciami przewodowymi lub Wi-Fi i chcesz rozdzielić ruch według typu użytkownika bez uciekania się do drogiego rozwiązania NAC, efektywne wykorzystanie 802.1X, FreeRADIUS i dynamicznego przydzielania VLAN to jedno z najskuteczniejszych rozwiązań, jakie możesz wdrożyć. Warto zrozumieć, jak wpisuje się to w architekturę Zero Trust . Prawidłowo wdrożone rozwiązanie pozwala decydować, z którą siecią łączy się każde urządzenie, na podstawie jego tożsamości, pochodzenia lub przynależności do grupy katalogowej, bez konieczności tworzenia identyfikatorów SSID wszędzie i przywiązywania się do jednego dostawcy.

W tym artykule szczegółowo omówimy, jak cała ta układanka się ze sobą łączy: rolę 802.1X, typową konfigurację FreeRADIUS, atrybuty RADIUS dla sieci VLAN, integrację z kontrolerami i przełącznikami Wi-Fi , przykłady z życia wzięte (Omada, ExtremeCloud IQ, klasyczne przełączniki), typowe problemy, a nawet zaawansowane zagadnienia, takie jak Azure AD i nieprawidłowe atrybuty w LDAP. Celem jest, abyś do końca kursu miał jasne i praktyczne zrozumienie oraz potrafił dostosować zdobytą tutaj wiedzę do własnej infrastruktury, niezależnie od jej wielkości.

802.1X i dynamiczne sieci VLAN: podstawowe koncepcje i komponenty

Standard 802.1X to, mówiąc wprost, strażnik sieci: dopóki urządzenie nie zostanie uwierzytelnione, port lub sieć Wi-Fi nie przyzna mu dostępu do legalnej sieci. Aby zapewnić prawdziwą segmentację, łączy się go z dynamicznym przydzielaniem sieci VLAN za pomocą atrybutów RADIUS , dzięki czemu serwer decyduje, do której sieci VLAN zostanie przypisany każdy klient po uwierzytelnieniu.

W przypadku każdego wdrożenia 802.1X występują trzy kluczowe komponenty, które zawsze są obecne, niezależnie od tego, czy używasz Omada, ExtremeCloud IQ czy przełączników ogólnych:

• Błagający: klient, który chce się połączyć (laptop, telefon komórkowy, „gotowa” drukarka itp.).
• Authenticator:sprzęt sieciowy kontrolujący dostęp (przełącznik, punkt dostępowy lub kontroler Wi-Fi) i komunikujący się z serwerem RADIUS.
• serwer uwierzytelniający:zwykle a PROMIEŃ, często FreeRADIUS, który weryfikuje dane uwierzytelniające i decyduje o zasadach (zezwalaj, odmawiaj, umieszczaj w jednej lub drugiej sieci VLAN).

Magia dynamicznych sieci VLAN przejawia się w postaci atrybutów RADIUS w ramach protokołu Access-Accept . W przypadku sieci VLAN niemal wszyscy producenci rozumieją kombinację atrybutów przypominających tunelowanie:

• Typ tunelu = VLAN
• Typ tunelu-średniego = IEEE-802
• Tunel-Prywatny-Identyfikator-Grupy = "Identyfikator VLAN" (zwykle liczba od 1 do 4095, choć jest wysyłana jako tekst)

Gdy przełącznik lub punkt dostępowy otrzyma sygnał Access-Accept z tymi atrybutami, a obsługuje standard 802.1X i dynamiczną sieć VLAN, przypisuje port lub sesję Wi-Fi do sieci VLAN wskazanej przez serwer RADIUS, ignorując domyślną sieć VLAN lub identyfikator SSID portu (chyba że serwer RADIUS nic nie wysyła, w takim przypadku stosuje lokalną konfigurację).

Konfiguracja FreeRADIUS dla dynamicznych sieci VLAN

FreeRADIUS to kwintesencja serwera RADIUS o otwartym kodzie źródłowym. Można go zainstalować na dowolnym , nawet bardzo małym sprzęcie, takim jak NanoPi NEO czy Raspberry Pi, a przy odpowiedniej konfiguracji radzi sobie z bardzo wymagającymi środowiskami. W przypadku dynamicznych sieci VLAN kluczowe są dwa obszary: definiowanie użytkowników/grup oraz prawidłowe rozmieszczenie modułów w łańcuchu przetwarzania.

W prostych wdrożeniach użytkowników testowych można zdefiniować bezpośrednio w pliku użytkowników FreeRADIUS , przypisując im sieć VLAN, którą powinni otrzymać. Typowy plik w systemach Debian/Ubuntu znajduje się w katalogu /etc/freeradius/3.0/users , a wpisy dotyczące sieci VLAN wyglądają następująco (uproszczone i przepisane):

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"

Dzięki tej strukturze FreeRADIUS zwróci, po potwierdzeniu dostępu (Access-Accept), trzy atrybuty tunelu, dzięki czemu serwer NAS (przełącznik lub punkt dostępowy) może umieścić klienta w sieci VLAN 10 lub 20, w zależności od użytkownika. Kluczem jest to, aby sprzęt sieciowy obsługiwał odpowiedni dokument RFC i respektował te atrybuty przed skonfigurowaniem sieci VLAN dostępu.

W niektórych scenariuszach, takich jak integracja z ExtremeCloud IQ, kluczowe jest, aby atrybuty te były wysyłane precyzyjnie w poleceniu Access-Accept , a nie tylko jako atrybuty „tunelowane” w innych fazach procesu EAP. W domyślnych konfiguracjach FreeRADIUS może najpierw przetwarzać moduł EAP , a następnie moduł plików (który odczytuje plik użytkownika). Powoduje to, że kontroler pomija atrybuty w odpowiednim momencie.

Praktycznym rozwiązaniem, które okazało się skuteczne, jest dostosowanie pliku /etc/freeradius/3.0/sites-enabled/default poprzez przeniesienie modułu plików przed EAP w bloku autoryzacji . W ten sposób FreeRADIUS najpierw ładuje statyczne atrybuty użytkownika (w tym VLAN), a następnie obsługuje EAP, dzięki czemu podczas konstruowania końcowego Access-Accept atrybuty tunelu są uwzględniane tam, gdzie oczekuje ich kontroler.

Inną zalecaną zmianą jest wyłączenie słabych metod EAP, takich jak EAP-MD5 , które nigdy nie były przeznaczone do środowisk produkcyjnych. Edytując plik /etc/freeradius/3.0/mods-enabled/eap i dodając komentarz lub usuwając sekcję MD5, FreeRADIUS przestanie je oferować. Warto skoncentrować konfigurację na solidnych metodach, takich jak EAP-TLS (certyfikaty) lub PEAP z MSCHAPv2.

Przypisanie sieci VLAN z Omadą: wewnętrzny RADIUS i zewnętrzny FreeRADIUS

Ekosystem Omada firmy TP-Link (kontroler + przełączniki + punkt dostępowy) doskonale integruje standard 802.1X z dynamicznymi sieciami VLAN, zarówno korzystając z wewnętrznego RADIUS-a , jak i delegując do zewnętrznego FreeRADIUS-a. To bardzo obrazowy przykład, ponieważ cały proces jest wyraźnie widoczny.

Aby skorzystać z protokołu RADIUS wbudowanego w kontroler Omada, zazwyczaj należy wykonać trzyetapowy proces. Najpierw w menu globalnym kontrolera włącza się zintegrowany protokół RADIUS , określając adres IP (adres samego kontrolera) i aktywując opcję Tunneled Reply , aby poprawnie wysyłał atrybuty tunelu do urządzenia dostępowego.

Następnie, po przejściu do konkretnej lokalizacji, przejdź do Ustawienia > Profil > Profil RADIUS , edytuj profil i utwórz wewnętrznych użytkowników RADIUS. Dla każdego użytkownika Omada pozwala ustawić nazwę, hasło i identyfikator VLAN , dzięki czemu po uwierzytelnieniu użytkownika kontroler zwróci atrybuty VLAN do przełącznika lub punktu dostępowego bez konieczności korzystania z serwera zewnętrznego.

Na koniec, w Ustawieniach > Uwierzytelnianie > 802.1X , włącz 802.1X, wybierz wewnętrzny profil RADIUS i jawnie włącz opcję Przypisanie VLAN . W tej samej sekcji wybierz porty przełącznika, które będą wymagały uwierzytelniania 802.1X. Po zapisaniu, każde urządzenie łączące się z tymi portami będzie musiało się uwierzytelnić, a jeśli konto ma przypisany identyfikator VLAN, zostanie automatycznie umieszczone w tej sieci VLAN.

Jeśli wolimy scentralizować wszystko na zewnętrznym serwerze FreeRADIUS, Omada idealnie to obsługuje. Pierwszym krokiem jest edycja pliku clients.conf na serwerze FreeRADIUS w celu autoryzacji kontrolera (lub zakresu, w którym znajdują się przełączniki/punkty dostępowe) jako klienta RADIUS, określając adres IP lub podsieć oraz współdzielony klucz , który później skonfigurujemy w Omadzie.

Następnie, wróć do Omada i utwórz zewnętrzny profil RADIUS w Ustawieniach > Profile > Profil RADIUS . W tym celu wprowadź adres IP FreeRADIUS, port uwierzytelniania (zwykle 1812) oraz hasło współdzielone. W ustawieniach 802.1X kontrolera wybierz ten zewnętrzny profil i ponownie włącz przypisywanie VLAN , zaznaczając porty lub identyfikatory SSID, które chcesz chronić.

Dalszą weryfikację można przeprowadzić z poziomu samego kontrolera: w menu Narzędzia > Terminal otwórz konsolę przełącznika z włączonym protokołem 802.1X i uruchom polecenie show dot1x auth-state . Jeśli wszystko działa poprawnie, zobaczysz uwierzytelniony port i sieć VLAN przypisaną przez RADIUS (na przykład port 1/0/1 uwierzytelniony i powiązany z siecią VLAN 2).

Dynamiczna sieć VLAN w sieci Wi-Fi z FreeRADIUS i ExtremeCloud IQ

Innym bardzo obszernym przykładem są sieci Wi-Fi zarządzane przez ExtremeCloud IQ (XIQ) z wykorzystaniem FreeRADIUS jako serwera uwierzytelniającego. W tym przypadku dynamiczna sieć VLAN jest przypisywana klientom Wi-Fi przede wszystkim na podstawie atrybutów tunelu zwróconych przez FreeRADIUS.

Najpierw FreeRADIUS przygotowuje się do wysłania tych trzech atrybutów w Access-Accept, tak jak poprzednio: wpisy w /etc/freeradius/3.0/users z użytkownikami i ich sieciami VLAN oraz ustawienie w sites-enabled/default , dzięki czemu moduł plików zostanie przetworzony przed eap , ponieważ XIQ oczekuje atrybutów dokładnie w Accept.

Zdecydowanie zaleca się wyłączenie protokołu EAP-MD5 i użycie metod takich jak PEAP/EAP-TLS . Po zmodyfikowaniu pliku konfiguracyjnego EAP należy ponownie uruchomić usługę poleceniem ` systemctl restart freeradius`, aby zastosować zmiany. Od tego momentu serwer będzie gotowy do odpowiadania na żądania wysyłane przez punkty dostępowe zarządzane przez XIQ.

W przypadku chmury Extreme dostępne są dwa istotne typy kont: bezpłatne konto Connect , które umożliwia podstawowe zarządzanie maksymalnie dziesięcioma urządzeniami, ale nie obsługuje zaawansowanych reguł klasyfikacji dla dynamicznych sieci VLAN, oraz wersja Pilot , która oferuje 90-dniowy okres próbny i umożliwia korzystanie ze pełnego zestawu profili i reguł opartych na atrybutach RADIUS.

Korzystając z konta Pilot, utwórz nową politykę sieciową z menu „Konfiguruj > Polityki sieciowe”, nadaj jej nazwę i dla uproszczenia wybierz opcję „Tylko Wi-Fi”. W drugim kroku zdefiniuj identyfikator SSID, zazwyczaj dla sieci korporacyjnej z WPA2 lub WPA3, i skojarz grupę RADIUS . Podczas tworzenia tej grupy dodaj FreeRADIUS jako serwer zewnętrzny, określając jego adres IP, tajny klucz i porty 1812/1813.

Następnie konfigurowane są profile użytkowników , które w praktyce są profilami dostępu powiązanymi z różnymi sieciami VLAN (na przykład VLAN10 i VLAN20). Istnieje profil domyślny, który zostanie przypisany klientom, których RADIUS nie zwraca atrybutów tunelu, ale w przypadku dynamicznych sieci VLAN reguły przypisywania są definiowane na podstawie wartości Tunnel-Private-Group-ID i innych atrybutów RADIUS.

Reguły stanowią po prostu: „jeśli identyfikator grupy prywatnej tunelu pochodzący z Accept wynosi 10, przypisz profilowi ​​użytkownika VLAN 10”; jeśli wynosi 20, przypisz profilowi ​​użytkownika VLAN 20 itd. ExtremeCloud IQ w praktyce przekłada te reguły na umieszczenie klienta w sieci VLAN, która odpowiada atrybutowi przesłanemu z FreeRADIUS.

Na koniec należy przyznać dostęp do tych sieci VLAN po przewodowej stronie punktu dostępowego, dostosowując profil punktu dostępowego w XIQ tak, aby port uplinku zezwalał na wszystkie skonfigurowane sieci VLAN i utrzymywał natywną sieć VLAN (zwykle VLAN 1). Po zapisaniu wszystkich danych i zastosowaniu zasad sieciowych do punktów dostępowych, można użyć narzędzia testowego RADIUS zintegrowanego z XIQ, aby sprawdzić, czy FreeRADIUS jest dostępny i czy serwer zwraca oczekiwany atrybut VLAN dla każdego użytkownika.

Omada SDN z FreeRADIUS: sieci VLAN dla sieci przewodowych i bezprzewodowych

Rozwiązanie SDN firmy Omada umożliwia również jednoczesne przypisywanie dynamicznych sieci VLAN w sieciach przewodowych i bezprzewodowych za pomocą zewnętrznego serwera RADIUS, takiego jak FreeRADIUS. Eliminuje to konieczność tworzenia wielu różnych identyfikatorów SSID lub używania statycznych identyfikatorów PVID na portach przełącznika.

Typowa topologia obejmuje kontroler Omada, punkty dostępowe EAP, przełączniki JetStream oraz serwer FreeRADIUS działający w systemie Linux. Aby umożliwić urządzeniom sieciowym wysyłanie żądań uwierzytelnienia do serwera, należy edytować plik clients.conf , ustawiając klienta na zakres sieci Omada (na przykład 192.168.0.0/24) i współdzielone hasło.

Następnie konfiguruje się konta w pliku użytkowników , definiując na przykład dwóch użytkowników: jednego dla VLAN10 i drugiego dla VLAN20, z odpowiednimi atrybutami Tunnel-Type, Tunnel-Medium-Type i Tunnel-Private-Group-Id. W przypadku protokołu WPA-Enterprise często modyfikuje się również plik konfiguracyjny protokołu EAP , aby dostosować metodę do typu klientów (na przykład EAP-PEAP dla laptopów z systemem Windows).

W kontrolerze Omada, w sekcji uwierzytelniania, utwórz profil RADIUS wskazujący na FreeRADIUS i wybierz opcję „Włącz przypisywanie VLAN dla sieci bezprzewodowej” . Dzięki temu, gdy klient uwierzytelnia się przez WPA-Enterprise, Omada wyśle ​​zapytanie do serwera RADIUS i umieści urządzenie w sieci VLAN zwróconej przez serwer, a nie w statycznej sieci VLAN o identyfikatorze SSID.

Konieczne jest również zdefiniowanie interfejsów VLAN sieci w Ustawieniach > Sieci przewodowe > Sieć lokalna (LAN) , tworząc na przykład dwa logiczne interfejsy dla VLAN10 i VLAN20 z odpowiednimi bramami IP. W ten sposób, gdy klient znajduje się w VLAN10, otrzyma adres IP z zakresu tej sieci VLAN , podobnie jak w przypadku VLAN20.

Po stronie sieci bezprzewodowej, identyfikator SSID jest tworzony za pomocą protokołu WPA-Enterprise, wskazując na profil RADIUS. Gdy klient łączy się i uwierzytelnia, na przykład jako test10, użytkownik otrzymuje adres IP z sieci VLAN10; jeśli używa test20, zostanie przypisany do sieci VLAN20, bez konieczności tworzenia osobnego identyfikatora SSID dla każdego przypadku.

Po stronie przewodowej logika jest podobna, ale wykorzystuje protokół 802.1X oparty na portach . Protokół 802.1X jest włączany w odpowiedniej sekcji kontrolera, wybierany jest typ „Port Based”, aktywowana jest funkcja „VLAN Assignment” (Przypisanie VLAN), a porty wymagające uwierzytelnienia są oznaczane. Następnie do tych samych portów jest stosowany profil portu , dodając sieci VLAN10 i VLAN20 jako sieci nieoznaczone, co zapewnia ustawienie trybu sterowania 802.1X na „Auto”, dzięki czemu przełącznik inicjuje negocjacje po wykryciu klienta.

Dzięki pojedynczej konfiguracji RADIUS i kilku profilom Omada SDN gwarantuje, że zarówno użytkownicy sieci przewodowej, jak i Wi-Fi znajdą się w odpowiedniej sieci VLAN zgodnie ze swoimi danymi uwierzytelniającymi , bez konieczności mnożenia sieci lub ręcznego dostosowywania konfiguracji każdego portu.

Praktyczne przykłady, typowe błędy i wskazówki dotyczące konfiguracji

Praca z FreeRADIUS i dynamicznymi sieciami VLAN nie zawsze jest usłana różami: podczas przechodzenia z testów laboratoryjnych do środowisk rzeczywistych pojawia się kilka powtarzających się problemów, zwłaszcza w przypadku katalogów LDAP/AD, formatów nazw użytkowników i złożonych zasad . Dlatego dobre zarządzanie ryzykiem cyberbezpieczeństwa pomaga ograniczyć liczbę incydentów.

Bardzo typowy błąd występuje, gdy serwer tworzy zapytanie LDAP przy użyciu atrybutu %{Nazwa użytkownika} w momencie dotarcia do RADIUS. W wielu scenariuszach Windows format dociera jako DOMENA\użytkownik, z ukośnikiem odwrotnym zakodowanym jako \5cJeśli szablon LDAP jest zbudowany z uid=%{User-Name}Wynikowe zapytanie będzie wyglądać mniej więcej tak: uid=DOMINIO\5cusuarioktóry rzadko odpowiada faktycznemu identyfikatorowi użytkownika w drzewie LDAP i nie zwraca żadnych wyników.

Oznacza to, że atrybuty użytkownika, w tym wartość VLAN lub grupy do zmapowania, nie znajdują się w katalogu. W związku z tym serwer nie dodaje identyfikatora Tunnel-Private-Group-Id, a klient pozostaje na przełączniku lub domyślnej sieci VLAN punktu dostępowego. Ten wzorzec jest wyraźnie widoczny w logach FreeRADIUS: zapytanie LDAP z identyfikatorem użytkownika „domena\użytkownik” i pustym wynikiem wyszukiwania.

Praktycznym rozwiązaniem, które sprawdziło się w praktyce, jest zmiana sposobu użycia %{User-Name} na %{Stripped-User-Name} w szablonie zapytania LDAP w konfiguracji FreeRADIUS, np.:

jeśli ("%{ldap:ldap:///dc=example,dc=com?uid?sub?(|(uid=%{Stripped-User-Name})(macAddress=%{Calling-Station-Id}))}") { ... }

W ten sposób FreeRADIUS używa „czystej” nazwy użytkownika, bez domeny ani ukośnika, a wyszukiwanie ponownie kończy się sukcesem. Gdy tylko LDAP zwróci poprawny wpis, serwer może zastosować logikę przypisywania sieci VLAN na podstawie grup, jednostek organizacyjnych (OU) lub określonych atrybutów, generując ponownie wartości Tunnel-Type, Tunnel-Medium-Type i Tunnel-Private-Group-Id w polu Access-Accept.

Inny ciekawy przypadek występuje w przypadku niektórych przełączników, gdy statyczne konfiguracje VLAN na porcie mieszają się z dynamicznymi konfiguracjami 802.1X. Na przykład, gdy port 17 jest w statycznej sieci VLAN 4, a jednocześnie użytkownik próbuje zmusić się do korzystania z sieci VLAN 2 za pomocą protokołu RADIUS. Jeśli urządzenie nie respektuje atrybutów tunelu lub funkcja dynamicznej sieci VLAN jest wyłączona, niezależnie od tego, co się dzieje w protokole RADIUS, port nadal będzie widział ruch jako sieć VLAN 4.

W takich sytuacjach kluczowe jest zapoznanie się z dokumentacją przełącznika, aby jawnie włączyć obsługę przypisywania sieci VLAN za pośrednictwem protokołu RADIUS , a także debugowanie za pomocą poleceń takich jak ` show dot1x` lub podobnych, sprawdzając, czy urządzenie zgłasza komunikaty takie jak „ignorowanie atrybutów tunelu” lub „wyłączone dynamiczne przypisywanie sieci VLAN”. Użytkownik podłączony domyślnie do portu fizycznego w sieci VLAN 4 zostanie faktycznie przeniesiony do sieci VLAN 2 po uwierzytelnieniu się jako „carlos” lub inna osoba tylko wtedy, gdy producent obsługuje tę funkcję i jest ona włączona.

Istnieją również klasyczne debaty na temat zasadności korzystania z dynamicznych sieci VLAN w scenariuszach pulpitu zdalnego (RDP) . Gdy uwierzytelnianie komputera następuje podczas uruchamiania systemu Windows, a następnie uwierzytelnianie użytkownika podczas logowania, zmiana sieci VLAN wywołana logowaniem użytkownika może przerwać trwające sesje RDP lub spowodować problemy z DNS, gdy port przełącza się z sieci VLAN „maszyny” na sieć VLAN „użytkownika”. Wielu administratorów zdecydowało się na utrzymanie jednej sieci VLAN dla wszystkich stanów w takich przypadkach lub na przypisanie tej samej sieci VLAN zarówno na poziomie komputera, jak i użytkownika, minimalizując zmiany segmentów.

Wreszcie, na poziomie zaawansowanej integracji, rośnie zainteresowanie połączeniem FreeRADIUS z Azure AD w celu określenia sieci VLAN na podstawie przynależności do grup w chmurze. Obecnie nie ma oficjalnego, natywnego modułu, który wykonywałby bezpośrednie wyszukiwanie grup dla sieci VLAN w Azure AD, a obejścia tego problemu wymagają zewnętrznych skryptów, wywołań interfejsu API Microsoft Graph i pewnych modyfikacji. To dynamiczne środowisko i jeśli potrzebne jest stabilne i obsługiwane rozwiązanie, logika ta jest często delegowana do komercyjnego NAC lub innego komponentu pośredniczącego.

Efektywne połączenie 802.1X, FreeRADIUS i dynamicznego przydzielania sieci VLAN pozwala na precyzyjną segmentację sieci bez konieczności stosowania uciążliwych rozwiązań NAC. Idealnie wpisuje się to w solidną strategię bezpieczeństwa technologii korporacyjnych : od kontrolerów takich jak Omada czy ExtremeCloud IQ po przełączniki średniej klasy – wszystko może się przydać, jeśli atrybuty tunelu są przestrzegane, zapytania LDAP/AD są starannie zarządzane i wiadomo, kiedy dynamicznie przenosić użytkowników z jednej sieci VLAN do drugiej, w zależności od ich tożsamości, roli lub typu podłączonego urządzenia.