Nega ASA masofaviy foydalanuvchisi subnetworkga yetadi, lekin ilovaga yetmaydi
Marshrutlar tunnel ishlashini isbotlaydi, foydalanuvchi ilovani ochishi mumkinligini emas. Sessiya olgan filtrni o‘qing, so‘ng ruxsat etilgan va rad etilgan ulanishni sinab ko‘ring.
Sizning foydalanuvchingiz ulanadi, manzil oladi, ilova subnetidagi serverga ping yuboradi va baribir undagi xizmatni ocha olmaydi. Bu birikma ASA uchun odatiy, chunki muvaffaqiyatli tunnel va foydalanish mumkin bo‘lgan ruxsat turli sozlamalar bilan belgilanadi. Bo‘lingan tunnel ro‘yxati qaysi manzillar tunnelga kirishini tanladi; VPN filtri va manzilning o‘z kirish qoidalari shifri ochilgan so‘rov nimaga yetishi mumkinligini belgilaydi. Marshrutlar ro‘yxatini kengaytirish o‘rniga uchta qarorni tartib bilan ko‘rib chiqing, biror narsa o‘zgarmaguncha.
Chalg‘itish oson bo‘lgan uchta qaror
Kirish foydalanuvchi tunnelni umuman qurishi mumkinligini javob beradi: hisob ma’lumotlari, sertifikat va har qanday ikkinchi omil. Marshrut tanlovi klient qaysi manzillarni shu tunnelga yuborishini javob beradi. Avtorizatsiya shifri ochilgan so‘rov xizmatga yetishi mumkinligini javob beradi. Foydalanuvchi xabar qilayotgan xatoni faqat uchinchisi tug‘diradi.
Ularni ajratishning tez yo‘li — o‘zgarish nimani buzishini so‘rash. Bo‘lingan ro‘yxatdan marshrutni olib tashlash o‘sha subnetga trafikni to‘xtatadi, lekin hech narsa bermaydi; VPN filtriga ACE qo‘shish manzil beradi, lekin klient tunnelga nima joylashini o‘zgartirmaydi.
| 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 |
Sessiya haqiqatan olgan filtrni o‘qing
Amal qiladi deb o‘ylagan konfiguratsiyadan emas, jonli sessiyadan boshlang. show vpn-sessiondb detail anyconnect tayinlangan guruh siyosatini va shu sessiyaga bog‘langan filtr nomini chiqaradi. Agar maydon bo‘sh bo‘lsa, hech qanday filtr hech narsani amalga oshirmaydi va to‘siq boshqa joydan keladi.
Keyin qiymatga ega siyosatni, standart qiymatlar bilan birga o‘qing, chunki filtr siz qarayotgan joyda yozilmasdan meros bo‘lishi mumkin:
show run all group-policy <policy-name>
show run access-list <acl-name>
show run webvpn
Sessiyadagi filtr nomini hozir tahrirlagan ACL bilan solishtiring. Foydalanuvchi hech qachon olmagan o‘xshash nomli ACL bu sessiyaning resurs siyosatini o‘zgartira olmaydi, va to‘g‘ri ko‘rinadigan o‘zgarishning ta’siri bo‘lmasligining eng keng tarqalgan sababi shu.
Ustuvorlik qolganini tushuntiradi. Filtr sozlamasi uchun DAP yozuvi foydalanuvchi nomi atributlaridan ustun, foydalanuvchi nomi atributlari esa guruh siyosatidan ustun. Sessiya kutmagan filtrni ko‘rsatsa, guruhga tegishdan oldin shu foydalanuvchiga mos DAP siyosatini qidiring.
Bo‘lingan ro‘yxat va filtr alohida maydonlar
ASA 9.x da guruh siyosati split-tunnel-network-list va vpn-filter ni turli sozlamalar sifatida saqlaydi va 9.22 guruh siyosati qo‘llanmasi aynan shu sababdan ularni alohida hujjatlashtiradi. Tarmoq ro‘yxati klient uchun marshrutlash ishorasi; filtr shifri ochilgan trafikka qo‘llanadigan kirishni boshqarish ro‘yxati.
Bu farq foydalanuvchiga subnetda bitta HTTPS xizmati kerak bo‘lganda muhim. Paketlar tunnelga kirishi uchun subnetni bo‘lingan ro‘yxatga qo‘ying, keyin filtrda faqat shu xizmatga ruxsat bering. Marshrutlar ro‘yxatini kengaytirish hech narsani avtorizatsiya qilmaydi, toraytirish esa ijro mexanizmi emas.
Interfeys ACL umuman yo‘lda ekanligini tekshiring
Shifri ochilgan masofaviy kirish trafigi odamlar o‘ylaganday har doim tashqi interfeys ACL orqali o‘tmaydi. sysopt connection permit-vpn yoqilgan joyda ASA shu trafik uchun o‘zining hujjatlashtirilgan VPN chetlanishini qo‘llaydi, amaldagi VPN filtrlari esa keyin ham amal qiladi. Sozlamani topologiya chizmasidan fikr yuritish o‘rniga show run all sysopt bilan tekshiring.
Qanday bo‘lmasin, manzil hostining o‘z xavfsizlik devori va ilovaning avtorizatsiyasi yo‘lda qoladi. TCP 443 ga ruxsat beradigan ASA qoidasi ilovani foydalanuvchini qabul qilishga majburlamaydi.
O‘zgarishni rad etilgan ulanish bilan ham qabul qiling
Faqat ruxsat etilgan sinov juda oz narsani isbotlaydi, chunki ishlaydigan tunnel filtr bo‘lishi yoki bo‘lmasligidan qat’i nazar bir xil birinchi paketni hosil qiladi. Klientdan mo‘ljallangan xizmatni oching, keyin yopiq qolishi kerak bo‘lgan manzilni sinab ko‘ring va u to‘g‘ri sabab bilan muvaffaqiyatsiz bo‘lishini tasdiqlang.
Tiketni yopayotganda to‘rtta faktni yozib oling: qabul qilingan shaxs, sessiya haqiqatan olgan siyosat va filtr, bo‘lingan ro‘yxatdagi manzillar va foydalanuvchiga yetish ruxsat berilgan resurs. Bu to‘rttasi marshrutlar ro‘yxatini xavfsizlik devoriga aylantirmasdan trafik qayerda nazorat qilinishini tushuntiradi.
Filtr ruxsat berganidan keyin ham xizmat rad etsa, hostga o‘ting: tinglash manzili, host xavfsizlik devori va ilovaning o‘z foydalanuvchi xaritasi. O‘sha paytda tunnel o‘z ishini qildi va ASA dagi keyingi o‘zgarishlar faqat xavf qo‘shadi.