Kodėl nuotolinis ASA naudotojas pasiekia potinklį, bet ne programėlę
Maršrutai įrodo, kad tunelis veikia, o ne tai, kad naudotojas gali atidaryti programėlę. Perskaitykite filtrą, kurį gavo sesija, tada išbandykite leistiną ir atmestą ryšį.
Jūsų naudotojas prisijungia, gauna adresą, pingina serverį programėlės potinkle ir vis tiek negali atidaryti jame esančios paslaugos. Šis derinys ASA įprastas, nes sėkmingą tunelį ir naudingą leidimą lemia skirtingi nustatymai. Padalyto tunelio sąrašas parinko, kurie tikslai pateko į tunelį; VPN filtras ir paties tikslo prieigos taisyklės lemia, ką gali pasiekti iššifruota užklausa. Peržiūrėkite tris sprendimus iš eilės, o ne plėskite maršrutų sąrašą, kol kažkas pasikeis.
Trys lengvai supainiojami sprendimai
Priėmimas atsako, ar naudotojas apskritai gali sukurti tunelį: prisijungimo duomenys, sertifikatas ir bet koks antrasis veiksnys. Maršruto parinkimas atsako, kuriuos tikslus klientas siunčia į tą tunelį. Autorizacija atsako, ar iššifruota užklausa gali pasiekti paslaugą. Tik trečiasis sukuria klaidą, apie kurią praneša naudotojas.
Greitas būdas juos atskirti – paklausti, ką sugadintų pakeitimas. Pašalinus maršrutą iš padalyto sąrašo, sustabdomas srautas į tą potinklį, bet nieko nesuteikiama; pridėjus ACE į VPN filtrą, suteikiamas tikslas nekeičiant to, ką klientas tuneliuoja.
| 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 |
Perskaitykite filtrą, kurį sesija iš tikrųjų gavo
Pradėkite nuo gyvos sesijos, o ne nuo konfigūracijos, kuri, jūsų manymu, galioja. show vpn-sessiondb detail anyconnect išspausdina priskirtą grupės politiką ir prie tos sesijos prijungto filtro pavadinimą. Jei laukas tuščias, joks filtras nieko nevykdo, o blokavimas ateina iš kitur.
Tada perskaitykite politiką, kuriai priklauso reikšmė, įskaitant numatytąsias reikšmes, nes filtras gali būti paveldėtas, o ne įrašytas ten, kur žiūrite:
show run all group-policy <policy-name>
show run access-list <acl-name>
show run webvpn
Palyginkite sesijos filtro pavadinimą su ACL, kurį ką tik redagavote. Panašiai pavadintas ACL, kurio naudotojas niekada negavo, negali pakeisti tos sesijos išteklių politikos, ir tai yra dažniausia priežastis, kodėl teisingai atrodantis pakeitimas neturi poveikio.
Pirmumas paaiškina likusią dalį. Filtro nustatymui DAP įrašas viršija naudotojo vardo atributus, o naudotojo vardo atributai viršija grupės politiką. Kai sesija rodo netikėtą filtrą, prieš liesdami grupę ieškokite to naudotojo atitinkančios DAP politikos.
Padalytas sąrašas ir filtras yra atskiri laukai
ASA 9.x grupės politika laiko split-tunnel-network-list ir vpn-filter kaip skirtingus nustatymus, o 9.22 grupės politikos vadovas juos dokumentuoja atskirai būtent todėl. Tinklo sąrašas yra maršrutizavimo užuomina klientui; filtras yra prieigos kontrolės sąrašas, taikomas iššifruotam srautui.
Šis skirtumas svarbus, kai naudotojui reikia vienos HTTPS paslaugos potinklyje. Įdėkite potinklį į padalytą sąrašą, kad paketai patektų į tunelį, tada filtre leiskite tik tą paslaugą. Maršrutų sąrašo plėtimas nieko neautorizuoja, o jo siaurinimas nėra vykdymo mechanizmas.
Patikrinkite, ar sąsajos ACL apskritai yra kelyje
Iššifruotas nuotolinės prieigos srautas ne visada eina per išorinės sąsajos ACL taip, kaip žmonės mano. Ten, kur sysopt connection permit-vpn įjungta, ASA taiko savo dokumentuotą VPN apėjimą tam srautui, o taikomi VPN filtrai galioja ir po to. Nustatymą patikrinkite su show run all sysopt, o ne spręskite iš topologijos schemos.
Bet kuriuo atveju paskirties hosto ugniasienė ir programėlės autorizacija lieka kelyje. ASA taisyklė, leidžianti TCP 443, nepriverčia programėlės priimti naudotojo.
Priimkite pakeitimą ir su atmestu ryšiu
Vien leistinas testas įrodo labai mažai, nes veikiantis tunelis sukuria tą patį pirmąjį paketą nepriklausomai nuo to, ar filtras yra. Atidarykite numatytą paslaugą iš kliento, tada pabandykite tikslą, kuris turėtų likti uždarytas, ir patvirtinkite, kad jis nepavyksta dėl teisingos priežasties.
Uždarydami bilietą užrašykite keturis faktus: priimtą tapatybę, politiką ir filtrą, kuriuos sesija iš tikrųjų gavo, tikslus padalytame sąraše ir išteklių, kurį naudotojui buvo leista pasiekti. Šie keturi paaiškina, kur kontroliuojamas srautas, nepaverčiant maršrutų sąrašo ugniasiene.
Jei paslauga vis tiek atmeta po to, kai filtras ją leidžia, pereikite prie hosto: klausymosi adresas, hosto ugniasienė ir pačios programėlės naudotojų susiejimas. Tada tunelis atliko savo darbą, o tolesni ASA pakeitimai tik prideda rizikos.