- 802.1X amb FreeRADIUS permet assignar VLANs dinàmiques usant atributs RADIUS estàndard.
- Controladores com Omada i ExtremeCloud IQ integren bé FreeRADIUS per segmentar usuaris cablejats i Wi‑Fi.
- Errors en consultes LDAP, mètodes EAP insegurs o switches mal configurats trenquen l'assignació de VLAN.
- Una bona planificació de polítiques i proves evita problemes amb RDP, dispositius legacy i entorns híbrids.
Si gestiones xarxes cablejades o Wi-Fi i vols separar el trànsit per tipus d'usuari sense ficar-te en una solució NAC caríssima, jugar bé amb 802.1X, FreeRADIUS i assignació dinàmica de VLANs és tan potent com pots fer, i convé entendre com encaixa això amb l' arquitectura Zero Trust . Ben muntat, us permet decidir a quina xarxa es connecta cada dispositiu en funció de qui és, d'on ve o de quin grup de directori pertany, sense anar creant SSIDs per tot arreu ni lligar-vos a un únic fabricant.
En aquest article desgranarem de forma molt detallada com encaixa tot el puzle: paper de 802.1X, configuració típica de FreeRADIUS, atributs RADIUS per a VLANs, integració amb controladores Wi‑Fi i switches , casos reals (Omada, ExtremeCloud IQ, switches clàssics) o problemes habituals. La idea és que en acabar tinguis una visió clara i pràctica, i que puguis adaptar allò que vegis aquí a la teva pròpia infraestructura, sigui petita o gran.
802.1X i VLANs dinàmiques: conceptes bàsics i components
L'estàndard 802.1X és, dit ràpid, el porter de la teva xarxa: fins que el dispositiu no s'autentica, el port o la Wi‑Fi no donen pas a la xarxa «bona». Per aconseguir segmentació real, es combina amb assignació dinàmica de VLAN usant atributs RADIUS , de manera que el servidor decideix a quin VLAN cau cada client després d'autenticar-se.
En qualsevol desplegament 802.1X hi ha tres peces clau que sempre apareixen, és igual que utilitzis Omada, ExtremeCloud IQ o switches genèrics:
- Supplicant: el client que es vol connectar (portàtil, mòbil, impressora “llista”, etc.).
- autenticador: l'equip de xarxa que controla l'accés (switch, AP o controladora Wi-Fi) i que parla amb el servidor RADIUS.
- Servidor d'autenticació: normalment un RADIUS, moltes vegades FreeRADIUS, que valida credencials i decideix política (permetre, denegar, ficar en una VLAN o una altra).
La màgia de les VLANs dinàmiques viatja en forma d' atributs RADIUS dins de l'Access-Accept . Per a VLANs, gairebé tots els fabricants entenen la combinació d'atributs tipus túnel:
- Tunnel-Type = VLAN
- Tunnel-Medium-Type = IEEE-802
- Tunnel-Private-Group-Id = «ID de VLAN» (normalment un número entre 1 i 4095, encara que s'envia com a text)
Quan el switch o l'AP rep un Access-Accept amb aquests atributs, si teniu suport de 802.1X i VLAN dinàmica, assigneu el port o la sessió Wi-Fi a la VLAN indicada pel RADIUS ignorant la VLAN per defecte del port o SSID (llevat que el RADIUS no envieu res, en aquest cas aplica.
Configuració de FreeRADIUS per a VLANs dinàmiques
FreeRADIUS és el servidor RADIUS open source per excel·lència. Es pot instal·lar a qualsevol Linux modest , fins i tot en maquinari molt petit tipus NanoPi NEO o Raspberry Pi, i amb una bona configuració és capaç de manejar entorns molt seriosos. Per a VLANs dinàmiques hi ha dos blocs importants: definició d'usuaris/grups i col·locació correcta dels mòduls a la cadena de processament.
En desplegaments senzills, es poden definir usuaris de prova directament a l'arxiu users de FreeRADIUS, assignant-los ja la VLAN que volem que rebin. El fitxer típic de Debian/Ubuntu és a /etc/freeradius/3.0/users , i les entrades amb VLAN queden així (simplificada i reescrita):
empleat10 Cleartext-Password := "clau10" Service-Type := Framed-User, Tunnel-Type := VLAN, Tunnel-Medium-Type := IEEE-802, Tunnel-Private-Group-Id := "10" empleat20 Cleartext-Password Framed-User, Tunnel-Type := VLAN, Tunnel-Medium-Type := IEEE-802, Tunnel-Private-Group-Id := "20"
Amb aquesta estructura FreeRADIUS tornarà, després d'un Access-Accept, els tres atributs túnel perquè el NAS (switch o AP) col·loqui el client a la VLAN 10 o 20 segons l'usuari. El secret és que l'equip de xarxa suporti la RFC corresponent i respecti aquests atributs davant de la VLAN d'accés configurada.
En alguns escenaris, com a integració amb ExtremeCloud IQ, és fonamental que aquests atributs s'enviïn exactament a l' Access-Accept , i no només com a atributs “tunneled” en altres fases de l'EAP. En configuracions per defecte, FreeRADIUS pot processar primer el mòdul eap i després el mòdul files (que és el que llegeix el fitxer users). Això fa que la controladora no vegi els atributs en el moment adequat.
La solució pràctica que s'ha demostrat útil és ajustar el fitxer /etc/freeradius/3.0/sites-enabled/default , movent el mòdul fils per davant de eap dins del bloc authorize . D'aquesta manera, FreeRADIUS carrega primer els atributs estàtics d'usuari (incloent-hi VLAN) i després gestiona l'EAP, de manera que en construir l'Access-Accept final s'inclouen els atributs de túnel on la controladora els espera.
Un altre ajustament recomanable és desactivar mètodes d'EAP febles com EAP-MD5 , que mai no es van pensar per a entorns productius. Editant el fitxer /etc/freeradius/3.0/mods-enabled/eap i comentant o eliminant la secció MD5, FreeRADIUS deixarà d'oferir-lo. És bona idea centrar la configuració en mètodes robusts com EAP-TLS (certificats) o PEAP amb MSCHAPv2.
Assignació de VLAN amb Omada: RADIUS intern i FreeRADIUS extern
L'ecosistema Omada de TP-Link (controladora + switches + AP) integra molt bé 802.1X amb VLAN dinàmica, tant usant el seu RADIUS intern com delegant en un FreeRADIUS extern. És un cas molt il·lustratiu perquè es veu clarament el flux complet.
Per utilitzar el RADIUS incorporat a la controladora Omada, se sol seguir un procés en tres grans passos. Primer, al menú global de la controladora s'habilita el RADIUS integrat , indicant la IP (la de la mateixa controladora) i activant l'opció de Tunneled Reply perquè enviï correctament els atributs de túnel a l'equip d'accés.
Després, ja al lloc concret, s'entra a Settings > Profile > RADIUS Profile , s'edita el perfil i es creen usuaris RADIUS interns. Per a cada usuari, Omada permet fixar un nom, contrasenya i VLAN ID , de manera que quan aquest usuari s'autentiqui, serà la controladora qui retorni els atributs VLAN al switch oa l'AP sense passar per un servidor extern.
Finalment, a Settings > Authentication > 802.1X s'activa el 802.1X, se selecciona el perfil RADIUS intern i s'habilita explícitament l'opció de VLAN Assignment . Al mateix apartat es marquen els ports del switch que requeriran autenticació 802.1X. Després de desar, qualsevol dispositiu que connecteu a aquests ports haurà d'autenticar-se i, si el compte té un VLAN ID assignat, es col·locarà en aquesta VLAN de forma automàtica.
Si preferim centralitzar-ho tot en un FreeRADIUS extern, Omada suporta perfectament aquest escenari. El primer pas és editar el fitxer clients.conf al servidor FreeRADIUS per autoritzar la controladora (o al rang on estiguin els switches/AP) com a client RADIUS, indicant IP o subxarxa i el shared secret que més tard configurarem a Omada.
Després, de nou a Omada, es crea un RADIUS Profile extern des de Settings > Profiles > RADIUS Profile , on s'introdueix la IP del FreeRADIUS, el port d'autenticació (1812 normalment) i la contrasenya compartida. A la configuració de 802.1X de la controladora se selecciona aquest perfil extern i es torna a activar VLAN Assignment , marcant els ports o SSIDs que vulguem protegir.
La comprovació posterior es pot fer des de la pròpia controladora: a Tools > Terminal s'obre una consola contra el switch que té 802.1X activat i s'executa l'ordre show dot1x auth-state . Si tot està bé, veureu el port autenticat i la VLAN assignada per RADIUS (per exemple, un port 1/0/1 autenticat i associat a VLAN 2).
VLAN dinàmica a Wi‑Fi amb FreeRADIUS i ExtremeCloud IQ
Un altre cas molt complet és el de xarxes Wi‑Fi gestionades per ExtremeCloud IQ (XIQ) usant FreeRADIUS com a servidor d'autenticació. Aquí la VLAN dinàmica s'assigna sobretot a clients Wi‑Fi segons atributs de túnel que torna FreeRADIUS.
Primer es prepara FreeRADIUS per enviar aquests tres atributs a l'Access-Accept, igual que abans: entrades a /etc/freeradius/3.0/users amb usuaris i els seus VLANs, i l'ajust a sites-enabled/default perquè el mòdul fils es processi abans que eap , ja que XIQ espera els atributs exactament.
És molt recomanable deixar desactivat EAP-MD5 i utilitzar mètodes com PEAP/EAP-TLS . Després de modificar el fitxer de configuració EAP, es reinicia el servei amb un systemctl restart freeradius per aplicar els canvis. A partir d'aquí, el servidor estarà llest per respondre a les peticions que us enviïn els AP gestionats per XIQ.
Per la part del núvol d'Extreme, hi ha dos tipus de compte rellevants: el gratuït Connect , que permet gestió bàsica de fins a deu dispositius però no suporta regles de classificació avançades per a VLANs dinàmiques, i la versió Pilot , que ofereix prova de 90 dies i sí que habilita tot el joc de perfils i regles basades en atributs RADIUS.
Amb el compte Pilot, es crea una nova Network Policy des del menú Configure > Network Policies, se li dóna nom i es tria que només sigui per a Wi‑Fi per simplificar. Al segon pas es defineix l'SSID, normalment com a xarxa Enterprise amb WPA2 o WPA3, i s'associa un RADIUS Group . En crear aquest grup s'afegeix el FreeRADIUS com a servidor extern, indicant IP, secret i ports 1812/1813.
Després es configuren els User Profiles , que són, a la pràctica, perfils d'accés vinculats a diferents VLAN (per exemple, VLAN10 i VLAN20). Hi ha un perfil per defecte al qual aniran a parar els clients el RADIUS dels quals no retorni atributs de túnel, però per a VLAN dinàmica es marquen regles d'assignació basades en el valor de Tunnel-Private-Group-ID i altres atributs RADIUS.
Les regles simplement diuen: «si el Tunnel-Private-Group-ID que ve a l'Accept és 10, assigna l'User Profile VLAN10»; si és 20, assigneu l'User Profile VLAN20, i així successivament. ExtremeCloud IQ tradueix aquestes regles a la pràctica a col · locar el client a la VLAN que coincideix amb l' atribut enviat des de FreeRADIUS.
Finalment, cal donar accés a aquestes VLAN al costat cablejat de l'AP, ajustant el perfil d'AP a XIQ perquè el port d'uplink permeti totes les VLAN configurades i mantingui la nativa (normalment VLAN 1). Un cop desat tot i aplicada la Network Policy als AP, es pot fer servir l'eina de RADIUS Test integrada a XIQ per comprovar que FreeRADIUS està accessible i que el servidor torna l'atribut de VLAN esperat per a cada usuari.
Omada SDN amb FreeRADIUS: VLANs per a cable i sense fil
La solució SDN d'Omada també permet assignar VLANs dinàmiques alhora en xarxes sense fil i cablejades usant un RADIUS extern com a FreeRADIUS. Això evita haver de crear molts SSID diferents o jugar amb PVIDs fixos als ports del switch.
La topologia típica inclou controladora Omada, punts d'accés EAP, switches JetStream i el servidor FreeRADIUS sobre Linux. Perquè els equips de xarxa puguin enviar peticions d'autenticació al servidor, s'edita el fitxer clients.conf fixant com a client el rang de xarxa dels Omada (per exemple, 192.168.0.0/24) i una contrasenya compartida.
Després es preparen els comptes al fitxer users , definint per exemple dos usuaris: un per a VLAN10 i un altre per a VLAN20, amb els seus respectius atributs Tunnel-Type, Tunnel-Medium-Type i Tunnel-Private-Group-Id. A WPA-Enterprise és freqüent tocar també el fitxer de configuració EAP per adaptar el mètode al tipus de clients (per exemple, EAP-PEAP per a portàtils Windows).
Des de la controladora Omada, a l'apartat d'autenticació es crea un RADIUS Profile apuntant al FreeRADIUS, i es marca l'opció Enable VLAN Assignment for Wireless Network . Això fa que, quan un client s'autentiqui via WPA-Enterprise, Omada consulteu el RADIUS i col·loqueu el dispositiu a la VLAN retornada pel servidor en lloc de a la VLAN fixa del SSID.
És necessari, a més, definir les pròpies interfícies VLAN de la xarxa a Settings > Wired Networks > LAN , creant per exemple dues interfícies lògiques per a VLAN10 i VLAN20 amb les portes d'enllaç IP. Així, quan un client caigui a VLAN10, obtindreu un IP dins del rang d'aquesta VLAN , i el mateix per a VLAN20.
Al pla sense fil, es crea un SSID amb WPA-Enterprise apuntant al perfil RADIUS. En connectar-se un client i autenticar-se com ara test10, l'usuari rebrà una IP de VLAN10; si utilitzeu test20, caurà a VLAN20, sense que haguem de crear un SSID específic per a cada cas.
Al costat cablejat, la lògica és similar però utilitzant 802.1X Port-Based . S'habilita el 802.1X a la secció corresponent de la controladora, se selecciona el tipus Port Based, s'activa VLAN Assignment i es marquen els ports que requeriran autenticació. Sobre aquests mateixos ports s'aplica un port profile que afegeix les VLAN10 i VLAN20 com a xarxes untagged, assegurant que el mode de control 802.1X estigui a «Auto» perquè el switch faci la negociació quan detecta un client.
Així, amb una sola configuració de RADIUS i un parell de perfils, Omada SDN aconsegueix que tant l'usuari cablejat com el Wi‑Fi acabin al seu VLAN corresponent segons les credencials , sense haver de multiplicar xarxes o tocar manualment la configuració de cada port.
Casos pràctics, errors freqüents i trucs de configuració
Treballant amb FreeRADIUS i VLAN dinàmica no tot són roses: hi ha diversos problemes recurrents que apareixen així que es passa de proves de laboratori a entorns reals, sobretot quan entren en joc directoris LDAP/AD, formats de nom d'usuari i polítiques complexes , per la qual cosa una bona gestió de riscos de ciberseguretat ajuda a reduir incidències.
Una fallada molt típica passa quan el servidor arma una consulta LDAP usant l'atribut %{User-Name} tal com arriba al RADIUS. En molts escenaris Windows, el format arriba com DOMINI\usuari, amb la barra invertida codificada com \5c. Si la plantilla LDAP es construeix amb uid=%{User-Name}, la query resultant serà alguna cosa com uid=DOMINIO\5cusuario, que poques vegades coincideix amb el uid real a l'arbre LDAP, tornant zero resultats.
Això implica que no es troben els atributs de l'usuari al directori, inclòs el possible valor de VLAN o grup que es vulgui mapejar, per la qual cosa el servidor no afegeix Tunnel-Private-Group-Id i el client es queda a la VLAN per defecte del switch o AP. Als logs de FreeRADIUS es veu clarament aquest patró: consulta LDAP amb uid «domini\5cusuari» i sortida de cerca buida.
La solució pràctica que s'ha utilitzat amb èxit és canviar a la configuració de FreeRADIUS l'ús de %{User-Name} per %{Stripped-User-Name} a la plantilla de consulta LDAP, p. ex.:
if ("%{ldap:ldap:///dc=exemple,dc=com?uid?sub?(|(uid=%{Stripped-User-Name})(macAddress=%{Calling-Station-Id}))}") { ... }
D'aquesta manera, FreeRADIUS utilitza el nom d'usuari net, sense domini ni barra, i les cerques tornen a donar resultat. Quan LDAP torna l'entrada correcta, el servidor pot aplicar la lògica per assignar VLANs basades en grup, OU o atributs específics, generant de nou Tunnel-Type, Tunnel-Medium-Type i Tunnel-Private-Group-Id a l'Access-Accept.
Un altre cas curiós es dóna amb alguns switches quan es barreja configuració estàtica de VLAN al port amb 802.1X dinàmic. Per exemple, tenir el port 17 a la VLAN 4 estàtica i, alhora, pretendre que RADIUS forci un usuari concret a la VLAN 2. Si l'equip no respecta els atributs de túnel o la funció de VLAN dinàmica està deshabilitada, passi el que passi a RADIUS, el port seguirà veient trànsit com a VLAN 4.
En aquest tipus de situacions és crucial revisar la documentació del switch per activar-li explícitament el suport de VLAN assignment via RADIUS , i depurar amb ordres com show dot1x o equivalents, verificant si l'equip comenta alguna cosa tipus ignoring tunnel attributes o dynamic vlan assignment disabled. Només quan el fabricant ho suporta i està habilitat s'aconseguirà que un usuari connectat a un port físic a VLAN 4 per defecte acabi realment a VLAN 2 després d'autenticar-se com a «carlos» o qui sigui.
També hi ha debats clàssics sobre la idoneïtat de fer servir VLAN dinàmica en escenaris amb Remote Desktop (RDP) . Quan es fa autenticació d'ordinador en arrencar Windows i després autenticació d'usuari en iniciar sessió, el canvi de VLAN que provoca el login de l'usuari pot tallar sessions RDP en curs o provocar problemes de DNS mentre el port salta de la VLAN de màquina a la VLAN d'usuari. Més d'un administrador ha optat per mantenir una única VLAN per a tots els estats en aquests casos, o per assignar la mateixa VLAN a nivell d'equip i usuari, i reduir al mínim els canvis de segment.
Finalment, a nivell d'integració avançada, hi ha interès creixent a lligar FreeRADIUS amb Azure AD per determinar la VLAN segons la pertinença a grups al núvol. A dia d'avui no hi ha un mòdul oficial nadiu que faci «group lookup» directe a Azure AD per a VLANs, i les aproximacions passen per scripts externs, cridades a Microsoft Graph API i una mica de treball de cola. És un camp en moviment, i si cal alguna cosa estable i suportat moltes vegades s'acaba delegant aquesta lògica en un NAC comercial o en una altra peça intermèdia.
Combinant bé 802.1X, FreeRADIUS i l'assignació dinàmica de VLANs es pot aconseguir una segmentació fina de la xarxa sense necessitat de solucions NAC pesades, el que encaixa dins d'una estratègia de seguretat tecnològica en empreses : des de controladores com Omada o ExtremeCloud IQ fins a switches de gamma mitjana, tot es pot col·laborar si tu LDAP/AD i es té clar quan convé o no moure dinàmicament els usuaris d'una VLAN a una altra segons la identitat, el rol o el tipus de dispositiu que connecten.
