HTTPS Basic autentifikatsiyasi va IPsec: har biri nimani himoya qiladi

Dasturchi asboblarini oching, ichki ilovani yuklang va sahifa chizilishidan oldin bitta so‘rov to‘rtta nazorat nuqtasidan qanday o‘tishini kuzating. Avval nom hal qilinadi, keyin TCP ulanishi ochiladi, so‘ngra TLS qo‘l berish server kimligini aniqlaydi va shundan keyingina ilova siz kimligingizni so‘raydi. Bularni alohida hodisalar deb qabul qiling, chunki har biri boshqa dalillar bilan muvaffaqiyatsiz bo‘ladi va har biri boshqa jamoaga tegishli. Hodisalardagi chalkashliklarning ko‘p qismi 401ni tunnel muammosi deb o‘qishdan yoki tunnel muammosini yomon parol deb o‘qishdan kelib chiqadi.

Birinchi nazorat nuqtasi: bu siz gaplashmoqchi bo‘lgan servermi

TLS qo‘l berish bu savolga har qanday hisob ma’lumoti yuborilishidan oldin javob beradi. Sizning mijozingiz sertifikat zanjirini ishonch omboriga qarshi tekshiradi va sertifikatdagi nom siz kiritgan xostga mos kelishini tekshiradi. Agar bu muvaffaqiyatsiz bo‘lsa, brauzer sertifikat xatosini ko‘rsatadi va Authorization sarlavhasini umuman yubormaydi. Shuning uchun parol so‘rovi server haqiqiy ekanining dalili emas; bu ilova javob berganining dalili.

Bu yerda birinchi chegara ko‘rinadi. TLS ulanishni tugash nuqtasigacha himoya qiladi. Agar yuk balanslagichi TLSni tugatib, ilovaga oddiy HTTP yuborsa, shifrlangan segment balanslagichda tugaydi va hisob ma’lumotlari faqat o‘sha birinchi bosqichda himoyalanadi.

Ikkinchi nazorat nuqtasi: 401 almashinuvida aslida nima harakatlanadi

HTTP Basic autentifikatsiyasi foydalanuvchi identifikatorini va parolni sarlavhada yuboradi, ular RFC 7617 da tavsiflanganidek Base64 bilan kodlanadi. Authorization: Basic dXNlcjpwYXNz uning shakli; kodlashni so‘rovni o‘qiy oladigan har kim qaytara oladi, shuning uchun butun maxfiylik ostidagi transportdan keladi. curl -v ikkala WWW-Authenticate: Basic chaqirig‘ini va siz qaytarib yuboradigan sarlavhani ko‘rsatadi.

Bu sarlavha ilovaga kim so‘rayotganini aytadi. Tarmoqqa kim ulanishi mumkinligini aytmaydi va o‘z-o‘zidan hech narsani shifrlamaydi. Ilova baribir hisob ma’lumotini omborga qarshi tekshirishi va bu hisob nima qila olishini hal qilishi kerak, bu esa avtorizatsiya bo‘lib, autentifikatsiyadan keyin sodir bo‘ladi.

IPsec tunneli bu yo‘lda qayerda turadi

Endi brauzerdan tashqariga qarab yuring. Shlyuzdan shlyuzga IPsec tunneli ikki xavfsizlik shlyuzi o‘rtasidagi tanlangan trafikni himoya qiladi, noutbukingiz va ilova jarayoni o‘rtasidagini emas. Tunnel rejimidagi ESP asl paketni o‘raydi, shlyuzlar uni shifrlaydi va autentifikatsiya qiladi, ichki manzillar saqlanadi, shunda uzoq tomon so‘rovni ilovaga yo‘naltira oladi.

