Por que um usuário remoto do ASA alcança a sub-rede mas não o aplicativo
Rotas provam que o túnel funciona, não que o usuário possa abrir o aplicativo. Leia o filtro que a sessão recebeu e depois teste uma conexão permitida e uma negada.
Seu usuário conecta, recebe um endereço, faz ping em um servidor na sub-rede do aplicativo e ainda assim não consegue abrir o serviço nele. Essa combinação é normal em um ASA, porque um túnel bem-sucedido e uma permissão utilizável são decididos por configurações diferentes. A lista de túnel dividido escolheu quais destinos entraram no túnel; um filtro VPN e as regras de acesso do próprio destino decidem o que a solicitação descriptografada pode alcançar. Percorra as três decisões em ordem em vez de ampliar a lista de rotas até algo mudar.
Três decisões fáceis de confundir
A admissão responde se o usuário pode estabelecer o túnel: credenciais, certificado e qualquer segundo fator. A seleção de rota responde quais destinos o cliente envia para esse túnel. A autorização responde se a solicitação descriptografada pode alcançar o serviço. Apenas a terceira produz o erro que o usuário relata.
Uma forma rápida de distingui-las é perguntar o que uma mudança quebraria. Remover uma rota da lista dividida interrompe o tráfego para essa sub-rede sem conceder nada; adicionar uma ACE ao filtro VPN concede um destino sem alterar 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 |
Leia o filtro que a sessão realmente recebeu
Comece pela sessão ativa e não pela configuração que você acha que se aplica. show vpn-sessiondb detail anyconnect imprime a política de grupo atribuída e o nome do filtro anexado a essa sessão. Se o campo estiver vazio, nenhum filtro está impondo nada e o bloqueio vem de outro lugar.
Depois leia a política que possui o valor, incluindo os padrões, porque um filtro pode ser herdado em vez de escrito onde você está olhando:
show run all group-policy <policy-name>
show run access-list <acl-name>
show run webvpn
Compare o nome do filtro na sessão com a ACL que você acabou de editar. Uma ACL de nome parecido que o usuário nunca recebeu não pode alterar a política de recursos dessa sessão, e essa é a razão mais comum para uma mudança que parece correta não ter efeito.
A precedência explica o restante. Para a configuração do filtro, um registro DAP tem precedência sobre atributos de nome de usuário, e os atributos de nome de usuário têm precedência sobre a política de grupo. Quando uma sessão mostra um filtro que você não esperava, procure uma política DAP correspondente a esse usuário antes de mexer no grupo.
A lista dividida e o filtro são campos separados
No ASA 9.x a política de grupo mantém split-tunnel-network-list e vpn-filter como configurações diferentes, e o guia de políticas de grupo 9.22 os documenta separadamente exatamente por isso. A lista de redes é uma dica de roteamento para o cliente; o filtro é uma lista de controle de acesso aplicada ao tráfego descriptografado.
Essa distinção importa quando o usuário precisa de um único serviço HTTPS em uma sub-rede. Coloque a sub-rede na lista dividida para que os pacotes entrem no túnel e depois permita apenas esse serviço no filtro. Ampliar a lista de rotas não autoriza nada, e reduzi-la não é um mecanismo de aplicação.
Verifique se uma ACL de interface está sequer no caminho
O tráfego descriptografado de acesso remoto nem sempre atravessa a ACL da interface externa como as pessoas supõem. Onde sysopt connection permit-vpn está habilitado, o ASA aplica sua omissão de VPN documentada para esse tráfego, enquanto os filtros VPN aplicáveis ainda valem depois. Verifique a configuração com show run all sysopt em vez de raciocinar a partir do diagrama de topologia.
De qualquer forma, o firewall do host de destino e a autorização do aplicativo permanecem no caminho. Uma regra do ASA que permite TCP 443 não faz o aplicativo aceitar o usuário.
Aceite a mudança também com uma conexão negada
Um teste permitido sozinho prova muito pouco, porque um túnel funcionando produz o mesmo primeiro pacote exista ou não um filtro. Abra o serviço pretendido a partir do cliente, depois tente um destino que deve permanecer fechado e confirme que falha pelo motivo certo.
Registre quatro fatos ao fechar o chamado: a identidade admitida, a política e o filtro que a sessão realmente recebeu, os destinos na lista dividida e o recurso que o usuário tinha permissão de alcançar. Esses quatro explicam onde o tráfego é controlado sem transformar uma lista de rotas em firewall.
Se o serviço ainda recusar depois que o filtro o permitir, passe ao host: endereço de escuta, firewall do host e o mapeamento de usuários do próprio aplicativo. Nesse ponto o túnel fez seu trabalho, e mais mudanças no ASA só acrescentam risco.