Waarom ’n RADIUS-VLAN-antwoord niks vir ’n VPN-gebruiker doen
Die gateway, nie die RADIUS-beleid nie, bepaal wat ’n VLAN-kenmerk doen. Volg die sessieketting en lees wat die bediener werklik teruggegee het voordat jy wysig.
Jy voeg die VLAN-kenmerk by die NPS-beleid, die VPN-gebruiker koppel, en die skootrekenaar beland steeds in die verstekpoel. Die RADIUS-bediener gee terug wat jy gevra het, wat die fout soos ’n kasprobleem laat lyk. Dit is gewoonlik nie. ’n Access-Accept dra magtigingswenke, en net die netwerktoegangsbediener wat dit ontvang het, kan een in ’n netwerktoekenning verander.
Begin by die gateway, nie by die beleid nie
Stap die ketting van die kliënt inwaarts voordat jy enigiets verander. Die kliënt vra die gateway vir ’n sessie, die gateway vra RADIUS of die gebruiker een mag hê, en RADIUS antwoord met ’n resultaat en ’n stel kenmerke. Die gateway pas dan toe wat hy weet hoe om toe te pas.
Jou deurloop begin by stap vier, daarom lyk die eerste drie gesond. Niks in die uitruiling verplig die gateway om ’n kenmerk te implementeer wat hy ontvang het nie. Die antwoord is ’n versoek aan die gateway, nie ’n feit oor die kliënt nie.
Wat die skakelaar doen wat die VPN nie kan nie
’n 802.1X-toegangskakelaar is ’n authentiseerder met poorte, en dinamiese VLAN-toekenning skuif een van daardie poorte in ’n VLAN wat die skakelaar reeds dra. Die RADIUS-tonnelkenmerke beskryf daardie bedoeling in ’n vorm wat die skakelaar verstaan. ’n Gerouteerde VPN termineer tonnels, nie skakelaarpoorte nie, en sy kliënte kry gewoonlik ’n adres en ’n roete eerder as lidmaatskap van ’n uitsaaidomein. Daar is geen poort om te skuif nie, so dieselfde kenmerk het niks om op te reageer nie.
Dit is ’n modelverskil, nie ’n verskafferfout nie. Sommige gateways voeg hul eie groepsbeleid, poelkeuse of filtermeganisme by wat in ’n skermkiekie soortgelyk lyk. Ander implementeer niks daarvan nie, en die kenmerk word gelog en geïgnoreer. Lees die dokumentasie vir die afstandtoegangsmodus wat jy werklik geaktiveer het, nie die een in die skermkiekie nie.
Lees die antwoord wat die bediener werklik gestuur het
Bevestig wat RADIUS teruggegee het eerder as wat die beleidsredigeerder wys. ’n Toetsversoek met dieselfde gebruikersnaam en ’n bekende wagwoord druk die antwoordkenmerke in leesbare vorm, wat die vraag in een stap besleg.
radtest alice secret 10.0.0.10 0 testing123As die VLAN-kenmerke in daardie antwoord ontbreek, maak eers die beleidsooreenstemming reg. As hulle teenwoordig is, het die bediener sy deel gedoen en die leemte is stroomaf.
Bewys eers die sessiebeleid, dan die bereikbaarheid
Kyk nou na die sessie wat die gateway gebou het. Die lys aktiewe sessies wys die poel, die toegekende adres en enige groepsbeleid wat die gateway aangeheg het, wat die enigste bewyse is wat vir afdwinging saak maak. Vergelyk dit met wat die gebruiker kan bereik eerder as met wat die beleid bedoel het.
swanctl --list-sasToets dan een toegelate en een geweierde hulpbron vanaf die kliënt, want ’n adres uit die regte poel bewys nie isolasie nie. As die gateway geen meganisme het vir die toekenning wat jy wil hê nie, sal meer kopieë van die kenmerk nie een skep nie. ’n Adres uit die verwagte poel kan saam met volle toegang tot elke ander poel bestaan. Kies ’n ondersteunde beleidsmeganisme of verander die netwerkontwerp doelbewus.