Hvorfor et RADIUS-VLAN-svar ikke gør noget for en VPN-bruger

Du tilføjer VLAN-attributten til NPS-politikken, VPN-brugeren opretter forbindelse, og bærbaren lander stadig i standardpoolen. RADIUS-serveren returnerer det, du bad om, hvilket får fejlen til at ligne et cacheproblem. Det er den normalt ikke. Et Access-Accept bærer autorisationshints, og kun den netværksadgangsserver, der modtog dem, kan omsætte ét til en netværkstildeling.

Start ved gatewayen, ikke ved politikken

Følg kæden fra klienten og indad, før du ændrer noget. Klienten beder gatewayen om en session, gatewayen spørger RADIUS, om brugeren må få en, og RADIUS svarer med et resultat og et sæt attributter. Derefter anvender gatewayen det, den ved hvordan den skal anvende.

Din gennemgang starter ved fjerde trin, og derfor ser de første tre sunde ud. Intet i udvekslingen forpligter gatewayen til at implementere en attribut, den har modtaget. Svaret er en anmodning til gatewayen, ikke en kendsgerning om klienten.

Hvad switchen gør, som VPN ikke kan

En 802.1X-adgangsswitch er en autentifikator med porte, og dynamisk VLAN-tildeling flytter en af disse porte til et VLAN, som switchen allerede bærer. RADIUS-tunnelattributterne beskriver den hensigt i en form, switchen forstår. En routet VPN afslutter tunneler, ikke switchporte, og dens klienter får normalt en adresse og en rute i stedet for medlemskab af et broadcast-domæne. Der er ingen port at flytte, så den samme attribut har intet at virke på.

Dette er en modelforskel, ikke en leverandørfejl. Nogle gateways tilføjer deres egen gruppepolitik, poolvalg eller filtermekanisme, der ser ens ud på et skærmbillede. Andre implementerer intet af det, og attributten logges og ignoreres. Læs dokumentationen for den fjernadgangstilstand, du faktisk aktiverede, ikke den på skærmbilledet.

Læs det svar, serveren faktisk sendte

Bekræft, hvad RADIUS returnerede, i stedet for hvad politikeditoren viser. En testanmodning med samme brugernavn og en kendt adgangskode udskriver svarets attributter i læsbar form, og det afgør spørgsmålet i ét trin.

radtest alice secret 10.0.0.10 0 testing123

Hvis VLAN-attributterne mangler i det svar, skal du først rette politikmatchningen. Hvis de er til stede, har serveren gjort sin del, og hullet er længere nede.

Bevis først sessionspolitikken, derefter rækkevidden

Se nu på den session, gatewayen byggede. Listen over aktive sessioner viser poolen, den tildelte adresse og enhver gruppepolitik, som gatewayen har vedhæftet, og det er det eneste bevis, der betyder noget for håndhævelsen. Sammenlign det med, hvad brugeren kan nå, i stedet for med hvad politikken havde til hensigt.

swanctl --list-sas

Test derefter én tilladt og én afvist ressource fra klienten, fordi en adresse fra den rigtige pool ikke beviser isolation. Hvis gatewayen ikke har nogen mekanisme til den tildeling, du ønsker, skaber flere kopier af attributten ikke en. En adresse fra den forventede pool kan eksistere sammen med fuld adgang til alle andre pools. Vælg en understøttet politikmekanisme, eller ændr netværksdesignet med vilje.