1X w praktyce: uwierzytelnianie urządzeń w LAN i WiFi krok po kroku

Po co 802.1X w sieci lokalnej: motywacja i scenariusze użycia

Problem „każdy, kto się wpiął, ma dostęp”

Klasyczna sieć LAN bez 802.1X działa według prostego schematu: jeśli ktoś fizycznie się wpiął do gniazdka lub zalogował do WiFi z hasłem znanym wszystkim, od razu ląduje w tej samej sieci co serwery, drukarki i stacje robocze. To wygodne, ale z perspektywy bezpieczeństwa kompletnie archaiczne. Wystarczy, że ktoś przyniesie laptopa z domu, podepnie się do wolnego portu w sali konferencyjnej i automatycznie staje się „wewnętrznym” użytkownikiem.

Ten model nie rozróżnia, kto lub co jest podłączone. Port jest ślepy na to, czy stoi za nim firmowa, zarządzana stacja robocza, prywatny telefon, czy może Raspberry Pi pozostawione przez wykonawcę. To samo dotyczy prostego WiFi z hasłem WPA2-PSK – jeśli hasło wycieknie, tracisz kontrolę nad dostępem.

802.1X rozwiązuje dokładnie ten problem. Zamiast „podłączony = zaufany” wprowadza zasadę „podłączony = spróbuj się uwierzytelnić, inaczej dostaniesz minimum lub nic”. Port przełącznika lub SSID w WiFi przestaje być biernym medium, a staje się punktem kontrolnym.

802.1X jako kontrola dostępu na porcie

802.1X to standard port-based network access control. Oznacza to, że decyzja o tym, czy ruch z danego urządzenia ma zostać przepuszczony, zapada bezpośrednio na porcie przełącznika (w LAN) lub na punkcie dostępowym (w WiFi). Zanim port stanie się w pełni aktywny, następuje procedura uwierzytelnienia za pomocą protokołu EAP (Extensible Authentication Protocol).

Istotny szczegół: 802.1X nie szyfruje ruchu w warstwie 2 – jest mechanizmem kontroli dostępu, a nie szyfrowania. W WiFi szyfrowanie zapewnia WPA2/WPA3 (klucze per sesja), w LAN zaś 802.1X decyduje tylko o tym, czy port ma się „otworzyć” i do jakiej sieci logicznej (VLAN) przypiąć danego klienta.

Port w stanie nieautoryzowanym przepuszcza jedynie określone typy ramek, głównie EAPOL (EAP over LAN), które służą do negocjacji uwierzytelnienia. Dopiero po pozytywnym wyniku autoryzacji port przechodzi w stan autoryzowany i ruch IP zostaje dopuszczony zgodnie z polityką (przypisanie VLAN, ACL, QoS itd.).

Scenariusze użycia: biuro, goście, produkcja, IoT

W małym biurze 802.1X pozwala oddzielić firmowe stacje robocze od gości, nawet jeśli korzystają z tych samych fizycznych gniazd. Pracownik z domenowym laptopem trafia do VLAN pracowniczego, gość bez certyfikatu lub bez konta – do VLAN gościnnego z dostępem wyłącznie do internetu.

W magazynie lub na hali produkcyjnej 802.1X przydaje się do izolacji urządzeń produkcyjnych (skanery, wagi, terminale) od zwykłych komputerów. Urządzenia, które nie obsługują 802.1X, można wpuszczać warunkowo przez MAB (MAC Authentication Bypass) i przypisywać do dedykowanego VLAN o bardzo ograniczonych uprawnieniach.

W sieciach WiFi 802.1X (w trybie WPA2/WPA3-Enterprise) to standard w firmach, które chcą uniknąć jednego wspólnego hasła do WiFi. Każdy użytkownik lub urządzenie ma własny sposób uwierzytelniania (login/hasło, certyfikat), a hasło do sieci jako takiej nie istnieje – jest tylko nazwa SSID, a resztę załatwia 802.1X i RADIUS.

Uwierzytelnianie użytkownika vs urządzenia

W 802.1X można uwierzytelniać zarówno użytkowników, jak i urządzenia – to dwie różne koncepcje, które często się miesza.

• Uwierzytelnianie użytkownika – najczęściej PEAP/MSCHAPv2 lub EAP-TLS z certyfikatem użytkownika; decyzja o dostępie zależy od tego, kto się loguje (konto w AD, grupa, rola).
• Uwierzytelnianie urządzenia – np. EAP-TLS z certyfikatem komputera (konto w AD typu „Computer”), MAB na podstawie adresu MAC lub specjalne profile dla IoT; decyzja nie zależy od zalogowanego usera, ale od tożsamości sprzętu.

W praktyce często stosuje się hybrydę: komputer musi być „firmowy” (certyfikat urządzenia, członkostwo w określonej OU/ grupie), a użytkownik musi mieć odpowiednie uprawnienia. Takie podejście dobrze działa w środowiskach domenowych Windows, gdzie GPO może wymuszać zasady 802.1X dla maszyn i użytkowników.

Gdzie 802.1X ma sens, a gdzie wystarczy coś prostszego

Nie każde środowisko wymaga pełnego 802.1X od dnia zero. Są miejsca, gdzie prosty model typu „WPA2-PSK + izolacja klientów” spełni oczekiwania. Przykłady:

• Mały punkt usługowy z kilkoma komputerami i jednym AP – kluczowe jest oddzielenie WiFi gościnnego; tu wystarczy osobny SSID z samym hasłem i izolacją klient-klient.
• Sieć dla urządzeń tymczasowych lub testowych – czasem prościej wydzielić je do osobnego VLAN z PSK i mocno ograniczonymi regułami firewall.

802.1X zaczyna naprawdę „zarabiać” tam, gdzie:

• masz większą liczbę urządzeń i użytkowników,
• wymagana jest zgodność z regulacjami (np. audyty bezpieczeństwa),
• chcesz automatyzować przypisywanie VLAN i polityk bezpieczeństwa,
• musisz kontrolować BYOD i urządzenia IoT.

