A política de grupo de NPS non é a aplicación de recursos de VPN

Dous grupos, dous perfís de acceso, unha pasarela VPN e, ao final, ambos os grupos chegan aos mesmos servidores. A razón habitual non é unha política rota senón unha segunda metade ausente do deseño: NPS decide quen pode establecer unha sesión, e outra cousa debe decidir a que pode chegar esa sesión. Cando só existe a primeira metade, a autorización ten éxito para todos os que se autentican. A política fai o seu traballo e o deseño segue incompleto.

Unha política de rede que coincide cun grupo é evidencia sobre a admisión. Non é evidencia sobre os paquetes, e o oco entre ambas as afirmacións é onde ocorre a maior parte deste traballo.

Atope a política que realmente admitiu a sesión

NPS avalía políticas de rede ordenadas e gaña a primeira regra habilitada cuxas condicións coinciden. As condicións poden incluír a pertenza a un grupo de usuarios ou de equipos, o tipo de conexión, a hora e o estado do dispositivo. Por iso unha política ampla situada antes na lista admite unha conexión antes de que se considere sequera unha regra máis estreita máis abaixo. A orde non é un detalle da interface; a orde é a política.

Lea a lista en orde e identifique a que coincidiu, e despois anote que configuracións devolveu. O nome do grupo no editor non é o resultado; o resultado é a autorización que recibiu o servidor. Manteña separadas a autorización de usuario e a do dispositivo onde o despregamento use ambas, porque unha conta que pode abrir un túnel non é automaticamente unha conta que debería chegar a cada servizo interno.

A resposta RADIUS é unha instrución, non un filtro

Un atributo Filter-Id leva o nome dunha lista de filtros. Non entrega un conxunto portátil de regras de filtrado de paquetes que todos os receptores entendan, e enviar un nome que a pasarela nunca definiu non aplica absolutamente nada. A mesma precaución vale para os atributos VLAN: asignar unha sesión de túnel a unha VLAN non é, por si só, unha regra de acceso encamiñada para ese usuario.

Aquí é onde un deseño que parece completo no lado de NPS non fai nada en silencio. Confirme coa documentación do provedor da pasarela que atributos de autorización se admiten e que fai o receptor con cada un, en lugar de supor que un nome de atributo estándar implica un comportamento estándar.

Pon a aplicación onde pasa o tráfico

Unha pasarela que procesa os paquetes do usuario pode aplicar un filtro por sesión, asignar un grupo a unha política da pasarela ou darlle á sesión un enderezo dun conxunto segregado que a devasa trata de xeito distinto. Calquera desas opcións pode funcionar, e fallan de maneiras diferentes. Identifique que mecanismo admite a súa pasarela antes de escribir a política que o nomea. Despois anote que ocorre cunha sesión cando ese mecanismo falta, porque o silencio é o valor por defecto.

Describa o permiso previsto en catro partes: identidade de orixe ou grupo, destino, protocolo e porto. Engada as dependencias que o usuario necesita de verdade, como DNS ou un servizo de autenticación, ou a restrición romperá fluxos de inicio de sesión que ninguén pensou en probar. Escriba a regra contra a interface que realmente filtra, non contra a interface que casualmente está aberta no editor.

Teña en conta tamén a tradución de enderezos. Se unha devasa posterior ve un só enderezo de orixe traducido para cada usuario do túnel, non pode distinguir individuos só con ese enderezo, e unha regra escrita coma se puidese será inútil ou demasiado ampla.

Os perfís de cliente viven no lado non fiable

Un perfil VPN xestionado pode empurrar rutas, regras de túnel dividido ou filtros de aplicacións, e estes moldean como se comporta un dispositivo ben educado. Non son protección para o servizo, porque o cliente é a parte que intenta restrinxir. Quitar unha ruta nun perfil tampouco é autorización, xa que un cliente pode ter outro camiño cara ao mesmo destino.

Trate a configuración do cliente como comodidade e a da pasarela como control. Cando as dúas discrepan, a pasarela ten razón porque é a que ve os paquetes.

Acepte con dúas contas e despois rastrexar en orde

Cree dúas contas de proba correntes con permisos previstos distintos, estableza sesións novas e comprobe a política efectiva da pasarela para cada unha. Despois probe unha operación permitida inofensiva e un recurso denegado especificamente. Un ping fallido demostra moi pouco por si só, xa que ICMP pode estar filtrado mentres o servizo TCP detrás responde tranquilamente.

Cando ambas as contas seguen obtendo acceso amplo, rastree nunha orde fixa: que política coincidiu, que autorización levaba a resposta e que fixo a pasarela con ela. Engadir máis atributos NPS antes de confirmar que o receptor os implementa é a forma en que un pequeno problema de autorización se converte nunha xanela de cambios sen resultado.