Per què un usuari remot d’ASA arriba a la subxarxa però no a l’aplicació
Les rutes demostren que el túnel funciona, no que l’usuari pugui obrir l’aplicació. Llegeixi el filtre que ha rebut la sessió i després provi una connexió permesa i una de denegada.
El seu usuari es connecta, obté una adreça, fa ping a un servidor de la subxarxa de l’aplicació i tot i així no pot obrir el servei que hi ha. Aquesta combinació és normal en un ASA, perquè un túnel correcte i un permís utilitzable es decideixen amb paràmetres diferents. La llista de túnel dividit va triar quines destinacions entraven al túnel; un filtre VPN i les regles d’accés pròpies de la destinació decideixen què pot arribar a la sol·licitud desxifrada. Recorri les tres decisions en ordre en lloc d’ampliar la llista de rutes fins que alguna cosa canviï.
Tres decisions fàcils de confondre
L’admissió respon si l’usuari pot establir el túnel: credencials, certificat i qualsevol segon factor. La selecció de ruta respon quines destinacions el client envia dins d’aquest túnel. L’autorització respon si la sol·licitud desxifrada pot arribar al servei. Només la tercera produeix l’error que l’usuari notifica.
Una manera ràpida de distingir-les és preguntar què trencaria un canvi. Treure una ruta de la llista dividida atura el trànsit cap a aquesta subxarxa sense concedir res; afegir una ACE al filtre VPN concedeix una destinació sense canviar què tunelitza el client.
| 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 |
Llegeixi el filtre que la sessió ha rebut realment
Comenci per la sessió activa i no per la configuració que creu que s’aplica. show vpn-sessiondb detail anyconnect mostra la política de grup assignada i el nom del filtre adjunt a aquesta sessió. Si el camp és buit, cap filtre no aplica res i el bloqueig ve d’un altre lloc.
Després llegeixi la política que posseeix el valor, inclosos els valors per defecte, perquè un filtre es pot heretar en lloc d’estar escrit on mira:
show run all group-policy <policy-name>
show run access-list <acl-name>
show run webvpn
Compari el nom del filtre de la sessió amb l’ACL que acaba d’editar. Una ACL amb un nom semblant que l’usuari no ha rebut mai no pot canviar la política de recursos d’aquesta sessió, i aquesta és la raó més habitual perquè un canvi aparentment correcte no tingui cap efecte.
La precedència explica la resta. Per al paràmetre del filtre, un registre DAP té més precedència que els atributs del nom d’usuari, i aquests tenen més precedència que la política de grup. Quan una sessió mostra un filtre que no esperava, busqui una política DAP que coincideixi amb aquest usuari abans de tocar el grup.
La llista dividida i el filtre són camps separats
A ASA 9.x la política de grup conté split-tunnel-network-list i vpn-filter com a paràmetres diferents, i la guia de polítiques de grup 9.22 els documenta per separat precisament per això. La llista de xarxes és un indici d’encaminament per al client; el filtre és una llista de control d’accés aplicada al trànsit desxifrat.
Aquesta distinció importa quan l’usuari necessita un sol servei HTTPS en una subxarxa. Posi la subxarxa a la llista dividida perquè els paquets entrin al túnel i després permeti només aquest servei al filtre. Ampliar la llista de rutes no autoritza res, i reduir-la no és cap mecanisme d’aplicació.
Comprovi si una ACL d’interfície és fins i tot al camí
El trànsit desxifrat d’accés remot no sempre travessa l’ACL de la interfície exterior tal com la gent suposa. Allà on sysopt connection permit-vpn està activat, l’ASA aplica el seu salt de VPN documentat per a aquest trànsit, mentre que els filtres VPN aplicables encara s’apliquen després. Comprovi el paràmetre amb show run all sysopt en lloc de raonar a partir del diagrama de topologia.
De qualsevol manera, el tallafoc propi de l’amfitrió de destinació i l’autorització de l’aplicació continuen al camí. Una regla d’ASA que permet TCP 443 no fa que l’aplicació accepti l’usuari.
Accepti el canvi també amb una connexió denegada
Una prova permesa sola demostra molt poc, perquè un túnel funcional produeix el mateix primer paquet tant si hi ha filtre com si no. Obri el servei previst des del client, després intenti una destinació que hauria de romandre tancada i confirmi que falla pel motiu correcte.
Anoti quatre fets quan tanqui el tiquet: la identitat admesa, la política i el filtre que la sessió ha rebut realment, les destinacions de la llista dividida i el recurs al qual l’usuari tenia permís d’arribar. Aquests quatre expliquen on es controla el trànsit sense convertir una llista de rutes en un tallafoc.
Si el servei encara rebutja després que el filtre el permeti, passi a l’amfitrió: adreça d’escolta, tallafoc de l’amfitrió i el mapatge d’usuaris propi de l’aplicació. En aquest punt el túnel ha fet la seva feina, i més canvis a l’ASA només afegeixen risc.