Por que uma resposta RADIUS de VLAN não faz nada por um usuário de VPN

Você adiciona o atributo VLAN à política NPS, o usuário de VPN se conecta e o notebook ainda cai no pool padrão. O servidor RADIUS retorna o que você pediu, o que faz a falha parecer um problema de cache. Normalmente não é. Um Access-Accept carrega indicações de autorização, e apenas o servidor de acesso à rede que as recebeu pode transformar uma delas em uma atribuição de rede.

Comece pelo gateway, não pela política

Percorra a cadeia do cliente para dentro antes de mudar qualquer coisa. O cliente pede uma sessão ao gateway, o gateway pergunta ao RADIUS se o usuário pode ter uma, e o RADIUS responde com um resultado e um conjunto de atributos. Depois o gateway aplica o que sabe aplicar.

Sua verificação começa no quarto passo, e é por isso que os três primeiros parecem saudáveis. Nada na troca obriga o gateway a implementar um atributo que recebeu. A resposta é um pedido ao gateway, não um fato sobre o cliente.

O que o switch faz e a VPN não pode

Um switch de acesso 802.1X é um autenticador com portas, e a atribuição dinâmica de VLAN move uma dessas portas para uma VLAN que o switch já transporta. Os atributos de túnel RADIUS descrevem essa intenção em um formato que o switch entende. Uma VPN roteada termina túneis, não portas de switch, e seus clientes geralmente recebem um endereço e uma rota em vez de participação em um domínio de broadcast. Não há porta a mover, então o mesmo atributo não tem sobre o que agir.

Isto é uma diferença de modelo, não um bug do fornecedor. Alguns gateways adicionam sua própria política de grupo, seleção de pool ou mecanismo de filtro que parece semelhante em uma captura de tela. Outros não implementam nada disso, e o atributo é registrado e ignorado. Leia a documentação do modo de acesso remoto que você realmente ativou, não a da captura de tela.

Leia a resposta que o servidor realmente enviou

Confirme o que o RADIUS retornou em vez do que o editor de políticas exibe. Uma requisição de teste com o mesmo nome de usuário e uma senha conhecida imprime os atributos de resposta em formato legível, e isso resolve a questão em um passo.

radtest alice secret 10.0.0.10 0 testing123

Se os atributos VLAN estiverem ausentes nessa resposta, corrija primeiro a correspondência da política. Se estiverem presentes, o servidor fez sua parte e a lacuna está mais adiante.

Prove primeiro a política de sessão, depois o alcance

Agora olhe a sessão que o gateway construiu. A lista de sessões ativas mostra o pool, o endereço atribuído e qualquer política de grupo anexada pelo gateway, e essa é a única evidência que importa para a aplicação. Compare com o que o usuário consegue alcançar, não com o que a política pretendia.

swanctl --list-sas

Depois teste do cliente um recurso permitido e um negado, porque um endereço do pool correto não prova isolamento. Se o gateway não tem mecanismo para a atribuição que você quer, mais cópias do atributo não criarão um. Um endereço do pool esperado pode coexistir com acesso total a todos os outros pools. Escolha um mecanismo de política suportado ou mude o desenho da rede de propósito.