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 वितरणाची आवश्यकता समाविष्ट करते, आणि उत्पादन कनेक्शन स्ट्रिंग बदलण्यापूर्वी तपासावे असे संदर्भ हेच आहे।