VPN orqali MySQL: faqat shifrlashni emas, serverni ham tekshiring
Noto'g'ri hostga shifrlash ham noto'g'ri. ssl-mode qiymatlarini solishtiring, so'ng mo'ljallangan serverni nomlaydigan va buni isbotlaydigan ulanishni ishga tushiring.
Siz 10.20.4.15 manziliga ulanishni saqlaysiz, VPN uziladi, lekin mijoz baribir ulanadi. Bu yaxshi xabar emas. Xususiy manzil siz bo'lgan har qanday marshrutlash konteksti ichidagi joy, va ko'plab tarmoqlar bir xil diapazonlardan foydalanadi. Mijoz MySQL serveriga yetib bordi, faqat sizning serveringizga yetmagan bo'lishi mumkin.
Tuzatishning ikki yarmi bor va ulardan faqat bittasi tarmoq haqida. Ulanishni mo'ljallangan yo'lda saqlang va mijozni u gaplashayotgan serverni autentifikatsiya qilishga majbur qiling. Birinchi yarmi VPN yordam beradigan joy; ikkinchi yarmi konfiguratsiya qilinishi kerak.
Aniq nimaga shifrlangan?
TLS suhbatni o'rtadagi har kimdan himoya qiladi va mijoz tekshirmasa, oxirgi nuqta o'zini kim deb da'vo qilishi haqida hech narsa aytmaydi. Ishonchli organga qarshi tekshiriladigan sertifikat sertifikat o'sha organdan kelganini isbotlaydi. U sertifikat siz yetib bormoqchi bo'lgan host nomiga berilganini isbotlamaydi, va bular turli savollar.
Bu nazariy bo'shliq emas. Captive portallar, noto'g'ri VRF xatolari va ustma-ust tushadigan manzil rejalari barchasi siz bilan TLS muzokaralariga to'liq tayyor server yaratadi. Agar mijoz faqat shifrlashni talab qilsa, sessiya xususiy, ammo noto'g'ri ma'lumotlar bazasiga yo'naltirilgan.
Shuning uchun tegishli savol ulanish shifrlanganmi degani emas, balki u siz mo'ljallagan shaxsga shifrlanganmi degani. MySQL mijozida bu farq butunlay ssl-mode sozlamasida yashaydi.
Amalda beshta ssl-mode qiymati
Beshta qiymat bor va ulardan faqat bittasi ushbu qo'llanmaning savoliga javob beradi. Jadval har birining nomi nimani taklif qilishini emas, aslida nimani kafolatlashini sanab o'tadi.
| Mode | What it guarantees |
|---|---|
DISABLED | No TLS at all; everything on the wire is readable |
PREFERRED | Tries TLS and falls back to plaintext when the account and server allow it, so it is not a fail-closed requirement |
REQUIRED | Refuses to connect without TLS, and does not validate the certificate |
VERIFY_CA | Validates the server certificate against the configured CA and does not check the hostname |
VERIFY_IDENTITY | Validates the CA and checks that the certificate names the host the client used |
Ushbu maqoladagi savolga faqat oxirgi qator javob beradi. PREFERRED alohida ta'kidlashga arziydi, chunki jimgina oddiy matnga tushib qoladigan mijoz rad etuvchidan yomonroq: sizda shifrlash bor deb o'ylaysiz, paket yozuvi esa bunga qo'shilmaydi.
Bugun ishga tushirishingiz mumkin bo'lgan ulanish
Quyidagi buyruq ishlatiladigan shakl, ikkita joy egallovchi bilan: tasdiqlangan ma'lumotlar bazasi nomi va tasdiqlangan kanal orqali olingan CA fayli. Ikkalasini ham server birinchi aloqada taklif qilgan narsadan olmaslik kerak.
mysql --host=db.corp.example --user=app_reader \
--ssl-mode=VERIFY_IDENTITY \
--ssl-ca=/approved/path/ca.pem --password--password qiymatsiz bo'lsa, kiritishni so'raydi, bu sirni jarayonlar ro'yxatidan va shell tarixingizdan tashqarida saqlaydi. Bu umumiy sakrash hostlarida katta foyda beradigan kichik odat, chunki buyruq satri boshqa foydalanuvchilarga ko'rinadi.
Bu muvaffaqiyatsiz bo'lsa, xato matni holatlarni intuitsiyadan yaxshiroq ajratadi. CA xatosi zanjir tekshirilmasligini bildiradi va server sertifikatiga qaysi CA imzo chekkanini ko'rish kerak. Host nomi xatosi zanjir joyida ekanini va nom mos kelmasligini bildiradi, bu odatda noto'g'ri serverga emas, to'g'ri serverga noto'g'ri nom bilan ulanganingizni anglatadi.
So'rovning paydo bo'lishi parol allaqachon yuborilganining isboti emas, va muvaffaqiyatsiz ulanish mijozdan hech narsa chiqmaganini isbotlamaydi. Agar o'tmishdagi voqeani qayta tiklayotgan bo'lsangiz, mijozni, uning konfiguratsiyasini, autentifikatsiya plaginini va muvaffaqiyatsiz bosqichni aniqlang. Yakuniy xato xabaridan ta'sirni baholash taxmin.
Nom tunneldan kelganda
Lokal portni yo'naltirish shaxsni tekshirishni odamlarni hayratda qoldiradigan tarzda buzadi. Agar lokal portni ma'lumotlar bazasiga yo'naltirib, localhost manziliga ulansangiz, mijoz sertifikatni localhost manziliga qarshi tekshiradi, va bu nom uchun sertifikat berilmagan. Ulanish butunlay xavfsiz bo'lishi mumkin, tekshiruv baribir muvaffaqiyatsiz bo'ladi, bu tekshiruvning mo'ljallanganidek ishlashi.
Ikki halol javob bor. Yo'naltirilgan oxirgi nuqtaga loopback manziliga hal bo'ladigan va server sertifikatida ko'rinadigan nom bering, yoki mijoz haqiqiy shaxsni tekshirishi uchun host nomini boshdan oxirigacha ishlating. Birinchisi dasturchilar uchun qulay va sertifikat ishini talab qiladi; ikkinchisi o'ylash osonroq va avtomatlashtirish uchun ko'pincha to'g'ri standart. Yo'naltirish ishlashi uchun tekshiruvni o'chirish siz qo'shmoqchi bo'lgan xususiyatni tashlab yuboradi.
Qabul uchta shart
Qabul testini uchta alohida bayonot sifatida yozing: ulanish mo'ljallangan marshrutdan foydalandi, shifrlash afzal emas, talab qilindi, va serverning shaxsi ishonchli materialga qarshi tekshirildi. Yashil VPN belgisi ularning hech birini o'rnatmaydi.
GUI mijozlari va MariaDB uchun bayroq imlosi o'zgarishsiz o'tadi deb taxmin qilish o'rniga sotuvchining o'z hujjatlarini tekshiring. MySQL shifrlangan ulanishlar hujjati rejimlar orasidagi farqlarni va CA tarqatish talabini qamrab oladi, va ishlab chiqarish ulanish satrini o'zgartirishdan oldin tekshirilishi kerak bo'lgan manba shu.