Por qué una respuesta RADIUS de VLAN no hace nada por un usuario de VPN

Usted agrega el atributo VLAN a la política NPS, el usuario de VPN se conecta y el portátil sigue cayendo en el grupo predeterminado. El servidor RADIUS devuelve lo que usted pidió, lo que hace que el fallo parezca un problema de caché. Normalmente no lo es. Un Access-Accept lleva indicios de autorización, y solo el servidor de acceso a la red que los recibió puede convertir uno en una asignación de red.

Empiece por la pasarela, no por la política

Recorra la cadena desde el cliente hacia dentro antes de cambiar nada. El cliente pide una sesión a la pasarela, la pasarela pregunta a RADIUS si el usuario puede tener una, y RADIUS responde con un resultado y un conjunto de atributos. Después la pasarela aplica lo que sabe aplicar.

Su recorrido empieza en el cuarto paso, y por eso los tres primeros parecen sanos. Nada en el intercambio obliga a la pasarela a implementar un atributo que recibió. La respuesta es una petición a la pasarela, no un hecho sobre el cliente.

Lo que hace el conmutador y la VPN no puede

Un conmutador de acceso 802.1X es un autenticador con puertos, y la asignación dinámica de VLAN mueve uno de esos puertos a una VLAN que el conmutador ya transporta. Los atributos de túnel RADIUS describen esa intención en una forma que el conmutador entiende. Una VPN enrutada termina túneles, no puertos de conmutador, y sus clientes suelen recibir una dirección y una ruta en lugar de pertenencia a un dominio de difusión. No hay ningún puerto que mover, así que el mismo atributo no tiene nada sobre lo que actuar.

Esto es una diferencia de modelo, no un error del proveedor. Algunas pasarelas añaden su propia política de grupo, selección de grupo o mecanismo de filtrado que en una captura de pantalla parece similar. Otras no implementan nada de eso, y el atributo se registra y se ignora. Lea la documentación del modo de acceso remoto que realmente habilitó, no la de la captura de pantalla.

Lea la respuesta que el servidor envió realmente

Confirme qué devolvió RADIUS en lugar de qué muestra el editor de políticas. Una petición de prueba con el mismo nombre de usuario y una contraseña conocida imprime los atributos de respuesta en forma legible, lo que resuelve la cuestión en un paso.

radtest alice secret 10.0.0.10 0 testing123

Si los atributos VLAN faltan en esa respuesta, corrija primero la coincidencia de la política. Si están presentes, el servidor ha hecho su parte y el hueco está más abajo.

Demuestre primero la política de sesión y luego el alcance

Ahora mire la sesión que construyó la pasarela. La lista de sesiones activas muestra el grupo, la dirección asignada y cualquier política de grupo que la pasarela haya adjuntado, y esa es la única evidencia que importa para la aplicación. Compárela con lo que el usuario puede alcanzar, no con lo que pretendía la política.

swanctl --list-sas

Luego pruebe desde el cliente un recurso permitido y uno denegado, porque una dirección del grupo correcto no demuestra aislamiento. Si la pasarela no tiene ningún mecanismo para la asignación que usted quiere, más copias del atributo no crearán uno. Una dirección del grupo esperado puede coexistir con acceso completo a todos los demás grupos. Elija un mecanismo de política compatible o cambie el diseño de la red a propósito.