VPN દ્વારા MySQL: સર્વર ચકાસો, ફક્ત એન્ક્રિપ્શન નહીં
ખોટા હોસ્ટ પર એન્ક્રિપ્શન પણ ખોટું છે. ssl-mode મૂલ્યોની સરખામણી કરો, પછી એવું જોડાણ ચલાવો જે તમે ઇચ્છેલા સર્વરનું નામ આપે અને તે સાબિત કરે.
તમે 10.20.4.15 પર જોડાણ સાચવો છો, VPN તૂટી જાય છે, અને ક્લાયન્ટ હજી પણ જોડાય છે. આ સારા સમાચાર નથી. ખાનગી સરનામું એ તમે જે પણ રાઉટિંગ સંદર્ભમાં હો તેની અંદરનું સ્થાન છે, અને ઘણા નેટવર્ક સમાન શ્રેણીઓ વાપરે છે. ક્લાયન્ટ એક MySQL સર્વર સુધી પહોંચ્યો, ફક્ત કદાચ તમારા સુધી નહીં.
ઉકેલની બે અડધી છે, અને તેમાંથી ફક્ત એક નેટવર્ક વિશે છે. જોડાણને તેના ઇચ્છિત માર્ગ પર રાખો, અને ક્લાયન્ટને જે સર્વર સાથે વાત કરે છે તેની ઓળખ ચકાસવા દો. પ્રથમ અડધી એ છે જ્યાં VPN મદદ કરે છે; બીજી અડધી ગોઠવવી પડે છે.
બરાબર શેના માટે એન્ક્રિપ્ટેડ?
TLS વાતચીતને વચ્ચેના કોઈપણથી બચાવે છે અને એન્ડપોઇન્ટ પોતાને કોણ કહે છે તે વિશે કંઈ કહેતું નથી, સિવાય કે ક્લાયન્ટ તેને ચકાસે. વિશ્વસનીય સત્તાધિકારી સામે માન્ય થતું પ્રમાણપત્ર સાબિત કરે છે કે પ્રમાણપત્ર તે સત્તાધિકારી પાસેથી આવ્યું છે. તે સાબિત કરતું નથી કે પ્રમાણપત્ર તમે પહોંચવા માંગતા હોસ્ટનામ માટે જારી કરવામાં આવ્યું છે, અને તે અલગ પ્રશ્નો છે.
આ સૈદ્ધાંતિક ખાલી જગ્યા નથી. કેપ્ટિવ પોર્ટલ, ખોટા VRF ની ભૂલો અને ઓવરલેપિંગ સરનામાં યોજનાઓ બધા એવું સર્વર બનાવે છે જે તમારી સાથે TLS વાટાઘાટ કરવા સંપૂર્ણ તૈયાર છે. જો ક્લાયન્ટ ફક્ત એન્ક્રિપ્શનની માંગ કરે, તો સત્ર ખાનગી છે અને ખોટા ડેટાબેઝ તરફ નિર્દેશિત છે.
તેથી સંબંધિત પ્રશ્ન એ નથી કે જોડાણ એન્ક્રિપ્ટેડ છે કે નહીં, પણ એ છે કે તે તમે ઇચ્છેલી ઓળખ તરફ એન્ક્રિપ્ટેડ છે કે નહીં. MySQL ના ક્લાયન્ટમાં, તે ભેદ સંપૂર્ણપણે ssl-mode સેટિંગમાં રહે છે.
વ્યવહારમાં પાંચ ssl-mode મૂલ્યો
પાંચ મૂલ્યો છે, અને તેમાંથી ફક્ત એક આ રનબુકના પ્રશ્નનો જવાબ આપે છે. કોષ્ટક દરેક ખરેખર શું બાંયધરી આપે છે તે સૂચિબદ્ધ કરે છે, તે નહીં જે તેનું નામ સૂચવે છે.
| 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 |
આ લેખના પ્રશ્નનો જવાબ ફક્ત છેલ્લી પંક્તિ આપે છે. PREFERRED એકલા ધ્યાનપાત્ર છે, કારણ કે જે ક્લાયન્ટ ચુપચાપ સાદા ટેક્સ્ટ પર પડી જાય છે તે નકારનારા કરતાં વધુ ખરાબ છે: તમને લાગે છે કે તમારી પાસે એન્ક્રિપ્શન છે અને પેકેટ કેપ્ચર તેની સાથે સહમત નથી.
આજે ચલાવી શકાય એવું જોડાણ
નીચેનો આદેશ વાપરવાનું સ્વરૂપ છે, બે પ્લેસહોલ્ડર સાથે: મંજૂર ડેટાબેઝ નામ અને મંજૂર ચેનલ દ્વારા મેળવેલ CA ફાઇલ. બંનેમાંથી કોઈ પણ સર્વર પ્રથમ સંપર્કમાં પ્રસ્તાવ કરે તેમાંથી લેવું ન જોઈએ.
mysql --host=db.corp.example --user=app_reader \
--ssl-mode=VERIFY_IDENTITY \
--ssl-ca=/approved/path/ca.pem --password--password મૂલ્ય વગર પ્રોમ્પ્ટ કરે છે, જે રહસ્યને પ્રોસેસ સૂચિ અને તમારા શેલ ઇતિહાસની બહાર રાખે છે. આ નાની આદત છે જેનો મોટો લાભ શેર કરેલા જમ્પ હોસ્ટ પર થાય છે, જ્યાં કમાન્ડ લાઇન અન્ય વપરાશકર્તાઓને દેખાય છે.
જ્યારે આ નિષ્ફળ જાય, ત્યારે ભૂલનું લખાણ કેસોને અંતર્જ્ઞાન કરતાં વધુ સારી રીતે અલગ પાડે છે. CA નિષ્ફળતાનો અર્થ છે કે સાંકળ માન્ય થતી નથી અને તમારે જોવું જોઈએ કે સર્વર પ્રમાણપત્રને કઈ CA એ સહી કરી છે. હોસ્ટનામ નિષ્ફળતાનો અર્થ છે કે સાંકળ ઠીક છે અને નામ મેળ ખાતું નથી, જેનો સામાન્ય અર્થ છે કે તમે ખોટા સર્વર પર નહીં, પણ સાચા સર્વર પર ખોટા નામથી જોડાયા છો.
પ્રોમ્પ્ટ દેખાવો એ સાબિતી નથી કે પાસવર્ડ પહેલેથી મોકલાઈ ગયો છે, અને નિષ્ફળ જોડાણ સાબિત કરતું નથી કે ક્લાયન્ટમાંથી કંઈ ગયું નથી. જો તમે ભૂતકાળની ઘટના ફરી ઉભી કરો છો, તો ક્લાયન્ટ, તેની ગોઠવણી, પ્રમાણીકરણ પ્લગઇન અને નિષ્ફળ ગયેલો તબક્કો ઓળખો. અંતિમ ભૂલ સંદેશમાંથી એક્સપોઝરનો અંદાજ કાઢવો અટકળ છે.
જ્યારે નામ ટનલમાંથી આવે છે
સ્થાનિક પોર્ટ ફોરવર્ડિંગ ઓળખ ચકાસણીને એવી રીતે તોડે છે જે લોકોને આશ્ચર્યમાં મૂકે છે. જો તમે સ્થાનિક પોર્ટને ડેટાબેઝ પર ફોરવર્ડ કરો અને localhost સાથે જોડાઓ, તો ક્લાયન્ટ પ્રમાણપત્રને localhost સામે માન્ય કરે છે, અને તે નામ માટે કોઈ પ્રમાણપત્ર જારી કરવામાં આવ્યું નથી. જોડાણ સંપૂર્ણપણે સુરક્ષિત હોઈ શકે છે અને ચકાસણી તોપણ નિષ્ફળ જશે, જે એ છે કે ચકાસણી ઇચ્છિત રીતે કામ કરી રહી છે.
બે પ્રામાણિક જવાબો છે. ફોરવર્ડ કરેલા એન્ડપોઇન્ટને એવું નામ આપો જે લૂપબેક સરનામા પર ઉકેલાય અને સર્વર પ્રમાણપત્રમાં દેખાય, અથવા હોસ્ટનામને શરૂઆતથી અંત સુધી વાપરો જેથી ક્લાયન્ટ વાસ્તવિક ઓળખ ચકાસે. પ્રથમ ડેવલપર્સ માટે અનુકૂળ છે અને પ્રમાણપત્ર કાર્યની જરૂર છે; બીજું વિચારવા માટે સરળ છે અને ઘણી વાર ઓટોમેશન માટે સાચું ડિફોલ્ટ છે. ફોરવર્ડ કામ કરે તે માટે ચકાસણી બંધ કરવી એ તમે ઉમેરવા માંગતી મિલકતને ફેંકી દે છે.
સ્વીકૃતિ ત્રણ શરતો છે
સ્વીકૃતિ પરીક્ષણને ત્રણ અલગ વિધાનો તરીકે લખો: જોડાણે ઇચ્છિત માર્ગ વાપર્યો, એન્ક્રિપ્શન પસંદગી નહીં પણ જરૂરી હતું, અને સર્વરની ઓળખ વિશ્વસનીય સામગ્રી સામે ચકાસવામાં આવી. લીલું VPN ચિહ્ન તેમાંથી એક પણ સ્થાપિત કરતું નથી.
GUI ક્લાયન્ટ અને MariaDB માટે, ફ્લેગની જોડણી એ જ રીતે લાગુ પડે છે એમ માનવાને બદલે વિક્રેતાના પોતાના દસ્તાવેજીકરણને ચકાસો. MySQL એન્ક્રિપ્ટેડ જોડાણ દસ્તાવેજીકરણ મોડ વચ્ચેના તફાવતો અને CA વિતરણની જરૂરિયાત આવરી લે છે, અને ઉત્પાદન જોડાણ શબ્દમાળા બદલતા પહેલા તે ચકાસવાનો સંદર્ભ છે.