A política de grupo do NPS não é a aplicação de recursos de VPN

Dois grupos, dois perfis de acesso, uma gateway VPN e, no fim, os dois grupos chegam aos mesmos servidores. O motivo habitual não é uma política quebrada, mas uma segunda metade ausente do desenho: o NPS decide quem pode estabelecer uma sessão, e outra coisa precisa decidir aonde essa sessão pode chegar. Quando só existe a primeira metade, a autorização é bem-sucedida para todos que se autenticam. A política faz o seu trabalho, e o desenho continua incompleto.

Uma política de rede que corresponde a um grupo é evidência sobre a admissão. Não é evidência sobre pacotes, e a lacuna entre essas duas afirmações é onde ocorre a maior parte deste trabalho.

Encontre a política que realmente admitiu a sessão

O NPS avalia políticas de rede ordenadas, e vence a primeira regra habilitada cujas condições correspondem. As condições podem incluir a associação a um grupo de usuários ou de computadores, o tipo de conexão, a hora e o estado do dispositivo. Por isso uma política ampla colocada antes na lista admite uma conexão antes que uma regra mais restrita mais abaixo seja sequer considerada. A ordem não é um detalhe da interface; a ordem é a política.

Leia a lista em ordem e identifique a que correspondeu, depois anote quais configurações ela retornou. O nome do grupo no editor não é o resultado; o resultado é a autorização que o servidor recebeu. Mantenha separadas a autorização de usuário e a de dispositivo onde a implantação usa as duas, porque uma conta que pode abrir um túnel não é automaticamente uma conta que deveria chegar a cada serviço interno.

A resposta RADIUS é uma instrução, não um filtro

Um atributo Filter-Id carrega o nome de uma lista de filtros. Ele não envia um conjunto portátil de regras de filtragem de pacotes que todo receptor entenda, e enviar um nome que a gateway nunca definiu não aplica absolutamente nada. O mesmo cuidado vale para os atributos VLAN: atribuir uma sessão de túnel a uma VLAN não é, por si só, uma regra de acesso roteada para aquele usuário.

É aqui que um desenho que parece completo do lado do NPS não faz nada, em silêncio. Confirme com a documentação do fornecedor da gateway quais atributos de autorização são suportados e o que o receptor faz com cada um, em vez de supor que um nome de atributo padrão implica comportamento padrão.

Coloque a aplicação onde o tráfego passa

Uma gateway que processa os pacotes do usuário pode aplicar um filtro por sessão, mapear um grupo para uma política da gateway ou dar à sessão um endereço de um conjunto segregado que o firewall trata de forma diferente. Qualquer uma dessas opções pode funcionar, e falham de maneiras diferentes. Identifique qual mecanismo a sua gateway suporta antes de escrever a política que o nomeia. Depois anote o que acontece com uma sessão quando esse mecanismo não existe, porque o silêncio é o padrão.

Descreva a permissão pretendida em quatro partes: identidade de origem ou grupo, destino, protocolo e porta. Acrescente as dependências de que o usuário realmente precisa, como DNS ou um serviço de autenticação, ou a restrição quebrará fluxos de login que ninguém pensou em testar. Escreva a regra contra a interface que realmente filtra, não contra a interface que por acaso está aberta no editor.

Considere também a tradução de endereços. Se um firewall a jusante vê um único endereço de origem traduzido para cada usuário do túnel, não consegue distinguir indivíduos apenas por esse endereço, e uma regra escrita como se conseguisse será inútil ou ampla demais.

Os perfis de cliente vivem no lado não confiável

Um perfil VPN gerenciado pode empurrar rotas, regras de túnel dividido ou filtros de aplicativos, e esses moldam como um dispositivo bem comportado se comporta. Não são proteção para o serviço, porque o cliente é a parte que você está tentando restringir. Remover uma rota de um perfil também não é autorização, já que um cliente pode ter outro caminho para o mesmo destino.

Trate as configurações do cliente como conveniência e as da gateway como controle. Quando as duas discordam, a gateway tem razão, porque é ela que vê os pacotes.

Aceite com duas contas e depois rastreie em ordem

Crie duas contas de teste comuns com permissões pretendidas diferentes, estabeleça sessões novas e verifique a política efetiva da gateway para cada uma. Depois teste uma operação permitida inofensiva e um recurso especificamente negado. Um ping que falha prova muito pouco sozinho, já que o ICMP pode estar filtrado enquanto o serviço TCP por trás responde tranquilamente.

Quando as duas contas ainda obtêm acesso amplo, rastreie numa ordem fixa: qual política correspondeu, qual autorização a resposta carregava e o que a gateway fez com ela. Acrescentar mais atributos do NPS antes de confirmar que o receptor os implementa é a forma como um pequeno problema de autorização se torna uma janela de mudanças sem resultado.