Dobrą praktyką jest rozpoczęcie od sieci WiFi (WPA2/WPA3-Enterprise), a dopiero potem dołożenie 802.1X na portach przewodowych, gdzie liczba wyjątków (drukarki, kamery, sterowniki PLC) bywa większa.

Architektura 802.1X: trzy role i podstawowe pojęcia

Supplicant, Authenticator, Authentication Server

802.1X opiera się na trzech rolach, które trzeba dobrze rozumieć, żeby sensownie diagnozować problemy:

• Supplicant – klient 802.1X, czyli system operacyjny/oprogramowanie na urządzeniu końcowym (Windows, macOS, Linux, Android, iOS) odpowiedzialne za prowadzenie dialogu EAP z siecią.
• Authenticator – urządzenie sieciowe „na brzegu”: przełącznik dostępowy (LAN) albo punkt dostępowy / kontroler WiFi (WLAN). To on pilnuje stanu portu i przekazuje komunikaty EAP dalej.
• Authentication Server – najczęściej serwer RADIUS, który podejmuje decyzję „allow/deny” na podstawie przedstawionych poświadczeń (login/hasło, certyfikat) i polityki.

Supplicant rozmawia z Authenticator za pomocą EAPOL, a Authenticator z serwerem RADIUS – za pomocą RADIUS/EAP. Authenticator jest więc swego rodzaju „tłumaczem” między światem ramek warstwy 2 a pakietami IP.

Przepływ ruchu: od EAPOL do RADIUS

Cały proces 802.1X można rozłożyć na prostą sekwencję:

1. Urządzenie podłącza się do portu lub łączy z SSID, port przełącznika jest w stanie nieautoryzowanym.
2. Authenticator wysyła EAPOL-Request/Identity: „Kim jesteś?”.
3. Supplicant odpowiada EAPOL-Response/Identity (np. nazwa użytkownika lub identyfikator urządzenia).
4. Authenticator pakuje to w RADIUS Access-Request i wysyła do serwera RADIUS.
5. Serwer RADIUS odpowiada serią Access-Challenge / Access-Reject / Access-Accept, w ramach których transportowana jest dana metoda EAP (np. PEAP, EAP-TLS).
6. Jeśli efekt końcowy to Access-Accept, Authenticator otwiera port i ewentualnie stosuje dodatkowe parametry (VLAN, ACL) z atrybutów RADIUS.

Ten przepływ jest kluczowy przy diagnose – trzeba wiedzieć, na którym etapie coś się psuje: supplicant nie startuje EAP, przełącznik nie wysyła zapytań do RADIUS, czy może RADIUS odrzuca z powodu złego hasła albo braku certyfikatu.

Relacja 802.1X, RADIUS i katalogu (AD/LDAP)

Sam serwer RADIUS rzadko przechowuje konta użytkowników; pełni raczej rolę pośrednika. Typowy układ:

• 802.1X na brzegu (przełącznik/AP) mówi z RADIUS (Authentication Server).
• RADIUS integruje się z Active Directory lub innym katalogiem LDAP, żeby sprawdzić dane logowania, członkostwo w grupach, atrybuty konta.
• Czasem RADIUS wykorzystuje też lokalną bazę (np. konta gościnne) równolegle do AD.

802.1X jest więc tylko mechanizmem przenoszenia procesu uwierzytelnienia z brzegu sieci do centralnego serwera RADIUS, który z kolei sięga do katalogu (AD/LDAP), certyfikatów (PKI) i polityk. Ten rozdział ról pozwala spiąć kontrolę dostępu do sieci z istniejącą infrastrukturą tożsamości.

Co jest „na brzegu”, a co „w serwerowni”

Projektując 802.1X warto jasno rozrysować podział:

• Na brzegu – przełączniki dostępowe, AP, kontrolery WLAN; konfigurujesz tam profile 802.1X, adresy serwerów RADIUS, tryby fallback (MAB, guest VLAN).
• W serwerowni – serwery RADIUS (np. NPS, FreeRADIUS, ISE, ClearPass), kontrolery domeny/serwery LDAP, serwery CA (PKI) oraz systemy NAC, które nakładają dodatkowe polityki.

Taki podział pomaga przy skalowaniu. Dodanie nowego budynku wymaga głównie konfiguracji przełączników i AP – logika uwierzytelniania i polityk pozostaje w centralnym RADIUS.

802.1X to nie szyfrowanie

Częsty mit: „włączymy 802.1X, to cała sieć będzie szyfrowana”. Nie – 802.1X kontroluje, kto ma prawo się wpiąć i jaką politykę dostępu otrzyma, ale nie szyfruje ruchu samego w sobie w sieciach przewodowych. Można oczywiście połączyć go z innymi mechanizmami, np.:

• IPsec między hostami lub host–serwer,
• MACsec (802.1AE) na łączach switch–switch lub switch–host,
• WPA2/WPA3 w WiFi, gdzie 802.1X jest częścią mechanizmu generowania kluczy sesji.

Świadomość tej różnicy jest ważna przy rozmowach z działem bezpieczeństwa i biznesem, żeby jasno określić, co 802.1X faktycznie daje, a czego nie rozwiązuje.

Przegląd metod EAP: wybór mechanizmu pod realne potrzeby

EAP jako „ramka” na różne metody

EAP (Extensible Authentication Protocol) to ramka, w którą można wpiąć różne metody uwierzytelnienia. Sam EAP nie narzuca, czy użyją się haseł, certyfikatów czy tokenów; jest tylko kontenerem. W praktyce najczęściej spotykane są:

• EAP-TLS – dwustronne uwierzytelnianie na certyfikatach (klient + serwer).
• PEAP z MSCHAPv2 – tunel TLS z loginem/hasłem wewnątrz (najczęściej z AD).
• EAP-TTLS – podobny do PEAP, ale bardziej elastyczny w metodach wewnętrznych.
• EAP-FAST – często spotykany w środowiskach Cisco, bazuje na tzw. PAC.

