Por qué un usuario remoto de ASA llega a la subred pero no a la aplicación
Las rutas demuestran que el túnel funciona, no que el usuario pueda abrir la aplicación. Lea el filtro que recibió la sesión y después pruebe una conexión permitida y otra denegada.
Su usuario se conecta, obtiene una dirección, hace ping a un servidor de la subred de la aplicación y aun así no puede abrir el servicio en él. Esa combinación es normal en un ASA, porque un túnel correcto y un permiso utilizable los deciden ajustes distintos. La lista de túnel dividido eligió qué destinos entraban en el túnel; un filtro VPN y las reglas de acceso propias del destino deciden qué puede alcanzar la solicitud descifrada. Recorra las tres decisiones en orden en lugar de ampliar la lista de rutas hasta que algo cambie.
Tres decisiones fáciles de confundir
La admisión responde si el usuario puede establecer el túnel: credenciales, certificado y cualquier segundo factor. La selección de ruta responde qué destinos envía el cliente dentro de ese túnel. La autorización responde si la solicitud descifrada puede alcanzar el servicio. Solo la tercera produce el error que notifica el usuario.
Una forma rápida de distinguirlas es preguntar qué rompería un cambio. Quitar una ruta de la lista dividida detiene el tráfico hacia esa subred sin conceder nada; añadir una ACE al filtro VPN concede un destino sin cambiar lo que el cliente tuneliza.
| Setting | What it decides | Symptom when it is wrong |
|---|---|---|
| Connection profile and authentication | Whether the tunnel is built | Login fails, no address assigned |
| Split-tunnel network list | Which destinations the client routes into the tunnel | Subnet unreachable from the client, everything else fine |
| VPN filter (ACL) | Which decrypted flows are permitted | Tunnel up, ping may work, TCP service refused or dropped |
Lea el filtro que la sesión recibió realmente
Empiece por la sesión activa y no por la configuración que cree que se aplica. show vpn-sessiondb detail anyconnect muestra la política de grupo asignada y el nombre del filtro asociado a esa sesión. Si el campo está vacío, ningún filtro impone nada y el bloqueo viene de otro sitio.
Después lea la política que posee el valor, incluidos los valores predeterminados, porque un filtro puede heredarse en lugar de estar escrito donde mira:
show run all group-policy <policy-name>
show run access-list <acl-name>
show run webvpn
Compare el nombre del filtro de la sesión con la ACL que acaba de editar. Una ACL de nombre parecido que el usuario nunca recibió no puede cambiar la política de recursos de esa sesión, y esta es la razón más habitual por la que un cambio que parece correcto no tiene efecto.
La precedencia explica el resto. Para el ajuste del filtro, un registro DAP tiene prioridad sobre los atributos de nombre de usuario, y estos tienen prioridad sobre la política de grupo. Cuando una sesión muestra un filtro que no esperaba, busque una política DAP que coincida con ese usuario antes de tocar el grupo.
La lista dividida y el filtro son campos separados
En ASA 9.x la política de grupo contiene split-tunnel-network-list y vpn-filter como ajustes distintos, y la guía de políticas de grupo 9.22 los documenta por separado precisamente por eso. La lista de redes es una indicación de enrutamiento para el cliente; el filtro es una lista de control de acceso aplicada al tráfico descifrado.
Esa distinción importa cuando el usuario necesita un solo servicio HTTPS en una subred. Ponga la subred en la lista dividida para que los paquetes entren en el túnel y luego permita solo ese servicio en el filtro. Ampliar la lista de rutas no autoriza nada, y reducirla no es un mecanismo de aplicación.
Compruebe si una ACL de interfaz está siquiera en el camino
El tráfico descifrado de acceso remoto no siempre atraviesa la ACL de la interfaz exterior como la gente supone. Donde sysopt connection permit-vpn está activado, el ASA aplica su omisión de VPN documentada para ese tráfico, mientras que los filtros VPN aplicables siguen aplicándose después. Compruebe el ajuste con show run all sysopt en lugar de razonar a partir del diagrama de topología.
En cualquier caso, el cortafuegos propio del host de destino y la autorización de la aplicación siguen en el camino. Una regla de ASA que permite TCP 443 no hace que la aplicación acepte al usuario.
Acepte el cambio también con una conexión denegada
Una prueba permitida por sí sola demuestra muy poco, porque un túnel que funciona produce el mismo primer paquete exista o no un filtro. Abra el servicio previsto desde el cliente, después intente un destino que deba permanecer cerrado y confirme que falla por el motivo correcto.
Anote cuatro hechos al cerrar el tiquete: la identidad admitida, la política y el filtro que la sesión recibió realmente, los destinos de la lista dividida y el recurso al que el usuario tenía permiso de llegar. Esos cuatro explican dónde se controla el tráfico sin convertir una lista de rutas en un cortafuegos.
Si el servicio sigue rechazando después de que el filtro lo permita, pase al host: dirección de escucha, cortafuegos del host y la asignación de usuarios propia de la aplicación. En ese punto el túnel hizo su trabajo, y más cambios en el ASA solo añaden riesgo.