Por que unha resposta RADIUS de VLAN non fai nada por un usuario de VPN

Engade o atributo VLAN á política NPS, o usuario de VPN conéctase e o portátil segue caendo no grupo predeterminado. O servidor RADIUS devolve o que vostede pediu, o que fai que o fallo pareza un problema de caché. Normalmente non o é. Un Access-Accept leva indicios de autorización, e só o servidor de acceso á rede que os recibiu pode converter un nunha asignación de rede.

Empece pola pasarela, non pola política

Percorra a cadea desde o cliente cara a dentro antes de cambiar nada. O cliente pide unha sesión á pasarela, a pasarela pregunta a RADIUS se o usuario pode ter unha, e RADIUS responde cun resultado e un conxunto de atributos. Despois a pasarela aplica o que sabe aplicar.

O seu percorrido comeza no cuarto paso, e por iso os tres primeiros parecen sans. Nada no intercambio obriga a pasarela a implementar un atributo que recibiu. A resposta é unha petición á pasarela, non un feito sobre o cliente.

O que fai o conmutador e a VPN non pode

Un conmutador de acceso 802.1X é un autenticador con portos, e a asignación dinámica de VLAN move un deses portos a unha VLAN que o conmutador xa transporta. Os atributos de túnel RADIUS describen esa intención nunha forma que o conmutador entende. Unha VPN encamiñada termina túneles, non portos de conmutador, e os seus clientes adoitan recibir un enderezo e unha ruta en lugar de pertenza a un dominio de difusión. Non hai ningún porto que mover, así que o mesmo atributo non ten nada sobre o que actuar.

Isto é unha diferenza de modelo, non un erro do provedor. Algunhas pasarelas engaden a súa propia política de grupo, selección de grupo ou mecanismo de filtrado que nunha captura de pantalla parece similar. Outras non implementan nada diso, e o atributo rexístrase e ignórase. Lea a documentación do modo de acceso remoto que realmente activou, non a da captura de pantalla.

Lea a resposta que o servidor enviou realmente

Confirme que devolveu RADIUS en lugar do que mostra o editor de políticas. Unha petición de proba co mesmo nome de usuario e un contrasinal coñecido imprime os atributos de resposta en forma lexible, o que resolve a cuestión nun paso.

radtest alice secret 10.0.0.10 0 testing123

Se os atributos VLAN faltan nesa resposta, corrixa primeiro a coincidencia da política. Se están presentes, o servidor fixo a súa parte e o oco está máis abaixo.

Demostre primeiro a política de sesión e despois o alcance

Agora mire a sesión que construíu a pasarela. A lista de sesións activas mostra o grupo, o enderezo asignado e calquera política de grupo que a pasarela teña anexado, e esa é a única evidencia que importa para a aplicación. Compárea co que o usuario pode alcanzar, non co que pretendía a política.

swanctl --list-sas

Despois probe desde o cliente un recurso permitido e un denegado, porque un enderezo do grupo correcto non demostra illamento. Se a pasarela non ten ningún mecanismo para a asignación que vostede quere, máis copias do atributo non crearán un. Un enderezo do grupo esperado pode coexistir con acceso completo a todos os demais grupos. Escolla un mecanismo de política compatible ou cambie o deseño da rede a propósito.