Varför ett RADIUS-VLAN-svar inte gör något för en VPN-användare

Du lägger till VLAN-attributet i NPS-policyn, VPN-användaren ansluter och den bärbara datorn hamnar fortfarande i standardpoolen. RADIUS-servern returnerar det du bad om, vilket får felet att se ut som ett cacheproblem. Vanligtvis är det inte det. Ett Access-Accept bär auktoriseringstips, och bara den nätverksåtkomstserver som tog emot dem kan göra ett av dem till en nätverkstilldelning.

Börja vid gatewayen, inte vid policyn

Följ kedjan från klienten och inåt innan du ändrar något. Klienten ber gatewayen om en session, gatewayen frågar RADIUS om användaren får ha en, och RADIUS svarar med ett resultat och en uppsättning attribut. Därefter tillämpar gatewayen det den vet hur den ska tillämpa.

Din genomgång börjar vid steg fyra, och därför ser de tre första sunda ut. Ingenting i utbytet tvingar gatewayen att implementera ett attribut den tog emot. Svaret är en begäran till gatewayen, inte ett faktum om klienten.

Vad switchen gör som VPN inte kan

En 802.1X-åtkomstswitch är en autentiserare med portar, och dynamisk VLAN-tilldelning flyttar en av dessa portar till ett VLAN som switchen redan bär. RADIUS-tunnelattributen beskriver den avsikten i en form som switchen förstår. En routad VPN avslutar tunnlar, inte switchportar, och dess klienter får vanligtvis en adress och en rutt i stället för medlemskap i en broadcastdomän. Det finns ingen port att flytta, så samma attribut har ingenting att verka på.

Detta är en modellskillnad, inte ett leverantörsfel. Vissa gatewayer lägger till sin egen grupprincip, poolval eller en filtermekanism som ser likadan ut på en skärmbild. Andra implementerar ingenting av det, och attributet loggas och ignoreras. Läs dokumentationen för det fjärråtkomstläge du faktiskt aktiverade, inte det på skärmbilden.

Läs svaret som servern faktiskt skickade

Bekräfta vad RADIUS returnerade i stället för vad principeditorn visar. En testbegäran med samma användarnamn och ett känt lösenord skriver ut svarsattributen i läsbar form, och det avgör frågan i ett steg.

radtest alice secret 10.0.0.10 0 testing123

Om VLAN-attributen saknas i det svaret, rätta först policymatchningen. Om de finns där har servern gjort sin del, och gapet ligger längre ned.

Bevisa först sessionspolicyn, sedan nåbarheten

Titta nu på sessionen som gatewayen byggde. Listan över aktiva sessioner visar poolen, den tilldelade adressen och alla grupprinciper gatewayen bifogade, och det är det enda bevis som spelar roll för efterlevnaden. Jämför det med vad användaren kan nå, inte med vad policyn avsåg.

swanctl --list-sas

Testa sedan en tillåten och en nekad resurs från klienten, eftersom en adress från rätt pool inte bevisar isolering. Om gatewayen inte har någon mekanism för den tilldelning du vill ha, skapar fler kopior av attributet ingen. En adress från förväntad pool kan samexistera med full åtkomst till alla andra pooler. Välj en stödd policymekanism eller ändra nätverksdesignen med avsikt.