Hvorfor et RADIUS-VLAN-svar ikke gjør noe for en VPN-bruker

Du legger VLAN-attributtet til NPS-policyen, VPN-brukeren kobler til, og den bærbare maskinen lander fortsatt i standardpoolen. RADIUS-serveren returnerer det du ba om, noe som får feilen til å se ut som et cacheproblem. Det er den vanligvis ikke. En Access-Accept bærer autorisasjonshint, og bare den nettverkstilgangsserveren som mottok dem, kan gjøre ett av dem om til en nettverkstildeling.

Start ved gatewayen, ikke ved policyen

Gå gjennom kjeden fra klienten og innover før du endrer noe. Klienten ber gatewayen om en sesjon, gatewayen spør RADIUS om brukeren kan få en, og RADIUS svarer med et resultat og et sett attributter. Deretter bruker gatewayen det den vet hvordan den skal bruke.

Gjennomgangen din starter ved steg fire, og derfor ser de tre første sunne ut. Ingenting i utvekslingen forplikter gatewayen til å implementere et attributt den mottok. Svaret er en forespørsel til gatewayen, ikke et faktum om klienten.

Hva svitsjen gjør som VPN ikke kan

En 802.1X-tilgangssvitsj er en autentisator med porter, og dynamisk VLAN-tildeling flytter en av disse portene til et VLAN svitsjen allerede bærer. RADIUS-tunnelattributtene beskriver den intensjonen i en form svitsjen forstår. En rutet VPN avslutter tunneler, ikke svitsjporter, og klientene får vanligvis en adresse og en rute i stedet for medlemskap i et kringkastingsdomene. Det er ingen port å flytte, så det samme attributtet har ingenting å virke på.

Dette er en modellforskjell, ikke en leverandørfeil. Noen gatewayer legger til sin egen gruppepolicy, poolvalg eller filtermekanisme som ser lik ut på et skjermbilde. Andre implementerer ingenting av det, og attributtet logges og ignoreres. Les dokumentasjonen for den fjernaksessmodusen du faktisk aktiverte, ikke den på skjermbildet.

Les svaret serveren faktisk sendte

Bekreft hva RADIUS returnerte i stedet for hva policyeditoren viser. En testforespørsel med samme brukernavn og et kjent passord skriver ut svarattributtene i lesbar form, og det avgjør spørsmålet i ett steg.

radtest alice secret 10.0.0.10 0 testing123

Hvis VLAN-attributtene mangler i det svaret, må du først rette policytreffet. Hvis de er til stede, har serveren gjort sin del, og gapet er lenger ned.

Bevis først sesjonspolicyen, deretter rekkevidden

Se nå på sesjonen gatewayen bygde. Listen over aktive sesjoner viser poolen, den tildelte adressen og enhver gruppepolicy gatewayen festet, og det er det eneste beviset som betyr noe for håndhevingen. Sammenlign det med hva brukeren kan nå, ikke med hva policyen hadde til hensikt.

swanctl --list-sas

Test deretter én tillatt og én avvist ressurs fra klienten, fordi en adresse fra riktig pool ikke beviser isolasjon. Hvis gatewayen ikke har noen mekanisme for tildelingen du ønsker, lager flere kopier av attributtet ingen. En adresse fra forventet pool kan eksistere sammen med full tilgang til alle andre pooler. Velg en støttet policymekanisme eller endre nettverksdesignet med vilje.