એક જ વપરાશકર્તા નામ બે જુદા માર્ગોથી લખો અને MariaDB તમને બે જુદા એકાઉન્ટ તરીકે પ્રમાણિત કરી શકે છે. એકાઉન્ટ વપરાશકર્તા અને હોસ્ટ સાથે મળીને કી થાય છે, તેથી 'reporter'@'localhost' અને 'reporter'@'10.90.0.23' અલગ પાસવર્ડ અને અલગ પરવાનગીઓ સાથે અલગ પંક્તિઓ છે. VPN પર, રસપ્રદ પ્રશ્ન એ નથી કે વપરાશકર્તાએ કયું નામ લખ્યું, પરંતુ સર્વરે કયું સ્રોત સરનામું જોયું.

સર્વર ખરેખર જે સ્રોત જુએ છે તે નક્કી કરો

લેપટોપથી નહીં, ડેટાબેઝ હોસ્ટથી પાછળની તરફ કામ કરો. ક્લાયન્ટ માને છે કે તેની પાસે જે સરનામું છે તે ઘણી શક્યતાઓમાંથી ફક્ત એક છે:

PathSource MariaDB sees
Routed tunnel, no translationThe client's inner VPN address
Gateway source translationThe gateway's translated address
SSH local forwardThe SSH server's address
Public exit, no tunnelWhatever 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 હજી પણ પોતાનું એકાઉન્ટ પસંદ કરે છે અને અધિકૃત કરે છે, અને આગલી વ્યક્તિને તમારું પરિણામ પુનઃઉત્પાદિત કરવા બંને હકીકતોની જરૂર છે.

સંબંધિત લેખો