Tanlov odamlarni qoqintiradigan qismdir. Siyosatga asoslangan tunnellar qaysi paketlar tunnelga kirishini hal qilish uchun trafik selektorlaridan foydalanadi, ular ko‘pincha kirish nazorati ro‘yxatlari sifatida ifodalanadi. Marshrutga asoslangan tunnellar esa buning o‘rniga virtual interfeys va marshrutlash jadvalidan foydalanadi. Linuxda ip xfrm policy selektorlarni ko‘rsatadi va ip xfrm state o‘rnatilgan xavfsizlik assotsiatsiyalarini ko‘rsatadi; xavfsizlik devori qurilmasida ekvivalenti tunnelning SA jadvali va paket kuzatuvchisidir.

Natijani ochiq aytish kerak. Paket butunlay sog‘lom tunnel ichida o‘tirib, ilova rad etadigan HTTPS so‘rovini tashishi mumkin, va to‘g‘ri hisob ma’lumotlari marshrutlash ruxsat bersa, tunnelsiz yo‘l orqali ham kelishi mumkin.

Xatoni uni xabar qilgan qatlamda o‘qing

401 ilova hisob ma’lumotini qabul qilmaganini bildiradi. 403 identifikatsiyani qabul qilib, operatsiyani rad etganini bildiradi. TLS xatosi mijoz serverni qabul qilmaganini bildiradi. Marshrut yo‘qligi yoki siyosat mos kelmasligi paket uzoq shlyuzga hech qachon yetib bormaganini bildiradi. To‘rt xil muvaffaqiyatsizlik, to‘rt xil egasi, va ularning hech biri kirish shakliga tikilib aniqlanmaydi.

Har bir qatlam ishlab chiqaradigan dalillardan foydalaning: holat va sarlavhalar uchun brauzerning tarmoq paneli, sertifikat zanjiri uchun openssl s_client -connect host:443, tunnel trafigi uchun shlyuzning SA hisoblagichlari va jurnallari, va hisob qarori uchun ilova jurnali. Ikki qatlam bir vaqtda xato xabar qilsa, avval pastki qatlamni tuzating, chunki o‘lik tunnel autentifikatsiya muvaffaqiyatsizligini osongina yashirishi mumkin va aksi ham shunday.

Bitta xizmatni boshidan oxirigacha xaritalang

Siz muammosini hal qilayotgan xizmat uchun besh qator yozing: tunnel qaysi tomonlarni bog‘laydi, selektorlar qaysi quyi tarmoqlar va portlarga ruxsat beradi, TLS qayerda tugaydi va sertifikat qaysi identifikatsiyani tasdiqlaydi, qaysi ilova hisobi va roli ishlatiladi, va har bir qatlam qayerda jurnal yuritadi. Ularni bitta sahifada saqlang, chunki xaritaning maqsadi bir qatlam mas’uliyati qayerda tugab, keyingisi qayerda boshlanishini ko‘rsatishdir.

So‘ngra har bir qatlam uchun bitta salbiy holatni sinab ko‘ring. Noto‘g‘ri parol ishlatib, vaqt tugashi emas, 401 olishingizni tasdiqlang. Selektorlardan tashqaridagi quyi tarmoqdan ulanib, paket tunnelga kirmasligini tasdiqlang. Noto‘g‘ri nom uchun sertifikat taqdim etib, mijoz hisob ma’lumotlarini yuborishdan oldin rad etishini tasdiqlang. O‘sha uch natija sizga dizayn haqida har qanday quti diagrammasidan ko‘proq gapiradi.

Nihoyat, har bir munosabat qanday himoyaga muhtojligini ongli ravishda hal qiling. TLS ustidagi Basic autentifikatsiya shlyuz orqasidagi kichik ichki vosita uchun o‘rinli; u har bir foydalanuvchi uchun avtorizatsiya yoki TLS oxirgi nuqtasidan tashqari trafikni himoya qilishning o‘rnini bosmaydi. Tunnel yo‘lni himoya qiladi, sertifikat bosqichni himoya qiladi, 401 esa hisobni himoya qiladi, va ulardan faqat oxirgisi siz kimligingizni biladi.