दफ़्तर के सर्वर पर चलने वाला ऐप localhost पर MySQL से जुड़ता है, आप वही होस्टनाम डेस्कटॉप क्लाइंट में कॉपी करते हैं, और कनेक्शन या तो विफल हो जाता है या कोई दूसरा डेटाबेस खोल देता है। VPN ने शब्द के अर्थ में कुछ नहीं बदला: localhost अब भी उसी मशीन को दर्शाता है जो क्लाइंट चलाती है। VPN ने पैकेट हिलाए, इंटरफ़ेस नहीं। किसी रूट को छूने से पहले तय करें कि लैपटॉप को किस छोर तक पहुँचना है।

चरण 1: तय करें कि लैपटॉप को किस छोर तक पहुँचना है

दोनों डिज़ाइन वैध हैं और अलग-अलग सवालों का जवाब देते हैं। सीधी पहुँच का मतलब है कि डेटाबेस किसी निजी पते पर सुनता है जहाँ तक टनल पहुँचती है, और लैपटॉप उस पते से जुड़ता है। फ़ॉरवर्ड की गई पहुँच का मतलब है कि डेटाबेस loopback पर रहता है और एक SSH सत्र पोर्ट को आपकी मशीन तक ले जाता है। एक को जानबूझकर चुनें, क्योंकि दोनों मिलाने से ऐसा कनेक्शन बनता है जो ग़लत कारण से काम करता है।

सीधी पहुँच के लिए, डेटाबेस होस्ट का अपना निजी नाम या पता और उसका पोर्ट उससे लें जो उसे चलाता है। VPN गेटवे का पता डेटाबेस का पता नहीं है, जब तक वही मशीन न हो। फिर पुष्टि करें कि श्रोता वास्तव में उस इंटरफ़ेस से बँधा है, क्योंकि किसी इंटरफ़ेस तक का रूट उस पर श्रोता नहीं बनाता।

चरण 2: पोर्ट तभी फ़ॉरवर्ड करें जब श्रोता स्थानीय रहे

अगर डेटाबेस को सिर्फ़ loopback पर रहना है, तो उसे SSH से फ़ॉरवर्ड करें और स्थानीय सिरे को भी loopback से बाँधें। बाईं ओर का बाइंड पता आपके लैपटॉप का है; दाईं ओर का लक्ष्य SSH सर्वर की ओर से समझा जाता है, जैसा OpenSSH संदर्भ बताता है। इन दो भूमिकाओं को उलट देना ही आम कारण है कि फ़ॉरवर्ड काम करता दिखता है पर किसी चीज़ से नहीं जुड़ता।

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:13306:127.0.0.1:3306 [email protected]
ss -ltn 'sport = :13306'

अगर SSH डेटाबेस होस्ट के बजाय किसी जंप होस्ट पर उतरता है, तो दाईं ओर का loopback जंप होस्ट को दर्शाता है, और लक्ष्य को ऐसे पते पर बदलना होगा जहाँ वह होस्ट पहुँचता है। ExitOnForwardFailure फ़ॉरवर्ड स्थापित करने में विफलता पकड़ता है, पर यह साबित नहीं करता कि लक्ष्य तक बाद के कनेक्शन सफल होते हैं। होस्ट-की जाँच चालू रखें, और फ़ॉरवर्डिंग पोर्ट को सभी इंटरफ़ेस से बाँधकर अपने पूरे LAN को न दें।

अगर डेटाबेस को सिर्फ़ loopback पर रहना है और आप SSH इस्तेमाल नहीं कर सकते तो रुकें। तब सीधी पहुँच ग़लत डिज़ाइन है, थोपने लायक कॉन्फ़िगरेशन नहीं।

चरण 3: क्लाइंट को TCP पर बाध्य करें

Unix पर localhost दिए जाने पर MySQL क्लाइंट डिफ़ॉल्ट रूप से Unix सॉकेट चुनता है, इसलिए सिर्फ़ पोर्ट बदलने से वह ऐसा सॉकेट ढूँढता रह सकता है जिसका आपके फ़ॉरवर्ड से कोई संबंध नहीं है। स्पष्ट TCP प्रोटोकॉल और loopback पता इस्तेमाल करें ताकि क्लाइंट आपके फ़ॉरवर्डिंग पोर्ट पर कनेक्शन खोले।

mysql --protocol=TCP --host=127.0.0.1 --port=13306 --user=DB_USER --password

बिना मान वाला पासवर्ड विकल्प रहस्य को कमांड लाइन में रखने के बजाय पूछता है, और यही वह आदत है जो रखने लायक है। दूसरे औज़ारों का इसी अंतर के लिए अपना स्विच है, और कुछ ड्राइवर localhost को भी ख़ास तरह से लेते हैं। यह मानने के बजाय कि फ़्लैग पहुँच गया, जाँचें कि आपका क्लाइंट क्या करता है। डेटाबेस खाते को ऐसी अनुमति भी चाहिए जो सर्वर जो स्रोत देखता है उससे मेल खाए, और वह आपका लैपटॉप नहीं, फ़ॉरवर्डिंग होस्ट है।

अगर औज़ार को TCP पर बाध्य नहीं किया जा सकता तो रुकें। तब दूसरा क्लाइंट इस्तेमाल करें, या निजी श्रोता तक सीधी पहुँच इस्तेमाल करें।

चरण 4: साबित करें कि आप वास्तव में किस छोर तक पहुँचे

सर्वर से पूछें कि वह कनेक्शन को क्या मानता है। होस्टनाम, पोर्ट और सॉकेट चर बताते हैं कि आप TCP से आए या नहीं और किस श्रोता ने जवाब दिया, और कनेक्शन सूची वह स्रोत पता दिखाती है जो सर्वर ने दर्ज किया। वह प्रमाण किसी और रूट बदलाव से ज़्यादा उपयोगी है।

mysql --protocol=TCP -h 127.0.0.1 -P 13306 -u DB_USER -p -e "SELECT @@hostname, @@port, @@socket"

दर्ज करें कि आपने किस छोर की कोशिश की: स्थानीय Unix सॉकेट, आपका फ़ॉरवर्डिंग पोर्ट या निजी श्रोता। इन तीन विफलताओं के अलग-अलग उपाय हैं, और क्लाइंट के ग़लत localhost से बात करते समय VPN रूट बदलना व्यर्थ श्रम है। नोट्स में SSH प्रमाणीकरण और डेटाबेस प्रमाणीकरण भी अलग रखें, क्योंकि डेस्कटॉप क्लाइंट से एक में विफलता दूसरे में विफलता जैसी दिखती है। फिर काम पूरा होने पर फ़ॉरवर्ड हटा दें।

जाँच-सूची तब पूरी होती है जब आप छोर, क्लाइंट प्रोटोकॉल, सर्वर द्वारा देखा गया स्रोत पता और उसे अनुमति देने वाली अनुमति का नाम बता सकें। चार तथ्य, और अगली कनेक्शन समस्या दोपहर के बजाय कुछ मिनट लेती है।

संबंधित लेख