VPN kirishi RADIUS va sizning identifikatsiya provayderingizga qanday yetib boradi

O'tgan hafta foydalanuvchi VPN ga kira oldi va baribir hech narsa hal bo'lmaydigan tarmoqqa tushdi. Mijoz ulangan dedi, shlyuz jurnali Access-Accept dedi, identifikatsiya jamoasi esa hisob yaxshi ekanini aytdi. Kirish ishlagan; uning orqasidagi avtorizatsiya ishlamagan. VPN kirishi muvaffaqiyatsiz bo'lganda, men so'rov haqiqatda bosib o'tadigan yo'lni bosib o'taman — mijoz, shlyuz, RADIUS serveri, identifikatsiya provayderi — va javobi keyingisiga to'g'ri kelmaydigan birinchi qadamda to'xtayman.

Mijoz hech qachon RADIUS tilida gapirmaydi

Noutbukdagi ilova nima ko'rsatsa ham, uning birinchi qadami VPN protokoli: IKEv2, OpenVPN, WireGuard yoki TLS asosidagi mijoz. RADIUS bu almashinuvda ko'rinmaydi. Mijoz shlyuzda sertifikat, foydalanuvchi nomi va parol yoki tunnel sozlamasida olib o'tiladigan EAP usuli bilan autentifikatsiyadan o'tadi.

Jurnallarni o'qishda bu muhim, chunki foydalanuvchi ko'radigan umumiy autentifikatsiya xatosini shlyuz allaqachon boshqa narsa bilan gaplashgandan keyin yaratadi. Agar mijoz shlyuzga hech qachon yetib bormasa, disk raskadrovka qilish uchun RADIUS so'rovi yo'q va RADIUS serverida o'tkazilgan bir soat behuda ketadi. Backendga tegishdan oldin tunnel umuman ko'tarilganini tasdiqlang.

Shlyuz RADIUS mijozi

Tunnel sozlamasi hisob ma'lumotlarini tekshirish kerak bo'lgan nuqtaga yetganda, shlyuz tarmoq kirish serveriga aylanadi. U Access-Request quradi: User-Name, parol yoki EAP yuki, NAS-IP-Address yoki NAS-Identifier, va usul talab qilganda Message-Authenticator. So'rov sukut bo'yicha UDP 1812 ga, hisob esa 1813 ga ketadi. Eski joylashtirishlar hali ham 1645 va 1646 dan foydalanadi, shuning uchun bir juftlik uchun yozilgan firewall qoidasi ko'plab jim muvaffaqiyatsizliklarni tushuntiradi.

Ikki tomon sirni baham ko'radi va bu foydalanuvchi hisob ma'lumoti emas. U almashinuvga imzo chekadi va har bir javob unga qarshi tekshiriladi. Sirni ikki tomonda turlicha sozlang, server yomon sir deb javob bermaydi — so'rovni tashlab yuboradi yoki javob tekshiruvdan o'tmaydi, shuning uchun shlyuz vaqt tugaganini bildiradi. Noto'g'ri sir va o'lik server shlyuzdan bir xil ko'rinadi, shuning uchun katalogni ayblashdan oldin qadamni mijoz vositasi bilan tekshiraman.

Protokol kichik va eski — RFC 2865 autentifikatsiya almashinuvini belgilaydi — lekin u olib o'tadigan atributlar VPN siyosatining ko'pchiligi qurilgan poydevordir.

# ask the RADIUS server directly, from the gateway host
radtest alice 'test-password' 127.0.0.1 0 testing123

# watch the exchange the gateway actually sends
tcpdump -ni any -c 20 'udp port 1812'

RADIUS serveri faqat identifikatsiya provayderining old qismi bo'lishi mumkin

Odamlar RADIUS va identifikatsiya provayderi haqida bir quti deb gapiradilar. Ko'pincha unday emas. RADIUS serveri Access-Request oladi va javob berishdan oldin boshqa narsadan so'raydi — LDAP yoki Kerberos orqali Active Directory, mahalliy foydalanuvchi fayli yoki tashqi xizmat. LDAP yoki krb5 moduli bilan FreeRADIUS, Windows NPS va Cisco ISE hammasi shu holatda turadi.

