De ce un utilizator la distanță ASA ajunge în subrețea, dar nu la aplicație
Rutele dovedesc că tunelul funcționează, nu că utilizatorul poate deschide aplicația. Citiți filtrul primit de sesiune, apoi testați o conexiune permisă și una respinsă.
Utilizatorul dvs. se conectează, primește o adresă, face ping către un server din subrețeaua aplicației și tot nu poate deschide serviciul de pe el. Această combinație este normală pe un ASA, pentru că un tunel reușit și o permisiune utilizabilă sunt decise de setări diferite. Lista de tunel divizat a ales ce destinații au intrat în tunel; un filtru VPN și regulile de acces proprii ale destinației decid ce poate atinge cererea decriptată. Parcurgeți cele trei decizii în ordine în loc să lărgiți lista de rute până se schimbă ceva.
Trei decizii ușor de confundat
Admiterea răspunde dacă utilizatorul poate stabili tunelul: acreditări, certificat și orice al doilea factor. Selecția rutei răspunde ce destinații trimite clientul în acel tunel. Autorizarea răspunde dacă cererea decriptată poate atinge serviciul. Doar a treia produce eroarea pe care o raportează utilizatorul.
O modalitate rapidă de a le distinge este să întrebați ce ar strica o modificare. Scoaterea unei rute din lista divizată oprește traficul către acea subrețea fără a acorda nimic; adăugarea unui ACE la filtrul VPN acordă o destinație fără a schimba ce tunelează clientul.
| 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 |
Citiți filtrul pe care sesiunea l-a primit efectiv
Începeți de la sesiunea activă, nu de la configurația despre care credeți că se aplică. show vpn-sessiondb detail anyconnect afișează politica de grup atribuită și numele filtrului atașat acelei sesiuni. Dacă câmpul este gol, niciun filtru nu impune nimic, iar blocarea vine de altundeva.
Apoi citiți politica ce deține valoarea, inclusiv valorile implicite, pentru că un filtru poate fi moștenit în loc să fie scris acolo unde vă uitați:
show run all group-policy <policy-name>
show run access-list <acl-name>
show run webvpn
Comparați numele filtrului din sesiune cu ACL-ul pe care tocmai l-ați editat. Un ACL cu nume similar pe care utilizatorul nu l-a primit niciodată nu poate schimba politica de resurse a acelei sesiuni, și acesta este cel mai frecvent motiv pentru care o modificare aparent corectă nu are efect.
Precedența explică restul. Pentru setarea filtrului, o înregistrare DAP are prioritate față de atributele numelui de utilizator, iar acestea au prioritate față de politica de grup. Când o sesiune arată un filtru la care nu vă așteptați, căutați o politică DAP care corespunde acelui utilizator înainte de a atinge grupul.
Lista divizată și filtrul sunt câmpuri separate
Pe ASA 9.x politica de grup păstrează split-tunnel-network-list și vpn-filter ca setări diferite, iar ghidul de politici de grup 9.22 le documentează separat exact din acest motiv. Lista de rețele este un indiciu de rutare pentru client; filtrul este o listă de control al accesului aplicată traficului decriptat.
Această distincție contează când utilizatorul are nevoie de un singur serviciu HTTPS într-o subrețea. Puneți subrețeaua în lista divizată ca pachetele să intre în tunel, apoi permiteți în filtru doar acel serviciu. Lărgirea listei de rute nu autorizează nimic, iar restrângerea ei nu este un mecanism de impunere.
Verificați dacă un ACL de interfață este măcar pe traseu
Traficul decriptat de acces la distanță nu trece întotdeauna prin ACL-ul interfeței externe așa cum presupun oamenii. Acolo unde sysopt connection permit-vpn este activat, ASA aplică ocolirea VPN documentată pentru acel trafic, în timp ce filtrele VPN aplicabile se aplică în continuare după aceea. Verificați setarea cu show run all sysopt în loc să raționați din diagrama topologiei.
În orice caz, firewall-ul gazdei destinație și autorizarea aplicației rămân pe traseu. O regulă ASA care permite TCP 443 nu face aplicația să accepte utilizatorul.
Acceptați modificarea și cu o conexiune respinsă
Un singur test permis dovedește foarte puțin, pentru că un tunel funcțional produce același prim pachet indiferent dacă există un filtru. Deschideți serviciul dorit din client, apoi încercați o destinație care ar trebui să rămână închisă și confirmați că eșuează din motivul corect.
Notați patru fapte la închiderea tichetului: identitatea admisă, politica și filtrul primite efectiv de sesiune, destinațiile din lista divizată și resursa la care utilizatorul avea voie să ajungă. Aceste patru explică unde este controlat traficul fără a transforma o listă de rute într-un firewall.
Dacă serviciul încă refuză după ce filtrul îl permite, treceți la gazdă: adresa de ascultare, firewall-ul gazdei și maparea utilizatorilor proprie aplicației. Tunelul și-a făcut treaba în acel moment, iar modificările suplimentare pe ASA adaugă doar risc.