Wybór metody EAP to decyzja strategiczna – determinuje, jak będzie wyglądać dystrybucja certyfikatów, zarządzanie hasłami i integracja z AD. Trzeba ją podjąć przed produkcyjnym wdrożeniem, bo późniejsza zmiana bywa bolesna.

EAP-TLS: certyfikaty klienta – najwyższy poziom zaufania

EAP-TLS uchodzi obecnie za złoty standard, szczególnie w środowiskach korporacyjnych. Uwierzytelnianie opiera się na certyfikatach X.509 po stronie klienta i serwera. Kluczowe cechy:

• Brak haseł użytkownika w samym procesie EAP (można je łączyć z logowaniem do domeny, ale nie muszą być przesyłane przez 802.1X).
• Silne uwierzytelnianie dwustronne: klient weryfikuje, że mówi z prawidłowym serwerem (uniknięcie rogue AP/RADIUS), a serwer weryfikuje klienta.
• Możliwość rozróżniania urządzeń na podstawie atrybutów certyfikatu (CN, SAN, OID, szablon certyfikatu).

Wadą EAP-TLS jest złożoność wdrożenia PKI (Public Key Infrastructure): trzeba mieć serwer(y) CA, szablony certyfikatów, mechanizmy automatycznego wystawiania i odnawiania certyfikatów (np. GPO dla stacji domenowych, MDM dla urządzeń mobilnych, SCEP/EST dla innych). Bez tego administracja ręczna szybko zamienia się w chaos.

EAP-TLS świetnie sprawdza się dla firmowych stacji roboczych i urządzeń zarządzanych, gdzie można wymusić instalację certyfikatów centralnie oraz dla IoT, jeśli producent wspiera klienta 802.1X z certyfikatami.

PEAP/MSCHAPv2: login i hasło w tunelu TLS

PEAP z MSCHAPv2: kompromis między wygodą a bezpieczeństwem

PEAP (Protected EAP) z wewnętrzną metodą MSCHAPv2 to dziś nadal najbardziej rozpowszechniony mechanizm w sieciach firmowych, szczególnie tam, gdzie dominują stacje Windows i integracja z Active Directory.

Schemat działania jest prosty:

• Najpierw zestawiany jest tunel TLS między supplicantem a serwerem RADIUS (klient weryfikuje certyfikat serwera).
• Wewnątrz tego tunelu wykonywane jest uwierzytelnienie hasłem (MSCHAPv2), zwykle loginem domenowym użytkownika.

Zalety:

• Brak konieczności wdrażania certyfikatów po stronie klientów (wystarczy certyfikat serwera RADIUS).
• Naturalna integracja z AD – użytkownik podaje te same dane, których używa do logowania do systemu.
• Szerokie wsparcie w systemach operacyjnych, bez dodatkowego oprogramowania.

Słabością jest oparcie o hasła oraz sam MSCHAPv2, który z perspektywy kryptografii ma już „swoje lata”. W praktyce problemem są zwłaszcza:

• słabe hasła użytkowników (łatwe do odgadnięcia/bruteforce),
• błędy w konfiguracji supplicanta – brak weryfikacji certyfikatu serwera lub akceptowanie dowolnego CA.

PEAP/MSCHAPv2 jest nadal sensowną opcją przejściową lub w środowiskach, gdzie nie ma możliwości wdrożenia PKI dla wszystkich klientów. Można go stosować np. dla użytkowników zewnętrznych lub BYOD, przy jednoczesnym użyciu EAP-TLS dla urządzeń firmowych.

Inne metody EAP w praktyce: TTLS, FAST, PWD

Oprócz EAP-TLS i PEAP/MSCHAPv2 istnieje kilka metod, które sporadycznie pojawiają się w specyficznych środowiskach:

• EAP-TTLS – podobny do PEAP, ale w tunelu TLS można używać różnych metod wewnętrznych (PAP, CHAP, MSCHAP, MSCHAPv2). Popularny w połączeniu z serwerami FreeRADIUS i katalogiem LDAP, gdy dane logowania nie są w AD.
• EAP-FAST (Cisco) – opiera się na PAC (Protected Access Credential), czyli „bileciku” dystrybuowanym klientom; bywa wykorzystywany tam, gdzie trudno wprowadzić klasyczną PKI, ale wymagana jest silna kontrola.
• EAP-PWD – metoda oparta na hasłach, projektowana jako nowocześniejsza alternatywa dla MSCHAPv2, jednak w mainstreamie spotykana rzadko.

Takie metody mają sens przede wszystkim wtedy, gdy używany system NAC/RADIUS lub konkretna platforma sieciowa ma dla nich dobre wsparcie i gotowe szablony polityk. W przeciwnym razie generują zbędną złożoność.

Jak dobrać metodę EAP do typu urządzeń

Dobrym podejściem jest rozbicie tematu nie „który EAP jest najlepszy ogólnie”, tylko „jaki EAP dla danej klasy urządzeń”. Przykładowy model:

• Stacje robocze domenowe (Windows, macOS) – EAP-TLS z automatyczną dystrybucją certyfikatów (GPO, MDM). Tu 802.1X może być wymuszony i bez możliwości wyłączenia przez użytkownika.
• Urządzenia mobilne (smartfony/tablety pracowników) – EAP-TLS z MDM (firmowe) lub PEAP z osobnym kontem/hasłem (BYOD), ewentualnie osobny SSID z portalem rejestracji.
• Urządzenia IoT / drukarki / kamery – jeśli obsługują EAP-TLS, wykorzystać certyfikaty. Jeśli nie, stosować MAB (MAC Authentication Bypass) i mocno ograniczony VLAN.
• Goście – najczęściej osobna sieć (SSID) bez 802.1X, ale z portalem WWW, albo osobny backend RADIUS z krótkotrwałymi kontami.

Taki podział pomaga uniknąć prób „wciśnięcia” jednej metody na siłę wszędzie, co kończy się dziesiątkami wyjątków konfiguracyjnych na przełącznikach i AP.

Niezbędne komponenty w infrastrukturze: RADIUS, PKI, katalog, sprzęt

RADIUS jako silnik decyzyjny

