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 таратуу талабын камтыйт, жана өндүрүштүк туташуу сабын өзгөртүүдөн мурун текшерүү керек болгон шилтеме ушул.

Тектеш макалалар