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