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 अभी भी अपना खाता चुनता और अधिकृत करता है, और अगले व्यक्ति को आपका परिणाम दोहराने के लिए दोनों तथ्य चाहिए।