Bu farq qayerga qarashni hal qiladi. Rad etilgan parol — RADIUS uzatadigan identifikatsiya provayderi javobi. Vaqt tugashi odatda RADIUS dan katalogga qadar bo'lgan qism: muddati o'tgan bind hisobi, yetib bo'lmaydigan katalog yoki noto'g'ri backendga yuborilgan so'rov. Agar foydalanuvchi nomida domen qo'shimchasi bo'lsa, server shunga qarab marshrutlashi mumkin va CORP\alice va [email protected] sifatida yuborilgan bir xil hisob turli joylarga tushishi mumkin. Windows NPS da Security jurnali ruxsat uchun 6272, rad etish uchun 6273 yozadi, bu qaror NPS dan kelganini bildiradi.

Muvaffaqiyatsizlikni uni keltirib chiqargan qadamda o'qing

Bitta ulanib bo'lmaydi xabari to'rt xil muvaffaqiyatsizlikni qamrab oladi. Biror narsani o'zgartirishdan oldin simptomni uni keltirib chiqargan qadam bilan moslashtiring.

Oxirgi qator odamlarni noto'g'ri jamoaga yuboradigan qatordir. Access-Accept hisob ma'lumotlari qabul qilinganini bildiradi; shlyuz foydalanuvchini to'g'ri hovuzga joylashtirgani yoki marshrutlarni itarib yuborganini bildirmaydi. Guruh atributlari faqat shlyuz siyosati ularni o'qisa muhim. Men to'g'ri kirishning mehmon hovuziga tushganini ko'rganman, chunki RADIUS tomonida guruh xaritasi shlyuz tekshiradigan atributdan boshqa atributga sozlangan edi.

Bitta kirishni boshidan oxirigacha kuzatib boring

Bitta sinov hisobi va bitta shlyuz tanlang, so'ngra o'sha urinishni to'rt nuqtada kuzating. RADIUS tomonida disk raskadrovkani boshlang — freeradius -X so'rovni va u tegadigan har bir modulni chop etadi — shlyuzning autentifikatsiya jurnalini kuzatib boring va UDP almashinuvi uchun tcpdump ishga tushiring. Bir marta ulanib, to'rt izni tartib bilan o'qing.

Ko'rmoqchi bo'lganingiz — kelishuv: shlyuz siz kutgan foydalanuvchi haqida so'radi, RADIUS serveri siz kutgan backendni tanladi, o'sha backend qaror qaytardi va javobdagi atributlar shlyuz qo'llaydigan siyosatga mos keladi. Izlar birinchi marta mos kelmaydigan joy — sizning nosozlik chizig'ingiz. Agar javobda guruh atributi bo'lmasa, muammo VPN profilida emas, RADIUS tomonida; agar atribut bor bo'lib, shlyuz uni e'tiborsiz qoldirsa, muammo shlyuz siyosatida.

U yerda bo'lganingizda bir xavfsizlik eslatmasi. Umumiy sir almashinuvni himoya qiladi, lekin atributlarning ko'pini shifrlamaydi. Agar shlyuz va RADIUS serveri turli segmentlarda bo'lsa, o'sha qadamni TLS orqali RADIUS ga yoki xususiy yo'lga qo'ying. Shifrlangan foydalanuvchi tunneli backend aloqasi haqida hech narsa demaydi.

Chiptani yopishdan oldin to'rt narsani tasdiqlang. Shlyuz RADIUS serveriga haqiqatda sozlangan portda yetib bora oladi. Umumiy sir ikki tomonda mos keladi. RADIUS serveri shlyuz yuboradigan foydalanuvchi nomining aniq shaklini hal qiladi. Qabul shlyuz siyosatiga kerakli atributlarni olib o'tadi. To'rttasi ham to'g'ri bo'lsa, hali ham muvaffaqiyatsiz bo'lgan kirish autentifikatsiya emas, shlyuz siyosati muammosidir.