Sayt VPN orqali masofaviy ASA ga SSH: bosqichma-bosqich
Masofaviy ASA ga boshqaruv yo'li to'g'ri nishon interfeysini, tunnel orqali qaytish marshrutini, SSH ruxsatini va ACL ni talab qiladi. Har bir bosqichni sinab ko'ring.
SSH mijozini masofaviy ASA ning ichki manziliga yo'naltirasiz va sessiya ulanish paytida o'ladi. Firewall o'z saytidan javob beradi, tunnel ko'rinadi, ammo 22-portda hech narsa eshitilmaydi. Bu holatlarning ko'pchiligida paket boshqaruv qabuliga hech qachon yetib bormaydi, chunki tekshirilayotgan yo'l hech qachon boshqaruv yo'li sifatida loyihalanmagan. Quyidagi oqimni tartib bilan kuzatib boring va nosozlik joy almashishdan to'xtaydi.
Haqiqatan boshqarayotgan manzilni tanlang
Uch loyiha o'xshash ko'rinadi va turlicha harakat qiladi: ASA ning ommaviy VPN ga qaragan manziliga yetish, IPsec orqali ichki interfeysga yetish va alohida boshqaruv interfeysiga yetish. Har qanday ruxsatga tegishdan oldin administratorning manba manzilini, aniq nishon manzilini va TCP 22 ni yozib oling. Keyingi hamma narsa shu juftlikka bog'liq.
Ikki server VLAN ini tashiyotgan tunnel firewall interfeys manzilini yoki administratorning boshqaruv quyi tarmog'ini umuman tashimasligi mumkin. Sayt-sayt siyosati uchun qiziqarli trafik ro'yxatini tekshiring va ASA ning o'z manzili nishon sifatida ko'rinishini tasdiqlang, faqat undan o'tuvchi quyi tarmoqlar emas.
Nishon firewall ning o'zi bo'lgani uchun boshqaruv qabuli uzatiladigan trafik qoidalaridan ajratilgan. Mijozlarni ASA orqasidagi serverlarga yetkazadigan ACL qurilmaning SSH boshqaruvini o'z-o'zidan yoqmaydi va uzatish qoidasini tuzatish bu nosozlikni joyidan qo'zg'atmaydi.
management-access interfeysga xos
management-access buyrug'i ASA ga VPN orqali kelgan boshqaruv ulanishlarini nomlangan interfeysda qabul qilishni buyuradi. U marshrut yaratmaydi, SSH ruxsatini qo'shmaydi va bir vaqtning o'zida barcha interfeyslarga taalluqli emas. Agar nishon interfeys nomlangan interfeys bo'lmasa, ulanish autentifikatsiyadan oldin tashlab yuboriladi.
Bu yerda ikkita istisno qarshilik qiladi. Faqat boshqaruv uchun interfeyslar bu mexanizmdan tashqarida, va ASA 9.20 boshqaruv qo'llanmasi standart CiscoSSH steki VPN orqali interfeyslar orasidagi SSH ni qo'llab-quvvatlamasligini, ASA SSH steki esa qo'llab-quvvatlashini qayd etadi. Marshrutlarga vaqt sarflashdan oldin o'rnatilgan versiyada faol stekni tasdiqlang.
Kirish so'rovidan oldin to'rt darvoza
Mijoz va foydalanuvchi nomi so'rovi o'rtasida to'rtta mustaqil darvoza turadi: boshqaruv juftligi uchun marshrut va tunnel mosligi, ASA manziliga TCP 22 ga ruxsat beruvchi interfeys ACL, administrator manbasini qamrab oluvchi ssh ruxsati va o'sha foydalanuvchi uchun AAA autentifikatsiyasi. Har biri qaysi darvoza yopilganini mijozga aytmasdan paketni tashlashi mumkin.
Biror narsani o'zgartirishdan oldin qaysi darvoza muvaffaqiyatsiz ekanini ko'rish uchun packet-tracer dan foydalaning: packet-tracer input inside tcp 10.10.5.20 50000 10.20.1.1 22 detailed. Iz ACL, NAT bosqichi va to-the-box qarorini nomlaydi, bu odatda marshrutlash muammosini qabul muammosidan ajratish uchun yetarli.
Tor ruxsatni yozing, kengini emas
Ruxsatni tasdiqlangan ma'muriy quyi tarmoq va tunnel trafigini qabul qiluvchi interfeys bilan cheklang: ssh 10.10.5.0 255.255.255.0 inside. Uni tashqi interfeysda har bir manbani ochish o'rniga aaa authentication ssh console LOCAL kabi autentifikatsiya usuli va nomlangan mahalliy hisob bilan bog'lang.
Interfeys ACL va ssh ruxsatini izchil tuting. ACL bloklaydigan quyi tarmoq uchun ruxsat baribir muvaffaqiyatsiz bo'ladi, mos ssh yozuvi bo'lmagan quyi tarmoqqa ruxsat beruvchi ACL keyingi darvozada muvaffaqiyatsiz bo'ladi. Ikkala bayonot ham bir yo'lni turli qatlamlardan tasvirlaydi, shuning uchun ularni ishlab turgan konfiguratsiyada birga ko'rib chiqing.
Nomlangan xostdan tekshiring, keyin yana toraytiring
Yangi sessiyani o'z stolingizdan emas, nomlangan boshqaruv xostidan oching va ulanish qaysi manba manzili va interfeysdan foydalanganini ASA da tasdiqlang. Sessiya ochiq turganda faol sessiyalarni va ishlab turgan konfiguratsiyaning SSH bo'limini tekshiring, so'ng uni yopib, sinov uchun qo'shgan har qanday vaqtinchalik ruxsatni olib tashlang. Sessiya ko'rinib, lekin kirgandan so'ng darhol yiqilsa, qolgan muammo yetib borish emas, avtorizatsiya. Keyingi odam diagnostikani takrorlamasligi uchun interfeys va manbani o'zgarishlar jurnaliga yozing.
Butun o'zgarish davomida konsolni yoki mustaqil tasdiqlangan boshqa tiklash yo'lini mavjud tuting. Xususiy yo'l ishlagandan so'ng ommaviy manbalar va aloqasi yo'q VPN foydalanuvchilari bir xil ruxsat olmaganini tasdiqlang, chunki hamma uchun ishlaydigan boshqaruv yo'li siz boshlagan muammodan boshqa muammo.