Serwer RADIUS jest centralnym elementem całego rozwiązania. To on:

• przyjmuje zapytania Access-Request z urządzeń sieciowych,
• prowadzi dialog EAP z klientem (poprzez Authenticator),
• odpyta katalog (AD/LDAP) albo lokalną bazę użytkowników,
• podejmuje decyzję Access-Accept / Access-Reject,
• zwraca atrybuty (VLAN, prawa, tagi) do zastosowania na brzegu.

W praktyce najczęściej spotyka się:

• Microsoft NPS – prosty, zintegrowany z AD, wystarczający dla mniejszych wdrożeń.
• FreeRADIUS – bardzo elastyczny i wydajny, wymaga jednak znajomości jego plików konfiguracyjnych i modułów.
• Cisco ISE, Aruba ClearPass – rozbudowane platformy NAC z GUI, politykami, integracją z MDM, skanerami podatności itd.

Wybierając RADIUS, trzeba zwrócić uwagę na:

• łatwość integracji z istniejącym AD/LDAP,
• obsługę planowanych metod EAP (EAP-TLS, PEAP itd.),
• wsparcie dla przypisywania VLAN i ACL (atrybuty standardowe i vendor-specific),
• model HA (klastry, redundancja, replikacja konfiguracji).

PKI: fundament dla EAP-TLS

Jeżeli w grę wchodzi EAP-TLS, bez sensownej PKI (Public Key Infrastructure) nie da się zrobić stabilnego wdrożenia. Podstawowe elementy:

• CA Root i Sub-CA – główne centrum certyfikacji (root) oraz ewentualne podległe (subordinate CA), których certyfikaty wystawiają konkretne szablony (np. „Computer Authentication”, „User Authentication”).
• Szablony certyfikatów – określają parametry certyfikatów klientów/serwerów (EKU, długość klucza, okres ważności, nazewnictwo).
• Mechanizmy enrolmentu – GPO/Autoenrollment dla domeny Windows, SCEP/EST dla urządzeń spoza domeny, integracja z MDM dla mobilnych.
• Listy CRL/OCSP – mechanizmy odwoływania certyfikatów (np. przy zgubieniu laptopa).

Przy planowaniu PKI pod 802.1X warto ustalić:

• czy stosujemy osobne CA do uwierzytelniania sieciowego, czy używamy istniejącej firmowej PKI,
• jak identyfikujemy urządzenia w certyfikacie (CN, SAN:DNS, SAN:UPN, OID szablonu),
• jak będzie wyglądał proces wygasania i odnawiania certyfikatów (np. 1–2 lata ważności, automatyczne odnowienie na 30 dni przed).

Katalog tożsamości: AD/LDAP i integracje

Active Directory albo inny katalog LDAP jest źródłem prawdy o użytkownikach i często o urządzeniach. RADIUS wykorzystuje:

• login i hasło (metody oparte na hasłach),
• UPN/PN (User Principal Name) lub CN do mapowania certyfikatu na konto,
• członkostwo w grupach (np. „WiFi-Firma”, „WiFi-Gość”),
• atrybuty niestandardowe (np. opis działu, lokalizacji).

Na tej bazie budowane są polityki typu:

• „Użytkownicy z grupy <IT> mogą trafić do VLAN z pełnym dostępem”
• „Goście z grupy <Guests> lądują w VLAN z dostępem tylko do internetu”
• „Kontrolery PLC z określonym prefiksem nazwy komputera mają własny segment”

Przed wdrożeniem 802.1X dobrze jest uporządkować strukturę grup, OU i nazewnictwo kont maszynowych – to potem ogromnie ułatwia pisanie reguł w RADIUS.

Sprzęt sieciowy: przełączniki i punkty dostępowe

Nie każdy przełącznik i AP radzi sobie dobrze z 802.1X. Rzeczy do sprawdzenia:

• Wsparcie 802.1X na portach dostępowych (dotyczy switchy) oraz WPA2/WPA3-Enterprise (dotyczy WiFi).
• Obsługa dynamicznego VLAN z RADIUS (atrybuty Tunnel-Private-Group-ID, Tunnel-Type),
• Możliwość zdefiniowania failmode (co się dzieje przy braku odpowiedzi RADIUS: otwieramy port czy blokujemy?),
• Wsparcie dla MAB (MAC Authentication Bypass) i guest/unauthorized VLAN,
• Limity liczby sesji 802.1X na port, limity zapytań RADIUS (ważne przy stackach i dużym zagęszczeniu),
• Jakość logów i debugów (komendy typu debug dot1x, show authentication sessions).

Na starych przełącznikach czasem brakuje kluczowych funkcji (np. brak dynamicznego VLAN albo bardzo uproszczony 802.1X bez trybów multi-auth), co wymusza kompromisy w projekcie segmentacji.

Planowanie wdrożenia 802.1X: model logiczny i segmentacja

Definicja klas urządzeń i polityk dostępu

Na początku trzeba opisać, jakie klasy urządzeń i użytkowników mają istnieć w sieci. Prosty podział:

• stacje robocze pracowników,
• serwery i urządzenia administratorskie,
• goście,
• IoT (drukarki, kamery, czujniki, sterowniki),
• systemy krytyczne (OT, produkcja).

Dla każdej klasy ustala się:

• jaki typ uwierzytelniania (EAP-TLS, PEAP, MAB),
• jaki VLAN lub segment (sieć logiczna),
• jakie reguły firewall/ACL (do czego mają mieć dostęp),
• czy 802.1X jest wymagany, czy dopuszczony jest fallback (MAB, open).

To później przekłada się bezpośrednio na polityki w RADIUS – reguły typu „IF warunek THEN przypisz VLAN X, ACL Y”.

Model VLAN a 802.1X: statyczny vs dynamiczny

802.1X pozwala wyjść poza klasyczny model „VLAN per port”. Pojawiają się dwie główne strategie:

• Statyczny VLAN na porcie – 802.1X tylko umożliwia lub blokuje dostęp do tego, co i tak jest skonfigurowane na porcie. Prostsze, ale mniej elastyczne.
• Dynamiczny VLAN z RADIUS – przełącznik/AP otrzymuje z RADIUS atrybut VLAN i przypisuje użytkownika/urządzenie do odpowiedniego segmentu niezależnie od fizycznego portu czy AP.

Dynamiczny model bywa bardzo wygodny (np. pracownik przenoszący laptop między gniazdami zawsze ląduje w tym samym VLAN), ale wymaga:

• spójnego planu adresacji (VLAN muszą istnieć w całej infrastrukturze dostępowej),
• konsekwentnej konfiguracji trunków i routingów,
• dobrego testu wydajności RADIUS (dużo więcej decyzji per sesja).

W małych i średnich środowiskach kompromisem jest stosowanie dynamicznego VLAN głównie w WiFi i dla części portów przewodowych, a resztę pozostawić na statycznym VLAN z prostym „allow/deny”.

Fallback: MAB, gościnny VLAN, tryb open

W rzeczywistości część urządzeń 802.1X nigdy nie obsłuży. Tu pojawiają się mechanizmy awaryjne:

• MAB (MAC Authentication Bypass) – przełącznik/AP zamiast dialogu EAP wysyła do RADIUS sam adres MAC jako „login”. RADIUS sprawdza, czy MAC jest na liście dozwolonych i przypisuje VLAN/politykę.
• Guest VLAN – jeśli na porcie nie ma odpowiedzi EAP (brak supplicanta), urządzenie trafia do VLAN gościnnego z ograniczonym dostępem.
• Critical VLAN – sieć awaryjna używana, gdy RADIUS jest niedostępny. Typowo minimalny dostęp np. do serwerów zarządzających i monitoringu.

Kluczowe jest, żeby fallback nie zjadał korzyści z 802.1X. Przykład: MAB powinien prowadzić do silnie ograniczonego VLAN (drukarka ma tylko drukować i raportować stan, a nie wychodzić w internet „jak użytkownik”).

Kolejność wdrożenia: test, pilot, pełne uruchomienie

Bezpieczna ścieżka to:

1. Lab – mały przełącznik i AP w wydzielonym segmencie, test RADIUS, EAP-TLS/PEAP, pilotowe polityki VLAN.
2. Tryb monitor/failed-open – 802.1X włączony, ale porty otwierają się nawet przy błędzie; logi RADIUS służą do analizy prób i błędów.
3. Pilot na wybranym piętrze/dziale – 802.1X wymuszony, ale z dobrze przygotowanym supportem IT (helpdesk wie, czego się spodziewać).
4. Stopniowe rozszerzanie – budynek po budynku, SSID po SSID, z korektą polityk na bazie realnych incydentów.

Polityka przejściowa: równoległe SSID i porty mieszane

Rzadko da się „przeklikać przełącznik” i od jutra mieć 802.1X wszędzie. Pomaga model przejściowy, w którym stara i nowa metoda dostępu współistnieją.

Na kablu typowy scenariusz to:

• porty skonfigurowane w trybie multi-auth lub dot1x + MAB,
• stare urządzenia (bez supplicanta) lecą po MAB/guest VLAN,
• nowe stacje robocze – po 802.1X z EAP-TLS.

W WiFi zwykle stosuje się podwójne SSID:

• dotychczasowe SSID z PSK (np. „Firma-PSK”) – utrzymane na czas migracji,
• nowe SSID z WPA2/WPA3-Enterprise (np. „Firma-8021X”) – stopniowo dodawane do konfiguracji urządzeń.

Daje to przestrzeń na spokojne wdrożenie agentów, certyfikatów i polityk, bez natychmiastowego odcinania użytkowników działających jeszcze na starych zasadach.

Konfiguracja 802.1X w LAN: przełączniki krok po kroku

Model ogólny konfiguracji na przełączniku

Niezależnie od producenta, konfiguracja 802.1X składa się zwykle z tych samych elementów:

1. włączenie AAA i zdefiniowanie serwerów RADIUS,
2. zdefiniowanie metody uwierzytelniania (dot1x, MAB, fallback),
3. globalne włączenie 802.1X,
4. konfiguracja portów dostępowych (tryby single/multi-auth, VLAN-y, fallback),
5. ustawienie failmode i VLAN-ów specjalnych (guest, critical),
6. logowanie, monitorowanie i limity.

Różnice między vendorami sprowadzają się do składni i nazw komend, ale logika pozostaje podobna.

Definicja serwerów RADIUS i kluczy

Na początku przełącznik musi wiedzieć, gdzie wysyłać zapytania i jak je zabezpieczyć. Konfiguruje się:

• adres IP/Nazwa serwera RADIUS (często dwa: primary i secondary),
• porty (domyślnie 1812 – auth, 1813 – accounting),
• wspólny sekret (shared secret) – silny, unikalny dla danego klienta,
• czas oczekiwania na odpowiedź, liczba retransmisji.

Tip: nie używać jednego sekretu RADIUS dla całej infrastruktury. Dla każdego przełącznika/stacka osobny, tak jak unikalne hasło do urządzenia.

Włączenie 802.1X globalnie

Drugi krok to aktywacja mechanizmu w systemie operacyjnym przełącznika. Nazwy poleceń bywają różne (dot1x system-auth-control, globalne aaa authentication itp.), ale efekt jest jeden – urządzenie zaczyna rozumieć ramki EAPOL i potrafi rozmawiać z RADIUS.

Często tu też definiuje się domyślny porządek metod (np. „najpierw 802.1X, jeśli brak – MAB, jeśli błąd – guest VLAN”). To jest miejsce, gdzie logiczny model z etapu planowania przekłada się na realny zbiór reguł.

Tryby autoryzacji na porcie: single-host, multi-auth, multi-domain

Port dostępowy nie zawsze obsługuje jedno urządzenie. Mamy kilka podstawowych trybów:

