802.1X, FreeRADIUS och dynamiska VLAN: En komplett guide

Informatec Digital » Resurser » 802.1X, FreeRADIUS och dynamiska VLAN: En komplett guide

Om du hanterar trådbundna eller Wi-Fi-nätverk och vill separera trafik efter användartyp utan att behöva en dyr NAC-lösning, är det en av de mest kraftfulla sakerna du kan göra att effektivt använda 802.1X, FreeRADIUS och dynamisk VLAN-tilldelning, och det är värt att förstå hur detta passar in i Zero Trust-arkitekturen . Korrekt implementerat låter det dig bestämma vilket nätverk varje enhet ansluter till baserat på vem den är, var den kommer ifrån eller vilken kataloggrupp den tillhör, utan att skapa SSID:er överallt eller vara bunden till en enda leverantör.

I den här artikeln kommer vi att gå igenom i detalj hur hela pusslet hänger ihop: rollen för 802.1X, typisk FreeRADIUS-konfiguration, RADIUS-attribut för VLAN, integration med Wi-Fi-kontroller och switchar , verkliga exempel (Omada, ExtremeCloud IQ, klassiska switchar), vanliga problem och till och med avancerade ämnen som Azure AD och felaktigt utformade attribut i LDAP. Målet är att du ska ha en tydlig och praktisk förståelse i slutet, och att kunna anpassa det du lär dig här till din egen infrastruktur, oavsett om den är liten eller stor.

802.1X och dynamiska VLAN: Grundläggande koncept och komponenter

802.1X-standarden är, enkelt uttryckt, grindvakten för ditt nätverk: tills enheten autentiseras ger porten eller Wi-Fi-nätverket den inte åtkomst till det legitima nätverket. För att uppnå verklig segmentering kombineras det med dynamisk VLAN-tilldelning med hjälp av RADIUS-attribut , så att servern bestämmer vilket VLAN varje klient ska tilldelas efter autentisering.

I alla 802.1X-distributioner finns det tre nyckelkomponenter som alltid visas, oavsett om du använder Omada, ExtremeCloud IQ eller generiska switchar:

• Supplikant: klienten som vill ansluta (bärbar dator, mobil, "klar" skrivare, etc.).
• Authenticator: nätverksutrustningen som styr åtkomst (switch, AP eller Wi-Fi-kontroller) och som kommunicerar med RADIUS-servern.
• Autentiseringsservernormalt en RADIE, ofta FreeRADIUS, som validerar autentiseringsuppgifter och bestämmer policy (tillåta, neka, lägga till ett VLAN eller ett annat).

Magin hos dynamiska VLAN färdas i form av RADIUS-attribut inom Access-Accept-protokollet . För VLAN förstår nästan alla tillverkare kombinationen av tunnelliknande attribut:

• Tunneltyp = VLAN
• Tunnel-Medium-Typ = IEEE-802
• Tunnel-Privat-Grupp-ID = "VLAN-ID" (vanligtvis ett nummer mellan 1 och 4095, även om det skickas som text)

När switchen eller AP:n tar emot en Access-Accept med dessa attribut, och om den stöder 802.1X och dynamiskt VLAN, tilldelar den porten eller Wi-Fi-sessionen till det VLAN som anges av RADIUS, och ignorerar portens standard-VLAN eller SSID (såvida inte RADIUS skickar något, i vilket fall den tillämpar sin lokala konfiguration).

FreeRADIUS-konfiguration för dynamiska VLAN

FreeRADIUS är den självklara RADIUS-servern med öppen källkod. Den kan installeras på alla enkla Linux-system , även på mycket liten hårdvara som NanoPi NEO eller Raspberry Pi, och med korrekt konfiguration kan den hantera mycket krävande miljöer. För dynamiska VLAN finns det två viktiga områden: att definiera användare/grupper och att korrekt placera modulerna i processorkedjan.

I enkla driftsättningar kan testanvändare definieras direkt i FreeRADIUS- användarfilen och tilldela dem det VLAN de ska få. Den typiska filen i Debian/Ubuntu finns på /etc/freeradius/3.0/users , och VLAN-posterna ser ut så här (förenklat och omskrivet):

