Hele přiznám se, že jsem ohledně Radiusu téměř čistý teoretik :-)
Ono přes Radius se dá řešit několik různých věcí pro různé accessové sítě:
Radius původně vznikl pro dial-up. PPPčko. Jednotlivému userovi se podle loginu+hesla přidělil subnet /30, nebo ještě spíš jediná koncová IP adresa (protější kus na access routeru byl unnumbered). Všimněte si: access *router*, ty klientské relace jsou L3 subnety (možná vyždímané až do rozměru 1 IP adresy). A ta IPčka nebo koncové subnety mohl dávat klientům Radius ze své databáze.
802.1x v rámci LAN dělá to, že konkrétní L2 port nejdřív autentikuje proti radiusovému serveru, a v případě úspěchu ho může ještě prohodit do konkrétní VLANy (kterou sdělí radiusový server). Tady bych rád zdůraznil, že se povoluje přístup na L2 portu a dokonce navíc pro jednu konkrétní MAC adresu (pokud se nepletu). Teprve poté, co se příchozí stroj (MAC adresa, jedna per port) dostane do LAN (do konkrétní VLAN), má šanci říct si o DHCP - a já se domnívám, že DHCP je servírováno celé této VLAN síti, nikoli jednotlivé MAC adrese, a DHCP server patrně neví nic o access switchi ani o radiusu, a jestli se toho schématu bude účastnit DHCP relay, tak to není přímo navázáno na autentikaci konkrétního klienta na konkrétním L2 portu (jinak než nepřímo skrz připojení do VLANy). DHCP relay je L3 funkce (vlastně svého druhu proxy služba), tzn. může běžet na routeru na L3 rozhraní (tzn. pro jednotlivou VLANu, do které to rozhraní kouká). Že by L2 switch per port kradl DHCP dotazy a relayoval je per user ať už Radiusu nebo DHCP serveru, ...to mi úplně pod nos nejde. Toto samozřejmě nijak nevylučuje, že DHCP server následně přiřadí pevnou IP adresu podle MAC adresy nebo GUIDu apod. - na základě konfigurace DHCP serveru (Radius už v tom roli nehraje).
No a pak je Wifi. Wifi ESSID je něco jako VLANa ve vzduchu. Taky jsou ESSIDy s oblibou na VLANy 1:1 bridgovány. První koncepční rozdíl oproti metalickému ethernetu je v tom, že "port na APčku" kouká směrem ven do vzduchu na L2 do bezdrátové logické multipoint sítě, ve které je větší počet klientů. Druhý koncepční rozdíl shledávám v tom, že na wifi si klient napřed vybere nějaký ESSID, a teprve pak se k němu pokusí přihlásit, autentikačním mechanismem, který si ten ESSID nadiktuje. Třeba WPA2 v kombinaci s EAP, kterážto kombinace je na APčku skrz WiFi variantu 802.1x navázaná na radiusový back-end (server někde kus dál v síti). Tzn. mám pocit, že ESSID (a potažmo pevně přibridgovanou VLAN) si klient vybere a priori, v rámci WPA2 se klient pobaví s AP také o 802.1x, a Radiusového serveru se AP jenom zeptá, jestli smí klienta do žádané L2 sítě vpustit (plus nějaká krypto omáčka). Prosím opravte mne, pokud kecám - domnívám se, že 802.1x na wifi nemá moc, přehodit klienta na jiný ESSID, a pokládám za nepravděpodobné, že by APčko v rámci jediného ESSIDu forwardovalo provoz různých WiFi klientů do různých páteřních VLAN. Letmým pohledem odhaduji, že by nebylo úplně triviální zařídit, aby na takovém forwardovacím schématu správně fungovaly všelijaké mechanismy mezi Ethernetem a IP (ačkoli vyloučit to nemohu). Přidělování IP adres na WiFi je opět v režii DHCP, server umístěný kdekoli v rámci VLANy... DHCP relay může jistě servírovat přímo AP (jeho L3 rozhraní do dané VLANy+ESSIDu, pokud je nakonfigurováno) ale nepočítám, že by to nějak spolupracovalo s Radiusem. A každopádně se DHCP děje opět až poté, co proběhla autentikace a rozběhlo se WPA2 šifrování payloadu.
Přidělovat DHCP server Radiusem mi přijde jako nedorozumění. DHCP server slouží celé VLANě, nikoli jednotlivému autentikovanému klientovi 802.1x. A jestli DHCP server slouží té VLANě skrz "directly connected" rozhraní, nebo skrz relay, to na věci mnoho nemění.
DHCP relay je proxy mechanismus, který Vám umožní servírovat DHCP více různým L2 broadcastovým segmentům v rozsáhlejší routované L3 síti - aniž by do každého L2 segmentu musel přímým rozhraním koukat DHCP server. DHCP server může být jediný kdekoli v síti (s jedinou síťovkou a IP adresou) a skrz lokální instance služby DHCP relay (na routerech) "distribuovaně" obsluhovat větší počet subnetů.
DHCP relay jsem tuším viděl použitý i pro GPRS APN, kde GGSN (access router operátora v GPRS síti) napřed přiřadil mobilního klienta do APN (VRF, MPLS VPN) podle "APN jména", následně ho autentikoval proti radiusu (odkaz na radius server u zákazníka už per APN), a následně GGSN v rámci APN přiděloval IP adresy DHCP relayem ze serveru na straně zákazníka, skrz nějaký VPN tunel nad pevnou infrastrukturou... Doufám že nekecám, "mobilních paketové sítě" jsou asi nejsložitější accessová technologie, co jsem viděl, a mezi generacemi se koncepce i názvosloví vyvíjejí. Distribuovaný Radius s použitím "realmů", mezinárodní roaming... to byl teprve začátek, někdy na přelomu století. Podrobnosti zdaleka neznám a do dalšího vývoje nevidím. Pravda je, že zrovna v těch mobilních sítích by mi přidělování IPček přímo Radiusem jednotlivým "mobilním terminálům" dávalo docela dobrý smysl. Když i na ten DHCP server se to musí roubovat přes UID, protože MTčka nemají MAC adresy. (Nebo dneska na L4 už mají?) Akorát že jestli má APN nějakou vnitřní routovanou strukturu, tak by z toho plynuly per-APN instance OSPF apod. - radši přestanu fantazírovat.
31 Odpovědí
7631 Zhlédnutí