VPN वर MariaDB: सर्व्हर कोणते user@host पाहतो?
खाते वापरकर्ता आणि होस्ट एकत्र ठरवले जाते। सर्व्हरने पाहिलेला स्रोत शोधा, CURRENT_USER() वाचा आणि नंतर तीच ओळ दुरुस्त करा, परवानगी नाही।
एकच वापरकर्तानाव दोन वेगळ्या मार्गांनी टाका आणि MariaDB तुम्हाला दोन वेगळी खाती म्हणून प्रमाणित करू शकते। खाती वापरकर्ता आणि होस्ट एकत्र यावर आधारित असतात, म्हणून 'reporter'@'localhost' आणि 'reporter'@'10.90.0.23' वेगळे पासवर्ड आणि वेगळ्या परवानग्या असलेल्या वेगळ्या ओळी आहेत। VPN वर मनोरंजक प्रश्न हा नाही की वापरकर्त्याने कोणते नाव टाकले, तर सर्व्हरने कोणता स्रोत पत्ता पाहिला हा आहे।
सर्व्हर प्रत्यक्षात पाहत असलेला स्रोत निश्चित करा
लॅपटॉपवरून नाही, डेटाबेस होस्टवरून मागे जाऊन काम करा। क्लायंटला आहे असे वाटणारा पत्ता अनेक शक्यतांपैकी एकच आहे:
| Path | Source MariaDB sees |
|---|---|
| Routed tunnel, no translation | The client's inner VPN address |
| Gateway source translation | The gateway's translated address |
| SSH local forward | The SSH server's address |
| Public exit, no tunnel | Whatever the ISP handed out |
ते ठरवण्यासाठी सर्व्हर-बाजूचे पुरावे वापरा। कनेक्शन लॉग, सक्रिय सत्रांची यादी किंवा सामान्य लॉगमधील तात्पुरती नोंद सर्व्हरने स्वीकारलेला पत्ता दाखवते। ब्राउझरवरून दिसणारा लॅपटॉपचा सार्वजनिक IP ही दुसरी वस्तुस्थिती आहे आणि बऱ्याचदा दिशाभूल करणारी असते।
MariaDB ने निवडलेल्या खात्याशी जुळवा
खाते निवड परवानग्यांच्या एकत्रीकरणाऐवजी नोंदवलेल्या क्रमाचे पालन करते। अचूक होस्ट जुळणीला वाइल्डकार्डवर प्राधान्य असते, आणि अनामिक वापरकर्त्याच्या ओळी फक्त नाव ठरवते असे गृहीत धरणाऱ्यांना आश्चर्याचा धक्का देणाऱ्या पद्धतीने जुळणीत सहभागी होतात। सर्व्हर एक ओळ निवडतो; तो प्रत्येक समान नावाच्या ओळीचे विशेषाधिकार एकत्र करत नाही। संदर्भ एकदा वाचणे अर्धा दिवस अंदाज तपासण्यापेक्षा जास्त मौल्यवान आहे।
याचा अर्थ असा की 'reporter'@'%' मध्ये परवानगी जोडल्याने काहीही बदलणार नाही जर सत्र 'reporter'@'10.90.0.23' म्हणून प्रमाणित झाले असेल। दुरुस्ती निवडलेल्या ओळीवरच पडली पाहिजे, म्हणूनच खाते ओळखणे परवानग्या संपादित करण्यापूर्वी येते।
सत्र प्रत्यक्षात वापरत असलेले खाते वाचा
SELECT USER(), CURRENT_USER();
SHOW GRANTS;CURRENT_USER() सत्र प्रमाणित करणाऱ्या खात्याचे नाव सांगते; USER() क्लायंटने काय मागितले ते सांगते आणि वेगळे असू शकते। हे सामान्य वरच्या स्तरावरील क्वेरी म्हणून चालवा, व्याख्याकार संदर्भ असलेल्या साठवलेल्या रूटीनमधून नाही, अन्यथा उत्तरे तुमच्या सत्राऐवजी रूटीनच्या मालकाचे वर्णन करतील।
अयशस्वी लॉगिन यापैकी काहीही चालवू शकत नाही, आणि हीच ती स्थिती आहे जिथे प्रशासकाला खाते व्याख्या आणि सर्व्हरचे कनेक्शन पुरावे तपासावे लागतात। त्यासाठी तयार राहा: नाकारलेले लॉगिन डीबग करणाऱ्या व्यक्तीकडे सहसा विचारण्यासाठी SQL सत्र नसते।
पोहोचक्षमता प्रमाणीकरणापासून वेगळी करा
त्रुटीचा मजकूर तुम्ही कोणत्या स्तरावर आहात ते सांगतो। नाकारलेले कनेक्शन किंवा वेळ संपणे म्हणजे क्लायंट कधीच श्रोत्यापर्यंत पोहोचला नाही, त्यामुळे खाते आणि त्याचा पासवर्ड अजून प्रश्नात नाहीत। प्रवेश नाकारला असा उत्तर म्हणजे सर्व्हरने उत्तर दिले, जे पोहोचक्षमता सिद्ध करते आणि खाते, होस्ट जुळणी किंवा क्रेडेन्शियलकडे निर्देश करते।
नेटवर्कच्या पूर्वअटी स्वतःची यादी आहेत: केवळ लूपबॅकवर नाही तर इच्छित पत्त्यावर बांधलेला श्रोता, कॉन्फिगर केलेल्या पोर्टवर परवानगी असलेला रहदारी आणि उत्तरासाठी परतीचा मार्ग। प्रत्येक स्वतंत्रपणे अयशस्वी होऊ शकतो, आणि कार्यरत सुरुंग यापैकी कोणतेही सूचित करत नाही। लूपबॅकवरील श्रोता स्थानिक कनेक्शन स्वीकारतो आणि प्रत्येक दूरस्थ नाकारतो, ज्यामुळे फायरवॉल ब्लॉकसारखे दिसणारे नाकारलेले कनेक्शन तयार होते।
नेटवर्क संघासोबत तिकीट उघडण्यापूर्वी बाइंड पत्ता तपासा। डेटाबेस होस्टवर ss -lntp कोणता पत्ता आणि पोर्ट प्रत्यक्षात ऐकत आहेत हे दाखवते, आणि ती एक ओळ अंदाजांचा संपूर्ण वर्ग वगळते।
अरुंदपणे दुरुस्त करा, नंतर दोन्ही दिशांनी पुन्हा चाचणी करा
संस्थेच्या मंजूर प्रक्रियेद्वारे इच्छित होस्ट-पात्र खाते तयार करा, तिकिटात चिकटवलेल्या सामायिक क्रेडेन्शियलऐवजी समर्थित साठ्यातील क्रेडेन्शियलसह। कार्यास आवश्यक असलेल्या स्कीमा क्रिया केवळ द्या। अयशस्वी दूरस्थ लॉगिनला रूट खाते, सर्व-द्या धोरण किंवा सर्वव्यापी वाइल्डकार्ड होस्ट बनवल्यास चाचणी पास होते आणि तुम्ही तपासत असलेले नियंत्रण काढून टाकले जाते। घाईघाईने जोडलेली परवानगी हीच नंतर कोणीही काढत नाही।
इच्छित मार्गाने नवीन सत्रासह पुन्हा चाचणी करा, नंतर नकारात्मक प्रकरणे तपासा। जो मार्ग अवरोधित असावा तो अजूनही अवरोधित राहिला पाहिजे, आणि जी क्रिया दिली नाही ती अजूनही नाकारली पाहिजे। या दोन तपासण्या दुरुस्त केलेले खाते विस्तारित खात्यापासून वेगळे करतात।
शेवटी, निरीक्षण केलेला स्रोत पत्ता आणि खात्याचे नाव एकत्र नोंदवा। सुरुंग पोहोचक्षमता देतो; MariaDB अजूनही स्वतःचे खाते निवडते आणि अधिकृत करते, आणि पुढच्या व्यक्तीला तुमचा निकाल पुनरुत्पादित करण्यासाठी दोन्ही तथ्ये लागतात।