anställd10 Klartext-lösenord := "nyckel10" Tjänsttyp := Inramad användare, Tunneltyp := VLAN, Tunnelmediumtyp := IEEE-802, Tunnelprivatgrupp-ID := "10" anställd20 Klartext-lösenord := "nyckel20" Tjänsttyp := Inramad användare, Tunneltyp := VLAN, Tunnelmediumtyp := IEEE-802, Tunnelprivatgrupp-ID := "20"

Med denna struktur kommer FreeRADIUS, efter en Access-Accept, att returnera de tre tunnelattributen så att NAS:en (switch eller AP) kan placera klienten i VLAN 10 eller 20, beroende på användaren. Nyckeln är att nätverksutrustningen stöder motsvarande RFC och respekterar dessa attribut före det konfigurerade åtkomst-VLAN:et.

I vissa scenarier, såsom integration med ExtremeCloud IQ, är det avgörande att dessa attribut skickas exakt i Access-Accept-satsen , och inte bara som "tunnlade" attribut i andra faser av EAP-processen. I standardkonfigurationer kan FreeRADIUS bearbeta eap- modulen först och sedan files- modulen (som läser användarens fil). Detta gör att kontrollenheten missar attributen vid rätt tidpunkt.

Den praktiska lösningen som har visat sig användbar är att justera filen /etc/freeradius/3.0/sites-enabled/default , och flytta files- modulen före eap inom authorize- blocket. På så sätt laddar FreeRADIUS de statiska användarattributen (inklusive VLAN) först och hanterar sedan EAP, så att tunnelattributen inkluderas där kontrollenheten förväntar sig dem när den slutliga Access-Accept konstrueras.

En annan rekommenderad justering är att inaktivera svaga EAP-metoder som EAP-MD5 , vilka aldrig var avsedda för produktionsmiljöer. Genom att redigera filen /etc/freeradius/3.0/mods-enabled/eap och kommentera bort eller ta bort MD5-avsnittet kommer FreeRADIUS att sluta erbjuda det. Det är en bra idé att fokusera din konfiguration på robusta metoder som EAP-TLS (certifikat) eller PEAP med MSCHAPv2.

VLAN-tilldelning med Omada: Intern RADIUS och extern FreeRADIUS

TP-Links Omada-ekosystem (kontroller + switchar + AP) integrerar 802.1X med dynamiska VLAN mycket bra, både med hjälp av dess interna RADIUS och genom att delegera till en extern FreeRADIUS. Det är ett mycket illustrativt exempel eftersom hela arbetsflödet är tydligt synligt.

För att använda RADIUS som är inbyggd i Omada-kontrollenheten följs vanligtvis en trestegsprocess. Först aktiveras den integrerade RADIUS i kontrollenhetens globala meny genom att ange IP-adressen (den för själva kontrollenheten) och aktivera alternativet Tunneled Reply så att tunnelattributen skickas korrekt till åtkomstenheten.

Sedan, när du är på den specifika webbplatsen, gå till Inställningar > Profil > RADIUS-profil , redigera profilen och skapa interna RADIUS-användare. För varje användare låter Omada dig ange ett namn, lösenord och VLAN-ID , så att när användaren autentiserar sig returnerar styrenheten VLAN-attributen till switchen eller AP:n utan att gå via en extern server.

Slutligen, i Inställningar > Autentisering > 802.1X , aktivera 802.1X, välj den interna RADIUS-profilen och aktivera explicit alternativet VLAN-tilldelning . I samma avsnitt väljer du de switchportar som kräver 802.1X-autentisering. Efter att du har sparat måste alla enheter som ansluter till dessa portar autentiseras, och om kontot har ett tilldelat VLAN-ID placeras det automatiskt i det VLAN:et.

Om vi ​​föredrar att centralisera allt på en extern FreeRADIUS-server, stöder Omada detta scenario perfekt. Det första steget är att redigera clients.conf- filen på FreeRADIUS-servern för att auktorisera kontrollenheten (eller området där switcharna/åtkomstpunkterna finns) som en RADIUS-klient, och ange IP-adressen eller subnätet och den delade hemligheten som vi senare kommer att konfigurera i Omada.

