Bakit naaabot ng remote user ng ASA ang subnet pero hindi ang app
Pinapatunayan ng mga ruta na gumagana ang tunnel, hindi na pinapayagan ang user na buksan ang app. Basahin ang filter na natanggap ng session, pagkatapos subukan ang pinayagan at tinanggihang koneksyon.
Kumokonekta ang user mo, nakakakuha ng address, nagpi-ping sa server sa subnet ng app, at hindi pa rin mabuksan ang serbisyo rito. Normal ang kombinasyong iyon sa isang ASA, dahil matagumpay na tunnel at magagamit na pahintulot ay pinagpapasyahan ng magkaibang setting. Pinili ng split-tunnel list kung aling destinasyon ang pumasok sa tunnel; ang filter ng VPN at ang sariling access rule ng destinasyon ang nagpapasya kung ano ang maaabot ng decrypted na kahilingan. Dumaan sa tatlong desisyon nang sunud-sunod sa halip na palawakin ang listahan ng ruta hanggang may magbago.
Tatlong desisyong madaling malito
Sinasagot ng pagtanggap kung maaaring itayo ng user ang tunnel: kredensyal, sertipiko at anumang pangalawang salik. Sinasagot ng pagpili ng ruta kung aling destinasyon ang ipinapadala ng client sa tunnel na iyon. Sinasagot ng awtorisasyon kung maaabot ng decrypted na kahilingan ang serbisyo. Ang pangatlo lang ang lumilikha ng error na iniuulat ng user.
Ang mabilis na paraan para mapaghiwalay ang mga ito ay itanong kung ano ang masisira ng isang pagbabago. Ang pag-alis ng ruta sa split list ay humihinto sa trapiko patungo sa subnet na iyon nang walang ibinibigay; ang pagdaragdag ng ACE sa filter ng VPN ay nagbibigay ng destinasyon nang hindi binabago kung ano ang tinutunnel ng 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 |
Basahin ang filter na aktwal na natanggap ng session
Magsimula sa live na session at hindi sa configuration na inaakala mong gumagana. show vpn-sessiondb detail anyconnect ipinapakita ang itinalagang patakaran ng grupo at ang pangalan ng filter na nakakabit sa session na iyon. Kung walang laman ang field, walang filter na nagpapatupad ng anuman at ang pagharang ay nanggagaling sa ibang lugar.
Pagkatapos basahin ang patakarang nagmamay-ari ng halaga, kasama ang mga default, dahil ang filter ay maaaring manahin sa halip na nakasulat sa tinitignan mo:
show run all group-policy <policy-name>
show run access-list <acl-name>
show run webvpn
Ihambing ang pangalan ng filter sa session sa ACL na karara mo lang na-edit. Ang ACL na may katulad na pangalan na hindi natanggap ng user ay hindi mababago ang patakaran ng mapagkukunan ng session na iyon, at ito ang pinakakaraniwang dahilan kung bakit walang epekto ang pagbabagong mukhang tama.
Ipinapaliwanag ng prayoridad ang natitira. Para sa setting ng filter, ang DAP record ay mas mataas sa mga attribute ng username, at ang mga attribute ng username ay mas mataas sa patakaran ng grupo. Kapag may filter na ipinakita ang session na hindi mo inaasahan, maghanap ng DAP policy na tumutugma sa user na iyon bago hawakan ang grupo.
Magkaibang field ang split list at ang filter
Sa ASA 9.x, hawak ng patakaran ng grupo ang split-tunnel-network-list at vpn-filter bilang magkaibang setting, at ang gabay sa patakaran ng grupo 9.22 ay hiwalay na dokumentado ang mga ito dahil doon. Ang network list ay isang routing hint sa client; ang filter ay isang access control list na inilalapat sa decrypted na trapiko.
Mahalaga ang pagkakaibang iyon kapag kailangan ng user ng isang serbisyong HTTPS sa isang subnet. Ilagay ang subnet sa split list para pumasok ang mga packet sa tunnel, pagkatapos payagan lang ang serbisyong iyon sa filter. Ang pagpapalawak ng listahan ng ruta ay walang awtorisasyon, at ang pagpapaliit nito ay hindi mekanismo ng pagpapatupad.
Tingnan kung nasa landas ba ang isang interface ACL
Ang decrypted na trapiko ng remote access ay hindi laging dumadaan sa ACL ng panlabas na interface gaya ng inaakala ng mga tao. Saan sysopt connection permit-vpn ay naka-enable, inilalapat ng ASA ang nakadokumentong VPN bypass nito para sa trapikong iyon, habang ang mga applicable na filter ng VPN ay umiiral pa rin pagkatapos. Tingnan ang setting gamit ang show run all sysopt sa halip na mangatwiran mula sa topology diagram.
Alinman sa dalawa, nananatili sa landas ang sariling firewall ng destination host at ang awtorisasyon ng app. Ang panuntunan ng ASA na nagpapahintulot sa TCP 443 ay hindi nagiging dahilan para tanggapin ng app ang user.
Tanggapin ang pagbabago gamit din ang tinanggihang koneksyon
Ang pinayagang pagsubok lamang ay kakaunti ang pinapatunayan, dahil ang gumaganang tunnel ay gumagawa ng parehong unang packet may filter man o wala. Buksan ang inilaan na serbisyo mula sa client, pagkatapos subukan ang destinasyong dapat manatiling sarado at tiyakin na nabigo ito sa tamang dahilan.
Itala ang apat na katotohanan kapag isinasara ang ticket: ang tinanggap na pagkakakilanlan, ang patakaran at filter na aktwal na natanggap ng session, ang mga destinasyon sa split list, at ang mapagkukunang pinayagang maabot ng user. Ang apat na ito ay nagpapaliwanag kung saan kinokontrol ang trapiko nang hindi ginagawang firewall ang listahan ng ruta.
Kung patuloy na tumatanggi ang serbisyo pagkatapos payagan ng filter, lumipat sa host: listen address, firewall ng host at ang sariling user mapping ng app. Ginawa ng tunnel ang trabaho nito sa puntong iyon, at ang karagdagang pagbabago sa ASA ay nagdaragdag lang ng panganib.