VPN द्वारे MySQL localhost: याचा अर्थ अजूनही स्थानिक प्रक्रिया आहे

कार्यालयीन सर्व्हरवरील अॅप 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 प्रमाणीकरण आणि डेटाबेस प्रमाणीकरणही वेगळे ठेवा, कारण डेस्कटॉप क्लायंटवरून एकातील अपयश दुसऱ्यातील अपयशासारखे दिसते। नंतर काम झाल्यावर फॉरवर्ड काढून टाका।

टोक, क्लायंट प्रोटोकॉल, सर्व्हरने पाहिलेला स्रोत पत्ता आणि त्यास परवानगी देणारी परवानगी यांची नावे सांगता आल्यावर यादी संपते। चार तथ्ये, आणि पुढील कनेक्शन समस्या दुपारऐवजी काही मिनिटांत सुटते।