Por que un usuario remoto de ASA chega á subrede pero non á aplicación
As rutas demostran que o túnel funciona, non que o usuario poida abrir a aplicación. Lea o filtro que recibiu a sesión e despois probe unha conexión permitida e outra denegada.
O seu usuario conéctase, obtén un enderezo, fai ping a un servidor na subrede da aplicación e aínda así non pode abrir o servizo nel. Esa combinación é normal nun ASA, porque un túnel correcto e un permiso utilizábel decídenos axustes distintos. A lista de túnel dividido escolleu que destinos entraron no túnel; un filtro VPN e as regras de acceso propias do destino deciden que pode acadar a solicitude descifrada. Percorra as tres decisións en orde en lugar de ampliar a lista de rutas ata que algo cambie.
Tres decisións fáciles de confundir
A admisión responde se o usuario pode establecer o túnel: credenciais, certificado e calquera segundo factor. A selección de ruta responde que destinos envía o cliente dentro dese túnel. A autorización responde se a solicitude descifrada pode acadar o servizo. Só a terceira produce o erro que notifica o usuario.
Unha forma rápida de distinguilas é preguntar que rompería un cambio. Quitar unha ruta da lista dividida detén o tráfico cara a esa subrede sen conceder nada; engadir unha ACE ao filtro VPN concede un destino sen cambiar o que o 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 o filtro que a sesión recibiu realmente
Comece pola sesión activa e non pola configuración que cre que se aplica. show vpn-sessiondb detail anyconnect mostra a política de grupo asignada e o nome do filtro asociado a esa sesión. Se o campo está baleiro, ningún filtro impón nada e o bloqueo vén doutro sitio.
Despois lea a política que posúe o valor, incluídos os valores predeterminados, porque un filtro pode herdarse en lugar de estar escrito onde mira:
show run all group-policy <policy-name>
show run access-list <acl-name>
show run webvpn
Compare o nome do filtro da sesión coa ACL que acaba de editar. Unha ACL de nome semellante que o usuario nunca recibiu non pode cambiar a política de recursos desa sesión, e esta é a razón máis habitual de que un cambio que parece correcto non teña efecto.
A precedencia explica o resto. Para o axuste do filtro, un rexistro DAP ten prioridade sobre os atributos de nome de usuario, e estes teñen prioridade sobre a política de grupo. Cando unha sesión mostra un filtro que non esperaba, busque unha política DAP que coincida con ese usuario antes de tocar o grupo.
A lista dividida e o filtro son campos separados
En ASA 9.x a política de grupo contén split-tunnel-network-list e vpn-filter como axustes distintos, e a guía de políticas de grupo 9.22 documéntaos por separado precisamente por iso. A lista de redes é unha indicación de encamiñamento para o cliente; o filtro é unha lista de control de acceso aplicada ao tráfico descifrado.
Esa distinción importa cando o usuario necesita un só servizo HTTPS nunha subrede. Poña a subrede na lista dividida para que os paquetes entren no túnel e logo permita só ese servizo no filtro. Ampliar a lista de rutas non autoriza nada, e reducila non é un mecanismo de aplicación.
Comprobe se unha ACL de interface está sequera no camiño
O tráfico descifrado de acceso remoto non sempre atravesa a ACL da interface exterior como a xente supón. Onde sysopt connection permit-vpn está activado, o ASA aplica a súa omisión de VPN documentada para ese tráfico, mentres que os filtros VPN aplicábeis seguen aplicándose despois. Comprobe o axuste con show run all sysopt en lugar de razoar a partir do diagrama de topoloxía.
En calquera caso, a devasa propia do host de destino e a autorización da aplicación seguen no camiño. Unha regra de ASA que permite TCP 443 non fai que a aplicación acepte o usuario.
Acepte o cambio tamén cunha conexión denegada
Unha proba permitida por si soa demostra moi pouco, porque un túnel que funciona produce o mesmo primeiro paquete exista ou non un filtro. Abra o servizo previsto desde o cliente, despois intente un destino que deba permanecer pechado e confirme que falla polo motivo correcto.
Anote catro feitos ao pechar o tícket: a identidade admitida, a política e o filtro que a sesión recibiu realmente, os destinos da lista dividida e o recurso ao que o usuario tiña permiso de chegar. Eses catro explican onde se controla o tráfico sen converter unha lista de rutas nunha devasa.
Se o servizo segue rexeitando despois de que o filtro o permita, pase ao host: enderezo de escoita, devasa do host e a asignación de usuarios propia da aplicación. Nese punto o túnel fixo o seu traballo, e máis cambios no ASA só engaden risco.