• single-host – tylko jedna sesja 802.1X na port; reszta MAC-ów blokowana. Dobre do biurka z pojedynczym PC.
• multi-auth – wiele niezależnych sesji (np. laptop i telefon na małym switchu biurkowym). Każde urządzenie może być przypisane do innego VLAN.
• multi-domain – osobne uwierzytelnianie dla ruchu data i voice (telefony IP). Telefon trafia do voice VLAN, komputer – do VLAN danych.

W biurach najczęściej spotyka się multi-domain (PC + IP phone) lub multi-auth (małe switche domowe wpinane do gniazd biurowych – „bo zabrakło portów”). Tryb dobiera się do realnego wykorzystania portów, a nie odwrotnie.

Fallback na porcie: 802.1X + MAB + guest VLAN

Na pojedynczym porcie często łączy się kilka metod:

• priorytet ma 802.1X – jeśli supplicant się zgłosi, toczy się pełny dialog EAP,
• jeśli po określonym czasie brak EAPOL, przełącznik odpala MAB i wysyła MAC do RADIUS,
• gdy RADIUS odrzuci MAB lub nie ma wpisu, port spada do guest VLAN / blokady, zgodnie z polityką.

Taka kaskada pozwala mieć na jednym porcie nowoczesny laptop z EAP-TLS i starą drukarkę IP wpiętą przez tani switch, bez dziur w bezpieczeństwie.

VLAN-y przypisywane lokalnie i z RADIUS

Przełącznik może dostać decyzję o VLAN-ie z dwóch źródeł:

• lokalna konfiguracja portu – access VLAN ustawiony w konfiguracji,
• atrybuty RADIUS – atrybuty Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-ID (lub vendor-specific).

Typowy wzorzec:

• port ma skonfigurowany „domyślny” VLAN (np. data VLAN),
• RADIUS może go nadpisać dynamicznym VLAN-em, jeśli polityka to przewiduje,
• dla MAB/guest może być zastosowany zupełnie inny VLAN (np. IoT/Guest).

Spójność nazewnictwa i numeracji VLAN-ów między RADIUS, przełącznikami i dokumentacją to rzecz, na której bardzo łatwo się wywrócić. Dobrą praktyką jest tabelka: ID VLAN – nazwa – przeznaczenie – trasa.

Failmode: co, gdy padnie RADIUS

Bez decyzji z RADIUS przełącznik nie wie, co zrobić z nową sesją. Możliwe są dwa skrajne podejścia:

• fail-open – port otwiera się „jakby wszystko było OK” (często wpuszcza do domyślnego VLAN),
• fail-close – brak RADIUS = brak dostępu (opcjonalnie tylko critical VLAN).

W praktyce stosuje się mieszankę:

• porty użytkowników biurowych – raczej fail-open do bardzo ograniczonego VLAN (żeby awaria RADIUS nie zatrzymała pracy całej firmy),
• porty do systemów krytycznych, szaf produkcyjnych – fail-close lub critical VLAN z mocno ograniczonym ruchem zarządzającym.

To trzeba przetestować – symulacja padnięcia RADIUS i obserwacja zachowania portów bywa bardziej pouczająca niż wiele dokumentów.

Debugowanie sesji na przełączniku

Bez sensownych logów każda awaria 802.1X zamienia się w wróżenie z fusów. Warto ogarnąć na starcie:

• komendy do podglądu sesji (np. show authentication sessions, show dot1x interface),
• tryby debug (EAPOL, RADIUS, MAB),
• mapowanie komunikatów (np. „RADIUS Access-Reject – no matching policy”).

Dobrym nawykiem jest doklejenie identyfikatora sesji (Session-ID) do logów po stronie RADIUS i SIEM. Ułatwia to śledzenie całej ścieżki: port → przełącznik → RADIUS → AD/PKI.

Typowe pułapki w sieci kablowej

W kablowym 802.1X powtarza się kilka klasycznych problemów:

• „niewidzialne” małe switche i extendery – użytkownik wpina własny sprzęt między gniazdo a PC, przez co liczba MAC-ów rośnie i port zaczyna zachowywać się inaczej niż w testach,
• niezidentyfikowane urządzenia bez supplicanta – sterowniki, PLC, stare drukarki, które lądują w guest VLAN lub są blokowane, bo nikt nie skonfigurował MAB,
• pomyłki w konfiguracji voice VLAN vs data VLAN – telefony IP próbują autoryzować się jak zwykły klient lub odwrotnie,
• duże opóźnienia z RADIUS – użytkownik widzi „brak sieci”, bo czas między podpięciem kabla a przydzieleniem VLAN zajmuje kilkanaście sekund.

Dobrą praktyką jest spisanie listy znanych „dziwnych” urządzeń przed wdrożeniem oraz przygotowanie dla nich dedykowanych polityk i reguł MAB.

802.1X w WiFi: integracja z WPA2/WPA3-Enterprise

Różnice między 802.1X na kablu a w radiu

Z punktu widzenia RADIUS mechanizm jest bardzo podobny – otrzymuje EAP w tunelu (RADIUS/EAP), podejmuje decyzję i odsyła atrybuty. Różnica jest na brzegu:

• na kablu klient rozmawia z przełącznikiem przy pomocy EAPOL bezpośrednio,
• w WiFi klient rozmawia z punktem dostępowym (AP/controllera) w ramach procedury WPA2/WPA3-Enterprise.

Efektem pozytywnej autoryzacji w WiFi jest nie tylko dostęp do VLAN, ale także wygenerowanie kluczy szyfrujących ruch (PTK/GTK). To jest zasadnicza przewaga nad WPA2-PSK, gdzie cały SSID dzieli jeden sekret.

WPA2-Enterprise vs WPA3-Enterprise

Oba tryby wykorzystują 802.1X, ale różnią się szczegółami:

• WPA2-Enterprise – klasyczny standard, obsługiwany praktycznie przez wszystkie urządzenia korporacyjne. Działa z EAP-TLS, PEAP i innymi metodami.
• WPA3-Enterprise – nowszy, ostrzejsze wymagania kryptograficzne (np. 192-bit security suite w wariancie „192-bit mode”), lepsza odporność na ataki słownikowe i niektóre wektory offline.

