Waarom een RADIUS-VLAN-antwoord niets doet voor een VPN-gebruiker

U voegt het VLAN-attribuut toe aan het NPS-beleid, de VPN-gebruiker maakt verbinding en de laptop belandt nog steeds in de standaardpool. De RADIUS-server geeft terug wat u hebt gevraagd, waardoor de storing op een cacheprobleem lijkt. Meestal is dat niet zo. Een Access-Accept draagt autorisatiehints, en alleen de netwerktoegangsserver die ze ontving, kan er één omzetten in een netwerktoewijzing.

Begin bij de gateway, niet bij het beleid

Loop de keten van de client naar binnen door voordat u iets wijzigt. De client vraagt de gateway om een sessie, de gateway vraagt RADIUS of de gebruiker er een mag krijgen, en RADIUS antwoordt met een resultaat en een reeks attributen. Daarna past de gateway toe wat zij weet toe te passen.

Uw doorloop begint bij stap vier, daarom zien de eerste drie er gezond uit. Niets in de uitwisseling verplicht de gateway een ontvangen attribuut te implementeren. Het antwoord is een verzoek aan de gateway, geen feit over de client.

Wat de switch doet en de VPN niet kan

Een 802.1X-toegangsswitch is een authenticator met poorten, en dynamische VLAN-toewijzing verplaatst een van die poorten naar een VLAN dat de switch al draagt. De RADIUS-tunnelattributen beschrijven die bedoeling in een vorm die de switch begrijpt. Een gerouteerde VPN beëindigt tunnels, niet switchpoorten, en de clients krijgen meestal een adres en een route in plaats van lidmaatschap van een broadcastdomein. Er is geen poort om te verplaatsen, dus hetzelfde attribuut heeft niets om op te werken.

Dit is een modelverschil, geen leveranciersfout. Sommige gateways voegen hun eigen groepsbeleid, poolselectie of filtermechanisme toe dat er op een schermafbeelding hetzelfde uitziet. Andere implementeren niets daarvan, en het attribuut wordt gelogd en genegeerd. Lees de documentatie voor de externe-toegangsmodus die u werkelijk hebt ingeschakeld, niet die op de schermafbeelding.

Lees het antwoord dat de server werkelijk stuurde

Bevestig wat RADIUS teruggaf in plaats van wat de beleidseditor toont. Een testverzoek met dezelfde gebruikersnaam en een bekend wachtwoord drukt de antwoordattributen af in leesbare vorm, en dat beslecht de vraag in één stap.

radtest alice secret 10.0.0.10 0 testing123

Als de VLAN-attributen in dat antwoord ontbreken, herstel dan eerst de beleidsmatch. Als ze aanwezig zijn, heeft de server zijn deel gedaan en zit de kloof stroomafwaarts.

Bewijs eerst het sessiebeleid, dan de bereikbaarheid

Kijk nu naar de sessie die de gateway heeft opgebouwd. De lijst met actieve sessies toont de pool, het toegewezen adres en elk groepsbeleid dat de gateway heeft gekoppeld, en dat is het enige bewijs dat voor handhaving telt. Vergelijk dat met wat de gebruiker kan bereiken, niet met wat het beleid bedoelde.

swanctl --list-sas

Test vervolgens vanaf de client één toegestane en één geweigerde bron, want een adres uit de juiste pool bewijst geen isolatie. Als de gateway geen mechanisme heeft voor de toewijzing die u wilt, maken meer kopieën van het attribuut er geen. Een adres uit de verwachte pool kan samengaan met volledige toegang tot elke andere pool. Kies een ondersteund beleidsmechanisme of wijzig het netwerkontwerp bewust.