Tillbaka i Omada skapar du sedan en extern RADIUS-profil från Inställningar > Profiler > RADIUS-profil , där du anger FreeRADIUS IP-adress, autentiseringsporten (vanligtvis 1812) och det delade lösenordet. I styrenhetens 802.1X-inställningar väljer du den här externa profilen och återaktiverar VLAN-tilldelning , och markerar de portar eller SSID:er du vill skydda.

Ytterligare verifiering kan utföras från själva kontrollenheten: i Verktyg > Terminal , öppna en konsol mot switchen som har 802.1X aktiverat och kör kommandot show dot1x auth-state . Om allt fungerar korrekt ser du den autentiserade porten och VLAN:et som tilldelats av RADIUS (till exempel en port 1/0/1 autentiserad och associerad med VLAN 2).

Dynamiskt VLAN på Wi-Fi med FreeRADIUS och ExtremeCloud IQ

Ett annat mycket omfattande exempel är Wi-Fi-nätverk som hanteras av ExtremeCloud IQ (XIQ) med FreeRADIUS som autentiseringsserver. Här tilldelas det dynamiska VLAN:et primärt Wi-Fi-klienter baserat på tunnelattribut som returneras av FreeRADIUS.

Först är FreeRADIUS förberett att skicka dessa tre attribut i Access-Accept, precis som tidigare: poster i /etc/freeradius/3.0/users med användare och deras VLAN, och inställningen i sites-enabled/default så att files- modulen bearbetas före eap , eftersom XIQ förväntar sig exakt attributen i Accept.

Det rekommenderas starkt att inaktivera EAP-MD5 och använda metoder som PEAP/EAP-TLS . Efter att ha ändrat EAP-konfigurationsfilen, starta om tjänsten med ` systemctl restart freeradius` för att tillämpa ändringarna. Från och med då kommer servern att vara redo att svara på förfrågningar som skickas av åtkomstpunkterna som hanteras av XIQ.

På Extreme-molnsidan finns det två relevanta kontotyper: det kostnadsfria Connect-kontot , som tillåter grundläggande hantering av upp till tio enheter men inte stöder avancerade klassificeringsregler för dynamiska VLAN, och Pilot- versionen , som erbjuder en 90-dagars provperiod och möjliggör hela uppsättningen profiler och regler baserade på RADIUS-attribut.

Använd pilotkontot och skapa en ny nätverkspolicy från menyn "Konfigurera > Nätverkspolicyer", namnge den och välj "Endast Wi-Fi" för enkelhetens skull. I det andra steget definierar du SSID, vanligtvis som ett företagsnätverk med WPA2 eller WPA3, och associerar en RADIUS-grupp . När du skapar den här gruppen lägger du till FreeRADIUS som en extern server och anger dess IP-adress, hemlighet och portarna 1812/1813.

Därefter konfigureras användarprofiler , vilka i praktiken är åtkomstprofiler länkade till olika VLAN (till exempel VLAN10 och VLAN20). Det finns en standardprofil som tilldelas klienter vars RADIUS inte returnerar tunnelattribut, men för dynamiska VLAN definieras tilldelningsregler baserat på värdet Tunnel-Private-Group-ID och andra RADIUS-attribut.

Reglerna säger helt enkelt: "om Tunnel-Private-Group-ID som kommer från Accept är 10, tilldela användarprofil-VLAN 10"; om det är 20, tilldela användarprofil-VLAN 20, och så vidare. ExtremeCloud IQ översätter dessa regler i praktiken till att placera klienten på det VLAN som matchar attributet som skickas från FreeRADIUS.

Slutligen måste du bevilja åtkomst till dessa VLAN på den trådbundna sidan av AP:n genom att justera AP-profilen i XIQ så att upplänksporten tillåter alla konfigurerade VLAN och bibehåller det ursprungliga VLAN:et (vanligtvis VLAN 1). När allt är sparat och nätverkspolicyn har tillämpats på AP:erna kan du använda RADIUS-testverktyget som är integrerat i XIQ för att verifiera att FreeRADIUS är tillgängligt och att servern returnerar det förväntade VLAN-attributet för varje användare.

