VPN арқылы MySQL: шифрлауды ғана емес, серверді де тексеріңіз

Дұрыс емес хостқа шифрлау да қате. ssl-mode мәндерін салыстырыңыз, содан кейін көздеген серверді атайтын және оны дәлелдейтін қосылымды іске қосыңыз.

Сіз 10.20.4.15 мекенжайына қосылымды сақтайсыз, VPN үзіледі, бірақ клиент әлі де қосылады. Бұл жақсы жаңалық емес. Жеке мекенжай — сіз қай маршруттау контекстінде болсаңыз да, соның ішіндегі орын, және көптеген желілер бірдей диапазондарды пайдаланады. Клиент MySQL серверіне жетті, тек сіздің серверіңізге жетпеген болуы мүмкін.

Түзетудің екі жартысы бар және олардың тек біреуі ғана желіге қатысты. Қосылымды көзделген жолда ұстаңыз және клиентті сөйлесіп тұрған серверді аутентификациялауға мәжбүр етіңіз. Бірінші жартысы — VPN көмектесетін жер; екінші жартысын конфигурациялау керек.

Нақты неге шифрланған?

TLS әңгімені ортадағы кез келгеннен қорғайды және клиент тексермесе, соңғы нүктенің өзін кім деп мәлімдейтіні туралы ештеңе айтпайды. Сенімді органға қатысты тексерілетін сертификат сертификаттың сол органнан шыққанын дәлелдейді. Ол сертификаттың сіз жеткіңіз келген хост атына берілгенін дәлелдемейді, және бұлар әртүрлі сұрақтар.

Бұл теориялық олқылық емес. Captive порталдар, қате VRF қателері және қабаттасатын мекенжай жоспарлары — барлығы сізбен TLS келіссөзін жүргізуге толық дайын сервер жасайды. Егер клиент тек шифрлауды талап етсе, сессия жеке, бірақ қате дерекқорға бағытталған.

Сондықтан тиісті сұрақ қосылымның шифрлануында емес, оның көздеген тұлғаға шифрлануында. MySQL клиентінде бұл айырмашылық толығымен ssl-mode параметрінде өмір сүреді.

Практикадағы бес ssl-mode мәні

Бес мән бар және олардың тек біреуі осы нұсқаулықтың сұрағына жауап береді. Кесте әрқайсысының аты нені меңзейтінін емес, шын мәнінде нені кепілдейтінін тізіп көрсетеді.

ModeWhat it guarantees
DISABLEDNo TLS at all; everything on the wire is readable
PREFERREDTries TLS and falls back to plaintext when the account and server allow it, so it is not a fail-closed requirement
REQUIREDRefuses to connect without TLS, and does not validate the certificate
VERIFY_CAValidates the server certificate against the configured CA and does not check the hostname
VERIFY_IDENTITYValidates the CA and checks that the certificate names the host the client used

Бұл мақаладағы сұраққа тек соңғы жол жауап береді. PREFERRED өз алдына назар аударуға тұрарлық, өйткені үнсіз қарапайым мәтінге түсіп кететін клиент бас тартатыннан да жаман: шифрлау бар деп ойлайсыз, ал пакет түсірілімі келіспейді.

Бүгін іске қосуға болатын қосылым

Төмендегі команда — қолдануға тиіс пішін, екі толтырғышпен: бекітілген дерекқор атауы және бекітілген арна арқылы алынған CA файлы. Екеуін де сервердің алғашқы байланыста ұсынатынынан алуға болмайды.

mysql --host=db.corp.example --user=app_reader \
  --ssl-mode=VERIFY_IDENTITY \
  --ssl-ca=/approved/path/ca.pem --password

--password мәнсіз болса, енгізуді сұрайды, бұл құпияны процестер тізімінен және shell тарихыңыздан тыс ұстайды. Бұл ортақ секіру хосттарында үлкен пайда әкелетін кішкентай әдет, өйткені команда жолы басқа пайдаланушыларға көрінеді.

Бұл сәтсіз болса, қате мәтіні жағдайларды түйсіктен жақсырақ ажыратады. CA қатесі тізбектің тексерілмейтінін білдіреді, сондықтан сервер сертификатына қай CA қол қойғанын қарау керек. Хост атының қатесі тізбектің дұрыс екенін және атаудың сәйкес келмейтінін білдіреді, бұл әдетте қате серверге емес, дұрыс серверге қате атпен қосылғаныңызды білдіреді.

Сұраныстың пайда болуы құпиясөздің әлдеқашан жіберілгенінің дәлелі емес, ал сәтсіз қосылым клиенттен ештеңе шықпағанын дәлелдемейді. Егер өткен оқиғаны қайта жасасаңыз, клиентті, оның конфигурациясын, аутентификация плагинін және сәтсіз болған кезеңді анықтаңыз. Соңғы қате хабарламасынан әсерді бағалау — болжам.

Атау туннельден келгенде

Жергілікті портты қайта бағыттау тұлғаны тексеруді адамдарды таңқалдыратын түрде бұзады. Жергілікті портты дерекқорға қайта бағыттап, localhost мекенжайына қосылсаңыз, клиент сертификатты localhost мекенжайына қатысты тексереді, ал бұл атқа сертификат берілмеген. Қосылым толығымен қауіпсіз болуы мүмкін, бірақ тексеру бәрібір сәтсіз аяқталады, бұл тексерудің мақсатындай жұмыс істеп тұрғаны.

Екі адал жауап бар. Қайта бағытталған соңғы нүктеге loopback мекенжайына шешілетін және сервер сертификатында көрінетін ат беріңіз, немесе клиент нақты тұлғаны тексеретіндей хост атын басынан аяғына дейін пайдаланыңыз. Біріншісі әзірлеушілерге ыңғайлы және сертификат жұмысын талап етеді; екіншісі ойлауға оңайырақ және автоматтандыру үшін жиі дұрыс әдепкі. Қайта бағыттау жұмыс істеуі үшін тексеруді өшіру — қосқыңыз келген қасиетті лақтырып тастау.

Қабылдау — үш шарт

Қабылдау тестін үш бөлек тұжырым ретінде жазыңыз: қосылым көзделген маршрутты пайдаланды, шифрлау қалаулы емес, талап етілген болды, және сервер тұлғасы сенімді материалға қатысты тексерілді. Жасыл VPN белгішесі олардың ешқайсысын орнатпайды.

GUI клиенттері мен MariaDB үшін флаг емлесі сол күйінде қолданылады деп болжаудың орнына жеткізушінің өз құжаттамасын тексеріңіз. MySQL шифрланған қосылымдар құжаттамасы режимдер арасындағы айырмашылықтарды және CA тарату талабын қамтиды, және өндірістік қосылым жолын өзгерту алдында тексеру керек сілтеме осы.

Қатысты мақалалар