Pse një përdorues në distancë i ASA arrin nënsrrjetin por jo aplikacionin
Rrugët vërtetojnë se tuneli funksionon, jo se përdoruesi mund të hapë aplikacionin. Lexoni filtrin që mori sesioni, më pas provoni një lidhje të lejuar dhe një të refuzuar.
Përdoruesi juaj lidhet, merr një adresë, pingon një server në nënsrrjetin e aplikacionit dhe prapëseprapë nuk mund të hapë shërbimin mbi të. Ky kombinim është normal në një ASA, sepse një tunel i suksesshëm dhe një leje e përdorshme vendosen nga cilësime të ndryshme. Lista e tunelit të ndarë zgjodhi cilat destinacione hynë në tunel; një filtër VPN dhe rregullat e aksesit të vetë destinacionit vendosin çfarë mund të arrijë kërkesa e dekriptuar. Kaloni nëpër tre vendimet sipas radhës në vend që të zgjeroni listën e rrugëve derisa të ndryshojë diçka.
Tre vendime që ngatërrohen lehtë
Pranimi përgjigjet nëse përdoruesi mund ta ndërtojë tunelin fare: kredencialet, certifikata dhe çdo faktor i dytë. Zgjedhja e rrugës përgjigjet se cilat destinacione klienti i dërgon në atë tunel. Autorizimi përgjigjet nëse kërkesa e dekriptuar mund ta arrijë shërbimin. Vetëm e treta prodhon gabimin që raporton përdoruesi.
Një mënyrë e shpejtë për t'i dalluar është të pyesni çfarë do të prishte një ndryshim. Heqja e një rruge nga lista e ndarë ndalon trafikun drejt atij nënsrrjeti pa dhënë asgjë; shtimi i një ACE në filtrin VPN jep një destinacion pa ndryshuar atë që tunelon klienti.
| 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 |
Lexoni filtrin që sesioni mori në të vërtetë
Filloni nga sesioni aktiv dhe jo nga konfigurimi që mendoni se zbatohet. show vpn-sessiondb detail anyconnect printon politikën e grupit të caktuar dhe emrin e filtrit të lidhur me atë sesion. Nëse fusha është bosh, asnjë filtër nuk po zbaton asgjë dhe bllokimi vjen nga diku tjetër.
Më pas lexoni politikën që zotëron vlerën, duke përfshirë parazgjedhjet, sepse një filtër mund të trashëgohet në vend që të shkruhet atje ku po shikoni:
show run all group-policy <policy-name>
show run access-list <acl-name>
show run webvpn
Krahasoni emrin e filtrit në sesion me ACL-në që sapo redaktuam. Një ACL me emër të ngjashëm që përdoruesi nuk e ka marrë kurrë nuk mund të ndryshojë politikën e burimeve të atij sesioni, dhe kjo është arsyeja më e zakonshme pse një ndryshim që duket i saktë nuk ka efekt.
Përparësia shpjegon pjesën tjetër. Për cilësimin e filtrit, një regjistrim DAP ka përparësi ndaj atributeve të emrit të përdoruesit, dhe ato ndaj politikës së grupit. Kur një sesion tregon një filtër që nuk e prisnit, kërkoni një politikë DAP që përputhet me atë përdorues përpara se të prekni grupin.
Lista e ndarë dhe filtri janë fusha të veçanta
Në ASA 9.x politika e grupit mban split-tunnel-network-list dhe vpn-filter si cilësime të ndryshme, dhe udhëzuesi i politikave të grupit 9.22 i dokumenton ato veçmas pikërisht për këtë arsye. Lista e rrjetit është një shenjë rrugëtimi për klientin; filtri është një listë e kontrollit të aksesit e aplikuar në trafikun e dekriptuar.
Ky dallim ka rëndësi kur përdoruesi ka nevojë për një shërbim të vetëm HTTPS në një nënsrrjet. Vendosni nënsrrjetin në listën e ndarë që paketat të hyjnë në tunel, më pas lejoni vetëm atë shërbim në filtër. Zgjerimi i listës së rrugëve nuk autorizon asgjë, dhe zvogëlimi i saj nuk është mekanizëm zbatimi.
Kontrolloni nëse një ACL ndërfaqeje është edhe në rrugë
Trafiku i dekriptuar i aksesit në distancë nuk kalon gjithmonë përmes ACL-së së ndërfaqes së jashtme siç mendojnë njerëzit. Aty ku sysopt connection permit-vpn është aktivizuar, ASA zbaton anashkalimin e dokumentuar të VPN-së për atë trafik, ndërsa filtrat VPN të zbatueshëm vazhdojnë të vlejnë më pas. Kontrolloni cilësimin me show run all sysopt në vend që të arsyetoni nga diagrami i topologjisë.
Në çdo rast, muri i zjarrit i vetë hostit të destinacionit dhe autorizimi i aplikacionit mbeten në rrugë. Një rregull i ASA që lejon TCP 443 nuk e bën aplikacionin ta pranojë përdoruesin.
Prano ndryshimin edhe me një lidhje të refuzuar
Një provë e lejuar vetëm dëshmon shumë pak, sepse një tunel funksional prodhon të njëjtën paketë të parë pavarësisht nëse ekziston një filtër. Hapni shërbimin e synuar nga klienti, më pas provoni një destinacion që duhet të mbetet i mbyllur dhe konfirmoni se dështon për arsyen e duhur.
Shënoni katër fakte kur mbyllni tiketën: identitetin e pranuar, politikën dhe filtrin që sesioni mori në të vërtetë, destinacionet në listën e ndarë dhe burimin që përdoruesit iu lejua të arrinte. Këto katër shpjegojnë ku kontrollohet trafiku pa e kthyer listën e rrugëve në mur zjarri.
Nëse shërbimi vazhdon të refuzojë pasi filtri e lejon, kaloni te hosti: adresa e dëgjimit, muri i zjarrit i hostit dhe hartëzimi i vetë përdoruesve të aplikacionit. Tuneli bëri punën e vet në atë pikë, dhe ndryshimet e mëtejshme në ASA shtojnë vetëm rrezik.