VPN üzərindən MySQL: yalnız şifrələməni deyil, serveri də təsdiqləyin
Səhv hosta şifrələmə yenə səhvdir. ssl-mode dəyərlərini müqayisə edin, sonra nəzərdə tutduğunuz serveri adlandıran və bunu sübut edən bağlantı qurun.
Bağlantını 10.20.4.15 ünvanına yadda saxlayırsınız, VPN düşür, amma müştəri yenə də qoşulur. Bu yaxşı xəbər deyil. Şəxsi ünvan hansı marşrutlaşdırma kontekstində olsanız, oradakı bir yerdir və bir çox şəbəkə eyni aralıqları istifadə edir. Müştəri MySQL serverinə çatdı, sadəcə sizin serverinizə çatmamış ola bilər.
Düzəlişin iki yarısı var və onlardan yalnız biri şəbəkə ilə bağlıdır. Bağlantını nəzərdə tutulan yolda saxlayın və müştərinin danışdığı serveri təsdiqləməsini təmin edin. Birinci yarıda VPN kömək edir; ikinci yarı konfiqurasiya edilməlidir.
Bəs nəyə şifrələnib, dəqiq?
TLS söhbəti ortadakı hər kəsdən qoruyur və müştəri yoxlamasa, son nöqtənin kim olduğunu iddia etdiyi barədə heç nə demir. Etibarlı orqana qarşı doğrulanan sertifikat onu sübut edir ki, sertifikat həmin orqan tərəfindən verilib. Bu, sertifikatın çatmaq istədiyiniz host adına verildiyini sübut etmir və bunlar fərqli suallardır.
Bu nəzəri boşluq deyil. Captive portallar, səhv VRF xətaları və üst-üstə düşən ünvan planları hamısı sizinlə TLS danışıqlarına tam hazır olan bir server yaradır. Əgər müştəri yalnız şifrələmə tələb edirsə, sessiya şəxsi olur, amma səhv verilənlər bazasına yönəlir.
Yəni əlaqəli sual bağlantının şifrələnib-şifrələnmədiyi deyil, nəzərdə tutduğunuz kimliyə şifrələnib-şifrələnmədiyidir. MySQL müştərisində bu fərq tamamilə ssl-mode parametrində yaşayır.
ssl-mode dəyərlərinin beşi praktikada
Beş dəyər var və onlardan yalnız biri bu runbook-un sualına cavab verir. Cədvəl hər birinin adının təklif etdiyini deyil, həqiqətən nəyə zəmanət verdiyini göstərir.
| 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 |
Bu məqalədəki suala yalnız sonuncu sətir cavab verir. PREFERRED tək başına qeyd edilməyə dəyər, çünki səssizcə açıq mətnə düşən müştəri imtina edəndən pisdir: şifrələmə olduğuna inanırsınız, paket tutucusu isə bunun əksini deyir.
Bugün işlədə biləcəyiniz bir bağlantı
Aşağıdakı əmr istifadə ediləcək formadır, iki yer tutucusu ilə: təsdiqlənmiş verilənlər bazası adı və təsdiqlənmiş kanaldan alınmış CA faylı. Heç biri serverin ilk təmasda təklif etdiyi şeydən götürülməməlidir.
mysql --host=db.corp.example --user=app_reader \
--ssl-mode=VERIFY_IDENTITY \
--ssl-ca=/approved/path/ca.pem --password--password dəyərsiz olduqda sorğu göndərir, bu da sirri proses siyahısından və shell tarixçənizdən kənarda saxlayır. Bu, paylaşılan jump hostlarda böyük fayda verən kiçik bir vərdişdir, çünki əmr sətri digər istifadəçilərə görünür.
Bu uğursuz olduqda, xəta mətni halları intuisiyadan daha yaxşı ayırd edir. CA xətası zəncirin doğrulanmadığını bildirir və server sertifikatını hansı CA-nın imzaladığına baxmalısınız. Host adı xətası zəncirin qaydasında olduğunu, adın uyğun gəlmədiyini bildirir; bu adətən səhv serverə deyil, düzgün serverə səhv adla qoşulduğunuzu göstərir.
Sorğunun görünməsi parolun artıq ötürüldüyünə sübut deyil və uğursuz bağlantı müştəridən heç nə çıxmadığını sübut etmir. Keçmiş hadisəni bərpa edirsinizsə, müştərini, onun konfiqurasiyasını, autentifikasiya plaginini və uğursuz olan mərhələni müəyyənləşdirin. Son xəta mesajından məruz qalmanı təxmin etmək təxmindir.
Ad tuneldən gəldikdə
Lokal port yönləndirməsi kimlik yoxlamasını insanları təəccübləndirən şəkildə pozur. Lokal portu verilənlər bazasına yönləndirib localhost ünvanına qoşulsanız, müştəri sertifikatı localhost üzərində doğrulayır, halbuki o ad üçün heç bir sertifikat verilməyib. Bağlantı tamamilə təhlükəsiz ola bilər və yoxlama yenə də uğursuz olacaq; bu, yoxlamanın nəzərdə tutulduğu kimi işləməsidir.
İki dürüst cavab var. Yönləndirilmiş son nöqtəyə loopback ünvanına çözülən və server sertifikatında görünən bir ad verin, ya da müştərinin real kimliyi doğrulaması üçün host adını başdan sona istifadə edin. Birincisi tərtibatçılar üçün rahatdır və sertifikat işi tələb edir; ikincisi üzərində düşünmək daha sadədir və avtomatlaşdırma üçün çox vaxt düzgün standartdır. Yönləndirmənin işləməsi üçün yoxlamanı söndürmək əlavə etməyə çalışdığınız xassəni atır.
Qəbul üç şərtdir
Qəbul testini üç ayrı ifadə kimi yazın: bağlantı nəzərdə tutulan marşrutdan istifadə etdi, şifrələmə üstünlük deyil tələb idi, və server kimliyi etibarlı materiala qarşı doğrulandı. Yaşıl VPN ikonu bunlardan heç birini təsdiqləmir.
GUI müştəriləri və MariaDB üçün bayraq yazılışının olduğu kimi keçdiyini güman etmək əvəzinə satıcının öz sənədlərinə baxın. MySQL şifrələnmiş bağlantı sənədləri rejim fərqlərini və CA paylanması tələbini əhatə edir və istehsal bağlantı sətrini dəyişməzdən əvvəl baxmalı olduğunuz mənbədir.