AWS Client VPN: kirish muvaffaqiyatli, lekin quyi tarmoqqa yetib bo‘lmaydi

Mijozingiz Connected deb ko‘rsatadi, sertifikat haqiqiy, intranet sahifasi esa baribir vaqt tugashi bilan yakunlanadi. Bu farq deyarli hech qachon autentifikatsiya emas. AWS Client VPN manzillarni kirishdan alohida avtorizatsiya qiladi va odatdagi ikki sabab: identifikatsiya provayderi yuborgan qiymatga mos kelmaydigan guruh qiymati va keng qoidani yengadigan aniqroq manzil qoidasi. Qayerga qarashni bilsangiz, ikkisi ham endpoint konfiguratsiyasida ko‘rinadi.

Kirish muvaffaqiyatli o‘tdi; qoida mos kelmadi

Autentifikatsiya foydalanuvchi kimligini javob beradi. Avtorizatsiya qoidalari bu identifikatsiya qaysi tarmoq prefikslariga yeta olishini javob beradi. Foydalanuvchi birinchisidan o‘tib, ikkinchisida muvaffaqiyatsiz bo‘lishi mumkin, mijoz esa har bir so‘rov vaqt tugashi bilan yakunlanar ekan, sizga faqat ochiq turgan ulanishni beradi.

Endpointda manzili muvaffaqiyatsiz bo‘layotgan manzilni o‘z ichiga olgan avtorizatsiya qoidasi borligini tasdiqlashdan boshlang. Mos qoida bo‘lmasa, ulanish to‘g‘ri ishlayapti; yetishmayotgani — siyosat.

Guruh qiymati aslida qayerdan keladi

Active Directory da access-group maydoni guruhning ko‘rsatiladigan nomini emas, SID ni saqlaydi. SAML federatsiyasida u sozlangan SAML guruh atributi haqiqatda olib yurgan guruh ID si yoki nomini saqlaydi. Qiymatni assertion yoki katalog so‘rovidan ko‘chiring, wiki sahifasidan emas.

IAM guruhi boshqa boshqaruv tekisligi. Client VPN endpointini boshqarish ruxsati IAM guruhini foydalanuvchining VPN guruhiga aylantirmaydi va IAM guruh nomini access-group maydoniga qo‘yish uni AD SID iga yoki SAML atribut qiymatiga aylantirmaydi.

Boshqa katalogdagi o‘xshash nomli guruh hech narsani isbotlamaydi. Endpointning autentifikatsiya usulini va o‘sha tizimdagi foydalanuvchi a’zoligini yoki assertionni tekshiring.

Eng uzun prefiks yutadi, 0.0.0.0/0 ham

Avtorizatsiya eng uzun prefiks mosligi bo‘yicha baholanadi, barcha manzillar qoidasi esa birinchi emas, oxirida baholanadi. Engineering uchun 10.46.0.0/16 qoidasini va hamma uchun 0.0.0.0/0 qoidasini qo‘shing, Engineeringdan tashqaridagi foydalanuvchi baribir keng qoida orqali 10.46.20.10 ga yeta olmaydi.

Aynan shu yerda tuzatish noto‘g‘ri ketishi mumkin. Tor qoidani o‘chirish foydalanuvchining ruxsatini qaytaradi va o‘sha quyi tarmoqni keng qoida qamrab olgan har bir identifikatsiyaga ham beradi. Biror narsani o‘chirishdan oldin guruh-tarmoq matritsasini tuzing va qaysi guruh qaysi diapazonga yetishi kerakligini yozib qo‘ying. Bu qoidalar faqat ruxsat beradi; keng ruxsatdan istisno kesib olish uchun rad etish yozuvi yo‘q.

O‘zgarishlar adolatli baholanishi uchun yangi ulanish ham kerak. Qoidalarni tahrirlagandan so‘ng mijozni qayta ulang, keyin yana sinab ko‘ring.

Avtorizatsiyani ma’lumot yo‘lidan ajrating

Mos keladigan qoida — marshrut emas. Endpointga bog‘langan quyi tarmoq va manzil uchun marshrutlar jadvali yozuvi kerak, maqsad resursning xavfsizlik guruhi trafikni qabul qilishi lozim. Qaytish trafigi va DNS ham ishlashi kerak.

Muvaffaqiyatli bo‘lishi kerak bo‘lgan foydalanuvchini va tashqarida qolishi kerak bo‘lgan foydalanuvchini sinang. Ikkisi ham kira oladi, lekin faqat biri quyi tarmoqqa yetadi va aynan shu farq sizga kerakli dalildir.

Agar IP manzil ishlab, xost nomi ishlamasa, avtorizatsiyaga tegishdan oldin resolverga qarang. Hech bir marshrut manzilni qamrab olmasa, bog‘lanishni yoki marshrutlar jadvalini tuzating. Paket kelib, xizmat uni rad etsa, keyingi bekat — o‘sha xizmat siyosati. Avtorizatsiya matritsasini barcha foydalanuvchilarga kengaytirish qaysi qatlam haqiqatda buzilganini yashiradi.

Chiptani yopishdan oldin identifikatsiya manbasini, aniq guruh qiymatini, manzil prefikslarini va trafikni olib yuruvchi marshrutni yozib qo‘ying. Bu yozuv keyingi ulangan, lekin ruxsat yo‘q degan xabarni yana bir taxmin bosqichi o‘rniga ikki daqiqalik taqqoslashga aylantiradi.