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 वितरणको आवश्यकता समेट्छ, र उत्पादन जडान स्ट्रिङ परिवर्तन गर्नुअघि जाँच्नुपर्ने सन्दर्भ यही हो।