W praktyce w wielu środowiskach przez dłuższy czas równolegle istnieją SSID WPA2-Enterprise (kompatybilność) i WPA3-Enterprise (nowe urządzenia). Warto sprawdzić, czy kontroler/AP wspiera tryb mieszany (Transition Mode) i jak zachowują się klienci.

Dobór metod EAP w sieci bezprzewodowej

Metoda EAP stosowana w WiFi zwykle jest taka sama jak na kablu, ale są wyjątki:

• dla stacji roboczych domenowych – typowo EAP-TLS,
• dla urządzeń BYOD – często PEAP/MSCHAPv2 lub inny tunelowany login/hasło,
• dla IoT z ograniczonym wsparciem – jeśli obsługują jedynie PEAP, trzeba przygotować specyficzny zestaw polityk i certyfikatów serwerowych.

Warto wymusić w kontrolerze/AP określone metody (lista dozwolonych EAP) zamiast „akceptuj wszystko, co poda klient”. Ułatwia to debugowanie i eliminuje egzotyczne kombinacje, które różne supplicanty próbują stosować.

Planowanie SSID a segmentacja

Nadmierna liczba SSID zabija wydajność radiową (każdy SSID to dodatkowe ramki beacon/probe). Rozsądny plan to kilka sieci logicznych:

• SSID dla pracowników (WPA2/WPA3-Enterprise, EAP-TLS, pełen dostęp),
• SSID dla gości (WPA2-PSK lub open + portal, odseparowany VLAN, tylko internet),
• opcjonalnie SSID dla IoT/urządzeń specjalnych, jeśli nie da się ich wrzucić na ten sam SSID co pracownicy z innym przydziałem VLAN.

Jeżeli kontroler i AP wspierają dynamiczny VLAN po 802.1X, lepsze jest jedno SSID „firmowe” i różne VLAN-y z RADIUS w zależności od certyfikatu/użytkownika/grupy. Dla użytkownika wygląda to prościej, a radio nie jest przeciążone dodatkowymi sieciami.

Integracja z RADIUS: atrybuty WLAN i VLAN

W rozwiązaniach WiFi często pojawiają się vendor-specific attributes (VSA), dzięki którym RADIUS może sterować nie tylko VLAN-em, ale też innymi parametrami:

• przypisanie do policy profile (Cisco) lub role (Aruba),
• zastosowanie określonych ACL/Group Policy,
• bandwidth profile / QoS dla danej klasy użytkownika.

Mechanizm jest prosty: jeśli warunki polityki w RADIUS są spełnione (np. grupa AD, certyfikat EAP-TLS z konkretnym OID), serwer odsyła zestaw VSA, a kontroler/AP przypisuje użytkownika do odpowiedniej roli. VLAN staje się tylko jednym z parametrów obok ACL i QoS.

Roaming i czas trwania sesji 802.1X

Użytkownik w ruchu (laptop, smartfon) przełącza się między AP. Dwa mechanizmy mają wtedy znaczenie:

• fast roaming (np. 802.11r, OKC, CCKM) – pozwala przenosić klucze szyfrujące między AP bez pełnego powtarzania EAP,
• session timeout – okresowa reautoryzacja 802.1X (RADIUS Session-Timeout).

Za agresywne ustawienia timeoutów potrafią zepsuć doświadczenie użytkownika – częste reautoryzacje mogą powodować krótkie przerwy, zwłaszcza przy słabym sygnale. Z drugiej strony zbyt długie sesje zmniejszają „responsywność” polityk (np. zmiana grupy w AD będzie odczuwalna dopiero po godzinach).

Najczęściej zadawane pytania (FAQ)

Co daje 802.1X w sieci LAN i WiFi w praktyce?

802.1X zmienia model „podłączył się, więc ma pełny dostęp” na „podłączył się, więc musi się uwierzytelnić”. Port przełącznika lub SSID w WiFi przestaje być „głupym” medium, a staje się kontrolowanym punktem dostępu. Dzięki temu nie wpuszczasz do tej samej sieci jednocześnie serwerów, pracowników i przypadkowych urządzeń.

Po udanym uwierzytelnieniu możesz automatycznie przypisywać użytkowników i urządzenia do różnych VLAN‑ów, narzucać ACL (listy kontroli dostępu) czy QoS. Przykład: pracownik z laptopem domenowym trafia do VLAN biurowego, gość – do VLAN z samym internetem, a skaner magazynowy – do sieci produkcyjnej z bardzo ograniczonym ruchem.

Czym różni się 802.1X od zwykłego WiFi z hasłem (WPA2-PSK)?

W WPA2-PSK wszyscy znają jedno wspólne hasło do sieci. Jeśli hasło wycieknie lub były pracownik je zachowa, nie masz realnej kontroli nad tym, kto się łączy. W 802.1X (WPA2/WPA3-Enterprise) nie ma „hasła do WiFi” – jest tylko nazwa sieci (SSID), a dostęp zależy od indywidualnych poświadczeń użytkownika lub urządzenia.

802.1X samo w sobie nie szyfruje ruchu – za szyfrowanie w WiFi dalej odpowiada WPA2/WPA3, ale z kluczami unikalnymi dla każdej sesji. Różnica polega na tym, że klucze są wynegocjowane po poprawnym EAP, a nie wyliczone ze wspólnego hasła PSK.

Czy 802.1X szyfruje ruch w sieci lokalnej?

Nie. 802.1X to mechanizm kontroli dostępu na porcie (port-based access control), a nie szyfrowania. W sieci przewodowej decyduje tylko, czy port ma się „otworzyć” i do jakiego VLAN przypiąć klienta. Ruch dalej leci „w plaintext” na warstwie 2, chyba że zastosujesz dodatkowe mechanizmy (np. IPsec na wyższych warstwach).

W WiFi szyfrowanie robi WPA2 albo WPA3. 802.1X jest tam używany jako sposób uwierzytelnienia (EAP) i dystrybucji kluczy sesyjnych, ale sam nie jest protokołem szyfrującym.

Jak działa proces uwierzytelniania 802.1X krok po kroku?

