La política de grupo de NPS no es la aplicación de recursos de VPN

Dos grupos, dos perfiles de acceso, una puerta de enlace VPN y, al final, ambos grupos llegan a los mismos servidores. La razón habitual no es una política rota sino una segunda mitad ausente del diseño: NPS decide quién puede establecer una sesión, y otra cosa debe decidir a qué puede llegar esa sesión. Cuando solo existe la primera mitad, la autorización tiene éxito para todos los que se autentican. La política hace su trabajo y el diseño sigue incompleto.

Una política de red que coincide con un grupo es evidencia sobre la admisión. No es evidencia sobre los paquetes, y la brecha entre ambas afirmaciones es donde ocurre la mayor parte de este trabajo.

Encuentre la política que realmente admitió la sesión

NPS evalúa políticas de red ordenadas y gana la primera regla habilitada cuyas condiciones coincidan. Las condiciones pueden incluir la pertenencia a un grupo de usuarios o de equipos, el tipo de conexión, la hora y el estado del dispositivo. Por eso una política amplia situada antes en la lista admite una conexión antes de que se considere siquiera una regla más estrecha situada más abajo. El orden no es un detalle de la interfaz; el orden es la política.

Lea la lista en orden e identifique la que coincidió, y luego anote qué configuraciones devolvió. El nombre del grupo en el editor no es el resultado; el resultado es la autorización que recibió el servidor. Mantenga separadas la autorización de usuario y la de dispositivo donde el despliegue use ambas, porque una cuenta que puede abrir un túnel no es automáticamente una cuenta que debería llegar a cada servicio interno.

La respuesta RADIUS es una instrucción, no un filtro

Un atributo Filter-Id lleva el nombre de una lista de filtros. No entrega un conjunto portátil de reglas de filtrado de paquetes que todos los receptores entiendan, y enviar un nombre que la puerta de enlace nunca definió no aplica absolutamente nada. La misma precaución vale para los atributos VLAN: asignar una sesión de túnel a una VLAN no es, por sí solo, una regla de acceso enrutada para ese usuario.

Aquí es donde un diseño que parece completo en el lado de NPS no hace nada en silencio. Confirme con la documentación del proveedor de la puerta de enlace qué atributos de autorización se admiten y qué hace el receptor con cada uno, en lugar de suponer que un nombre de atributo estándar implica un comportamiento estándar.

Ponga la aplicación donde pasa el tráfico

Una puerta de enlace que procesa los paquetes del usuario puede aplicar un filtro por sesión, asignar un grupo a una política de la puerta de enlace o dar a la sesión una dirección de un conjunto segregado que el cortafuegos trata de forma distinta. Cualquiera de esas opciones puede funcionar, y fallan de maneras diferentes. Identifique qué mecanismo admite su puerta de enlace antes de escribir la política que lo nombra. Después anote qué ocurre con una sesión cuando ese mecanismo falta, porque el silencio es el valor predeterminado.

Describa el permiso previsto en cuatro partes: identidad de origen o grupo, destino, protocolo y puerto. Añada las dependencias que el usuario necesita de verdad, como DNS o un servicio de autenticación, o la restricción romperá flujos de inicio de sesión que nadie pensó en probar. Escriba la regla contra la interfaz que realmente filtra, no contra la interfaz que casualmente está abierta en el editor.

Tenga en cuenta también la traducción de direcciones. Si un cortafuegos posterior ve una sola dirección de origen traducida para cada usuario del túnel, no puede distinguir individuos solo con esa dirección, y una regla escrita como si pudiera será inútil o demasiado amplia.

Los perfiles de cliente viven en el lado no confiable

Un perfil de VPN administrado puede empujar rutas, reglas de túnel dividido o filtros de aplicaciones, y esos moldean cómo se comporta un dispositivo bien educado. No son protección para el servicio, porque el cliente es la parte que intenta restringir. Quitar una ruta en un perfil tampoco es autorización, ya que un cliente puede tener otro camino hacia el mismo destino.

Trate la configuración del cliente como comodidad y la de la puerta de enlace como control. Cuando ambas discrepan, la puerta de enlace tiene razón porque es la que ve los paquetes.

Acepte con dos cuentas y luego rastree en orden

Cree dos cuentas de prueba corrientes con permisos previstos distintos, establezca sesiones nuevas y compruebe la política efectiva de la puerta de enlace para cada una. Después pruebe una operación permitida inofensiva y un recurso denegado específicamente. Un ping fallido demuestra muy poco por sí solo, ya que ICMP puede estar filtrado mientras el servicio TCP detrás responde tranquilamente.

Cuando ambas cuentas siguen obteniendo acceso amplio, rastree en un orden fijo: qué política coincidió, qué autorización llevaba la respuesta y qué hizo la puerta de enlace con ella. Añadir más atributos de NPS antes de confirmar que el receptor los implementa es la forma en que un pequeño problema de autorización se convierte en una ventana de cambios sin resultado.