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'@'10.90.0.23' को रूपमा प्रमाणित भएको खण्डमा 'reporter'@'%' मा अनुमति थप्दा केही पनि नबदल्न सक्छ। सुधार छानिएको पङ्क्तिमै पर्नुपर्छ, त्यसैले खाता पहिचान अनुमति सम्पादनभन्दा अगाडि आउँछ।
सत्रले वास्तवमा प्रयोग गर्ने खाता पढ्नुहोस्
SELECT USER(), CURRENT_USER();
SHOW GRANTS;CURRENT_USER() ले सत्र प्रमाणित गर्ने खाताको नाम दिन्छ; USER() ले क्लाइन्टले के माग्यो भनी जानकारी दिन्छ र फरक हुन सक्छ। यिनलाई सामान्य उच्च-स्तरीय क्वेरीको रूपमा चलाउनुहोस्, परिभाषक सन्दर्भ भएको भण्डारित रुटिनभित्रबाट होइन, नत्र उत्तरहरूले तपाईंको सत्रको सट्टा रुटिनको मालिकको वर्णन गर्नेछन्।
असफल लगइनले यीमध्ये केही पनि चलाउन सक्दैन, र यही त्यो अवस्था हो जहाँ प्रशासकले खाता परिभाषा र सर्भरको जडान प्रमाण जाँच्नुपर्छ। त्यसका लागि तयारी गर्नुहोस्: अस्वीकृत लगइन डिबग गर्ने व्यक्तिसँग सामान्यतया सोध्ने SQL सत्र हुँदैन।
पहुँचलाई प्रमाणीकरणबाट अलग गर्नुहोस्
त्रुटि पाठले तपाईं कुन तहमा छ भनी बताउँछ। अस्वीकृत जडान वा समय समाप्तिको अर्थ क्लाइन्ट कहिल्यै श्रोतासम्म पुग्न सकेन, त्यसैले खाता र त्यसको पासवर्ड अझै प्रश्नमा छैनन्। पहुँच अस्वीकृत भन्ने उत्तरको अर्थ सर्भरले जवाफ दियो, जसले पहुँच सिद्ध गर्छ र खाता, होस्ट मिलान वा प्रमाणपत्रतर्फ सङ्केत गर्छ।
नेटवर्क पूर्वसर्तहरू आफ्नै सूची हुन्: लूपब्याकमा मात्र होइन, इच्छित ठेगानामा बाँधिएको श्रोता, कन्फिगर गरिएको पोर्टमा अनुमति दिइएको ट्राफिक र जवाफका लागि फर्किने मार्ग। प्रत्येक स्वतन्त्र रूपमा असफल हुन सक्छ, र काम गर्ने सुरुङले तीमध्ये कुनैलाई पनि जनाउँदैन। लूपब्याकको श्रोताले स्थानीय जडान स्वीकार गर्छ र हरेक दूरस्थलाई अस्वीकार गर्छ, जसले फायरवाल ब्लकजस्तो देखिने अस्वीकृत जडान उत्पन्न गर्छ।
नेटवर्क टोलीसँग टिकट खोल्नुअघि बाइन्ड ठेगाना जाँच्नुहोस्। डेटाबेस होस्टमा ss -lntp ले कुन ठेगाना र पोर्ट वास्तवमा सुनिरहेका छन् देखाउँछ, र त्यो एउटै पङ्क्तिले अनुमानको सम्पूर्ण वर्ग हटाउँछ।
साँघुरो रूपमा सुधार्नुहोस्, त्यसपछि दुवै दिशामा पुनः परीक्षण गर्नुहोस्
संस्थाको स्वीकृत प्रक्रियाबाट इच्छित होस्ट-योग्य खाता सिर्जना गर्नुहोस्, टिकटमा टाँसिएको साझा प्रमाणपत्रको सट्टा समर्थित भण्डारबाट प्रमाणपत्रसहित। कार्यलाई आवश्यक पर्ने स्किमा सञ्चालन मात्र दिनुहोस्। असफल दूरस्थ लगइनलाई रुट खाता, सबै-दिने नीति वा व्यापक वाइल्डकार्ड होस्ट बनाउँदा परीक्षण पास हुन्छ र तपाईंले परीक्षण गरिरहेको नियन्त्रण हट्छ। हतारमा थपिएको अनुमति त्यही हो जुन पछि कसैले हटाउँदैन।
इच्छित मार्गबाट नयाँ सत्रसँग पुनः परीक्षण गर्नुहोस्, त्यसपछि नकारात्मक अवस्थाहरू जाँच्नुहोस्। अवरुद्ध हुनुपर्ने मार्ग अझै अवरुद्ध रहनुपर्छ, र नदिइएको सञ्चालन अझै अस्वीकृत रहनुपर्छ। यी दुई जाँचले सुधारिएको खातालाई विस्तारित खाताबाट छुट्याउँछन्।
अन्तमा, अवलोकन गरिएको स्रोत ठेगाना र खाताको नाम सँगै अभिलेख गर्नुहोस्। सुरुङले पहुँच दिन्छ; MariaDB ले अझै आफ्नै खाता छान्छ र अधिकृत गर्छ, र अर्को व्यक्तिलाई तपाईंको नतिजा पुनरुत्पादन गर्न दुवै तथ्य चाहिन्छ।