Po podłączeniu urządzenia port przełącznika (lub AP) jest w stanie nieautoryzowanym i przepuszcza praktycznie tylko ramki EAPOL (EAP over LAN). Authenticator (przełącznik/AP) pyta klienta „kim jesteś?” (EAPOL-Request/Identity), klient odpowiada, a przełącznik pakuje tę odpowiedź w zapytanie RADIUS i wysyła do serwera uwierzytelniającego.

Serwer RADIUS prowadzi właściwy „dialog” EAP (np. PEAP, EAP-TLS) z klientem przez przełącznik jako pośrednika. Jeśli na końcu wyśle Access-Accept, port przechodzi w stan autoryzowany i przełącznik może zastosować atrybuty z RADIUS – np. przypisać VLAN, ACL lub inne parametry polityki.

Czym się różni uwierzytelnianie użytkownika od uwierzytelniania urządzenia w 802.1X?

Uwierzytelnianie użytkownika oznacza, że decyzja o dostępie zależy od konta osoby (login/hasło, certyfikat użytkownika). Typowo robi się to przez PEAP/MSCHAPv2 lub EAP-TLS z certyfikatem użytkownika powiązanym z kontem w AD. To dobry model np. dla pracowników biurowych.

Uwierzytelnianie urządzenia opiera się na tożsamości samej maszyny: certyfikacie komputera (EAP-TLS z kontem typu „Computer” w AD) albo – w wersji uproszczonej – na adresie MAC (MAB, MAC Authentication Bypass). Wtedy liczy się, czy sprzęt jest „firmowy” lub „produkcyjny”, niezależnie od tego, kto jest zalogowany. Często łączy się oba podejścia: najpierw musi przejść komputer, potem użytkownik.

W jakich sieciach warto wdrożyć 802.1X, a gdzie to przesada?

802.1X ma największy sens tam, gdzie jest dużo użytkowników i urządzeń, wymagane są audyty bezpieczeństwa albo chcesz automatycznie przypisywać VLAN‑y i polityki (pracownicy, goście, IoT, produkcja). Bez tego kończy się na ręcznym zarządzaniu VLAN‑ami i „zaufaniu do kabla” – co zwykle nie przechodzi przy poważniejszych wymaganiach bezpieczeństwa.

W bardzo małych środowiskach da się przeżyć z prostszym modelem: osobny SSID z WPA2-PSK dla gości, izolacja klient‑klient, osobny VLAN na sprzęt testowy z twardymi regułami firewall. Sensowną ścieżką jest start od 802.1X w WiFi (WPA2/WPA3-Enterprise), a dopiero potem objęcie nim portów przewodowych, gdzie wyjątków typu drukarki czy kamery bywa najwięcej.

Jak 802.1X współpracuje z RADIUS i Active Directory?

Przełącznik lub AP pełni rolę Authenticatora i mówi z serwerem RADIUS (Authentication Server). RADIUS z kolei nie musi mieć własnej bazy kont – typowo pyta o nie Active Directory lub inny katalog LDAP. W efekcie polityki dostępu do sieci możesz powiązać z grupami i OU w AD, zamiast utrzymywać osobne listy użytkowników.

Tip: RADIUS może równolegle używać kilku źródeł tożsamości – np. AD dla pracowników, lokalnej bazy dla gości i statycznych wpisów MAC dla urządzeń IoT. Całość jest wtedy spięta jednym mechanizmem 802.1X na brzegu sieci, a logika „kto ma do czego dostęp” siedzi centralnie w RADIUS i katalogu.

Najważniejsze wnioski

• 802.1X zamienia sieć z modelu „kto się podłączy, ten ma dostęp” na kontrolę dostępu na porcie: samo fizyczne wpięcie do gniazdka lub znajomość hasła do WiFi nie oznacza już zaufania.
• Standard działa jako port-based NAC (Network Access Control) – przełącznik lub punkt dostępowy przed dopuszczeniem ruchu IP wymusza uwierzytelnienie EAP, a po sukcesie może przypisać konkretny VLAN, ACL czy zasady QoS.
• 802.1X nie szyfruje ruchu; w WiFi szyfrowanie zapewnia WPA2/WPA3 (klucze per sesja), a 802.1X jedynie decyduje, czy i jak szeroko otworzyć port oraz do jakiej sieci logicznej trafi urządzenie.
• Mechanizm dobrze skaluje się w biurach, magazynach, halach produkcyjnych i sieciach IoT: pozwala oddzielić firmowe stacje, gości oraz urządzenia produkcyjne, a sprzęty bez 802.1X obsłużyć przez MAB i trzymać w mocno ograniczonych VLAN-ach.
• Można uwierzytelniać osobno użytkowników (np. PEAP/MSCHAPv2, EAP-TLS z kontem usera) i urządzenia (EAP-TLS z certyfikatem komputera, MAB), a w środowiskach domenowych sensowne jest podejście hybrydowe: zaufany musi być jednocześnie sprzęt i zalogowany użytkownik.
• 802.1X ma największy sens tam, gdzie rośnie liczba urządzeń i wymogi bezpieczeństwa: ułatwia spełnianie regulacji, automatyczne przypisywanie VLAN i kontrolę BYOD/IoT; w małych, prostych instalacjach często wystarczy osobny SSID z PSK i izolacją klientów.

Bibliografia

• IEEE Std 802.1X-2020 – IEEE Standard for Local and metropolitan area networks—Port-Based Network Access Control. IEEE (2020) – Podstawowa norma 802.1X: pojęcia, role, przepływ EAPOL
• RFC 3748 – Extensible Authentication Protocol (EAP). IETF (2004) – Definicja EAP, ramy protokołu używanego w 802.1X
• Guide to IEEE 802.1X Port-Based Network Access Control. National Institute of Standards and Technology (2010) – Przewodnik NIST po 802.1X, scenariusze wdrożeń i dobre praktyki
• Secure Wired and Wireless LAN Access with 802.1X. Cisco Systems – Opis ról supplicant, authenticator, RADIUS i przepływu EAPOL/RADIUS