Omada SDN med FreeRADIUS: VLAN för trådbundna och trådlösa nätverk

Omadas SDN-lösning låter dig också tilldela dynamiska VLAN samtidigt över trådbundna och trådlösa nätverk med hjälp av en extern RADIUS som FreeRADIUS. Detta eliminerar behovet av att skapa flera olika SSID:er eller använda statiska PVID:er på switchportar.

Den typiska topologin inkluderar en Omada-kontroller, EAP-åtkomstpunkter, JetStream-switchar och en FreeRADIUS-server som körs på Linux. För att tillåta nätverksenheter att skicka autentiseringsförfrågningar till servern redigeras clients.conf -filen , vilket ställer in klienten på Omada-nätverksintervallet (till exempel 192.168.0.0/24) och ett delat lösenord.

Därefter konfigureras kontona i användarfilen , och definierar till exempel två användare: en för VLAN10 och en annan för VLAN20, med deras respektive attribut Tunnel-Type, Tunnel-Medium-Type och Tunnel-Private-Group-Id. I WPA-Enterprise är det vanligt att även modifiera EAP-konfigurationsfilen för att anpassa metoden till klienttypen (till exempel EAP-PEAP för Windows-bärbara datorer).

Från Omada-kontrollenheten, i autentiseringsavsnittet, skapar du en RADIUS-profil som pekar mot FreeRADIUS och väljer alternativet "Aktivera VLAN-tilldelning för trådlöst nätverk" . Detta säkerställer att när en klient autentiserar via WPA-Enterprise, kommer Omada att fråga RADIUS-servern och placera enheten i det VLAN som returneras av servern istället för det statiska VLAN för SSID.

Det är också nödvändigt att definiera nätverkets VLAN-gränssnitt i Inställningar > Kabelanslutna nätverk > LAN , och skapa till exempel två logiska gränssnitt för VLAN10 och VLAN20 med deras respektive IP-gateways. På så sätt, när en klient är på VLAN10, kommer den att få en IP-adress inom det VLAN:ets intervall , och detsamma gäller för VLAN20.

På den trådlösa sidan skapas ett SSID med hjälp av WPA-Enterprise, vilket pekar mot RADIUS-profilen. När en klient ansluter och autentiserar sig som till exempel test10, får användaren en IP-adress från VLAN10; om de använder test20 kommer de att tilldelas VLAN20, utan att vi behöver skapa ett specifikt SSID för varje enskilt fall.

På den trådbundna sidan är logiken liknande men använder 802.1X portbaserad . 802.1X aktiveras i motsvarande sektion av styrenheten, typen "Portbaserad" väljs, "VLAN-tilldelning" aktiveras och de portar som kräver autentisering markeras. En portprofil tillämpas sedan på samma portar , vilket lägger till VLAN10 och VLAN20 som otaggade nätverk, vilket säkerställer att 802.1X-kontrollläget är inställt på "Auto" så att switchen initierar förhandling när den upptäcker en klient.

Med en enda RADIUS-konfiguration och ett par profiler säkerställer Omada SDN således att både trådbundna och Wi-Fi-användare hamnar i sina motsvarande VLAN enligt sina inloggningsuppgifter , utan att behöva multiplicera nätverk eller manuellt justera konfigurationen för varje port.

Praktiska exempel, vanliga misstag och konfigurationstips

Att arbeta med FreeRADIUS och dynamiska VLAN är inte bara rosenrött: flera återkommande problem uppstår när man går från laboratorietester till verkliga miljöer, särskilt när man hanterar LDAP/AD-kataloger, användarnamnsformat och komplexa policyer . Därför bidrar god riskhantering för cybersäkerhet till att minska incidenter.

Ett mycket typiskt fel inträffar när servern konstruerar en LDAP-fråga med hjälp av attributet %{Användarnamn} när den anländer i RADIUS. I många Windows-scenarier anländer formatet som DOMÄN\användare, med bakåtsnedstrecket kodat som \5cOm LDAP-mallen är byggd med uid=%{User-Name}Den resulterande frågan kommer att se ut som något i stil med uid=DOMINIO\5cusuariovilket sällan matchar den faktiska uid:en i LDAP-trädet och returnerar noll resultat.

