MySQL kupitia VPN: thibitisha seva, si usimbaji fiche tu
Usimbaji fiche kuelekea mwenyeji asiye sahihi bado si sahihi. Linganisha thamani za ssl-mode, kisha endesha muunganisho unaotaja seva uliyokusudia na kuthibitisha hilo.
Unahifadhi muunganisho kwa 10.20.4.15, VPN inaanguka, na mteja bado anajiunga. Hiyo si habari njema. Anwani ya kibinafsi ni mahali ndani ya muktadha wowote wa uelekezaji ulio nao, na mitandao mingi hutumia safu zile zile. Mteja alifika kwenye seva ya MySQL, labda tu si yako.
Suluhisho lina nusu mbili, na ni moja tu kati yao inayohusu mtandao. Weka muunganisho kwenye njia iliyokusudiwa, na ufanye mteja kuthibitisha seva anayozungumza nayo. Nusu ya kwanza ni pale VPN inasaidia; nusu ya pili lazima isanidiwe.
Imesimbwa fiche kuelekea nini, hasa?
TLS inalinda mazungumzo kutoka kwa mtu yeyote aliye katikati, na haisemi chochote kuhusu nani mwisho unadai kuwa, isipokuwa mteja akikagua. Cheti kinachothibitishwa dhidi ya mamlaka inayoaminika kinathibitisha kuwa cheti kilitoka kwa mamlaka hiyo. Hakiathibitishi kuwa cheti kilitolewa kwa jina la mwenyeji uliyekusudia kufikia, na hayo ni maswali tofauti.
Hili si pengo la kinadharia. Portal za captive, makosa ya VRF isiyo sahihi na mipango ya anwani inayogongana yote huunda seva iliyo tayari kabisa kujadili TLS nawe. Ikiwa mteja anadai usimbaji fiche tu, kikao ni cha faragha na kinaelekezwa kwenye hifadhidata isiyo sahihi.
Kwa hivyo swali muhimu si kama muunganisho umesimbwa fiche, bali kama umesimbwa fiche kuelekea utambulisho ulioukusudia. Katika mteja wa MySQL, tofauti hiyo inaishi kabisa katika mpangilio wa ssl-mode.
Thamani tano za ssl-mode kwa vitendo
Kuna thamani tano, na ni moja tu kati yao inayojibu swali la mwongozo huu. Jedwali linaorodhesha kile kila moja inahakikisha kwa kweli, si kile jina lake linadokeza.
| 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 |
Ni safu ya mwisho pekee inayojibu swali la makala hii. PREFERRED inafaa kuangaziwa yenyewe, kwa sababu mteja anayeanguka kimya kwenye maandishi wazi ni mbaya zaidi kuliko anayekataa: unaamini una usimbaji fiche na upigaji picha wa pakiti hakubaliani.
Muunganisho unaoweza kuendesha leo
Amri iliyo chini ni umbo la kutumia, na viwakilishi viwili: jina la hifadhidata lililoidhinishwa na faili la CA lililopatikana kupitia njia iliyoidhinishwa. Hakuna kati yao linalopaswa kuchukuliwa kutoka kile seva inakupa katika mawasiliano ya kwanza.
mysql --host=db.corp.example --user=app_reader \
--ssl-mode=VERIFY_IDENTITY \
--ssl-ca=/approved/path/ca.pem --password--password bila thamani huuliza ingizo, jambo ambalo huiweka siri nje ya orodha ya michakato na nje ya historia ya shell yako. Ni tabia ndogo yenye faida kubwa kwenye wageni wa kuruka wanaoshirikiwa, ambapo mstari wa amri unaonekana kwa watumiaji wengine.
Hili linaposhindwa, maandishi ya kosa hutofautisha kesi vizuri zaidi kuliko hisia. Kushindwa kwa CA kunamaanisha mnyororo hauthibitishwi na unapaswa kuangalia ni CA gani ilitia saini cheti cha seva. Kushindwa kwa jina la mwenyeji kunamaanisha mnyororo uko sawa na jina halilingani, ambayo kwa kawaida inamaanisha uliunganisha kwenye seva sahihi kwa jina lisilo sahihi badala ya seva isiyo sahihi.
Kuonekana kwa kidokezo si uthibitisho kwamba nenosiri limeshatumwa, na muunganisho ulioshindwa hauthibitishi kuwa hakuna kitu kilichotoka kwa mteja. Ikiwa unarejesha tukio la zamani, tambua mteja, usanidi wake, programu-jalizi ya uthibitishaji na hatua iliyoshindwa. Kukadiria mfiduo kutoka ujumbe wa mwisho wa kosa ni kubahatisha.
Jina linapokuja kutoka kwenye handaki
Uelekezaji wa bandari ya ndani huvunja ukaguzi wa utambulisho kwa namna inayowashangaza watu. Ikiwa unaelekeza bandari ya ndani kwenye hifadhidata na unajiunga na localhost, mteja huthibitisha cheti dhidi ya localhost, na hakuna cheti kilichotolewa kwa jina hilo. Muunganisho unaweza kuwa salama kabisa na uthibitishaji utashindwa hata hivyo, ambayo ni ukaguzi unaofanya kazi kama ilivyokusudiwa.
Kuna majibu mawili ya uaminifu. Ipe ncha iliyoelekezwa jina linalotatuliwa kwenye anwani ya loopback na kuonekana kwenye cheti cha seva, au tumia jina la mwenyeji kutoka mwanzo hadi mwisho ili mteja athibitishe utambulisho halisi. La kwanza ni rahisi kwa watengenezaji na linahitaji kazi ya vyeti; la pili ni rahisi kufikiria na mara nyingi ndilo chaguo-msingi sahihi kwa uendeshaji otomatiki. Kuzima uthibitishaji ili uelekezaji ufanye kazi hutupa sifa uliyokuwa ukijaribu kuongeza.
Kukubali ni masharti matatu
Andika jaribio la kukubali kama kauli tatu tofauti: muunganisho ulitumia njia iliyokusudiwa, usimbaji fiche ulihitajika na si uliopendelewa, na utambulisho wa seva ulithibitishwa dhidi ya nyenzo zinazoaminika. Aikoni ya kijani ya VPN haiweki hata moja yao.
Kwa wateja wa GUI na kwa MariaDB, angalia nyaraka za muuzaji mwenyewe badala ya kudhani kwamba tahajia ya bendera inahamishwa. Nyaraka za MySQL kuhusu miunganisho iliyosimbwa fiche zinashughulikia tofauti kati ya hali na hitaji la usambazaji wa CA, na ni rejea inayopaswa kukaguliwa kabla ya kubadilisha mnyororo wa muunganisho wa uzalishaji.