Det här innebär att användarens attribut, inklusive VLAN- eller gruppvärdet som ska mappas, inte hittas i katalogen. Därför lägger servern inte till Tunnel-Private-Group-Id, och klienten förblir på switchens eller AP:s standard-VLAN. Detta mönster syns tydligt i FreeRADIUS-loggarna: en LDAP-fråga med uid:en "domain\5user" och tom sökutdata.

Den praktiska lösningen som har använts framgångsrikt är att ändra användningen av %{User-Name} till %{Stripped-User-Name} i LDAP-frågemallen i FreeRADIUS-konfigurationen, t.ex.:

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

På så sätt använder FreeRADIUS det "rena" användarnamnet, utan domän eller snedstreck, och sökningarna lyckas igen. Så snart LDAP returnerar rätt post kan servern tillämpa logiken för att tilldela VLAN baserat på grupper, OU:er eller specifika attribut, och generera Tunnel-Type, Tunnel-Medium-Type och Tunnel-Private-Group-Id igen i Access-Accept.

Ett annat märkligt fall inträffar med vissa switchar när statiska VLAN-konfigurationer på en port blandas med dynamiska 802.1X-konfigurationer. Till exempel, om man har port 17 på statiskt VLAN 4 och samtidigt försöker tvinga en specifik användare till VLAN 2 med hjälp av RADIUS. Om enheten inte respekterar tunnelattribut eller om den dynamiska VLAN-funktionen är inaktiverad, oavsett vad som händer i RADIUS, kommer porten att fortsätta att se trafik som VLAN 4.

I dessa situationer är det avgörande att granska switchens dokumentation för att explicit aktivera stöd för VLAN-tilldelning via RADIUS , och felsöka med kommandon som ` show dot1x` eller motsvarande, och kontrollera om enheten rapporterar något i stil med "ignorerar tunnelattribut" eller "dynamisk vlantilldelning inaktiverad". Först när tillverkaren stöder det och det är aktiverat kommer en användare som är ansluten till en fysisk port i VLAN 4 som standard faktiskt att hamna i VLAN 2 efter att ha autentiserat sig som "carlos" eller vem det nu är.

Det finns också klassiska debatter om lämpligheten av att använda dynamiska VLAN i fjärrskrivbordsscenarier (RDP) . När maskinautentisering sker vid Windows-start och sedan användarautentisering vid inloggning, kan VLAN-ändringen som utlöses av användarinloggning avbryta pågående RDP-sessioner eller orsaka DNS-problem när porten växlar från "maskin"-VLAN till "användar"-VLAN. Många administratörer har valt att behålla ett enda VLAN för alla tillstånd i dessa fall, eller att tilldela samma VLAN på både maskin- och användarnivå, vilket minimerar segmentändringar.

Slutligen, på den avancerade integrationsnivån, finns det ett växande intresse för att länka FreeRADIUS med Azure AD för att fastställa VLAN baserat på gruppmedlemskap i molnet. För närvarande finns det ingen officiell nativ modul som utför direkta gruppsökningar för VLAN i Azure AD, och lösningar involverar externa skript, anrop till Microsoft Graph API och viss justering. Det är ett dynamiskt område, och om en stabil och stödd lösning behövs delegeras denna logik ofta till en kommersiell NAC eller en annan mellanliggande komponent.

Genom att effektivt kombinera 802.1X, FreeRADIUS och dynamisk VLAN-tilldelning kan finjusterad nätverkssegmentering uppnås utan behov av besvärliga NAC-lösningar. Detta överensstämmer perfekt med en robust säkerhetsstrategi för företagsteknik : från styrenheter som Omada eller ExtremeCloud IQ till mellanstora switchar kan allt bidra om tunnelattribut respekteras, LDAP/AD-frågor hanteras noggrant och det är tydligt när användare ska flyttas dynamiskt från ett VLAN till ett annat baserat på deras identitet, roll eller vilken typ av enhet de ansluter.