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 எந்த முகவரியும் துறைமுகமும் உண்மையில் கேட்கின்றன என்பதைக் காட்டுகிறது, அந்த ஒரு வரி முழு ஊக வகையையும் நீக்குகிறது.
குறுகியதாகச் சரிசெய்து, பின்னர் இரு திசைகளிலும் மறுசோதனை செய்யுங்கள்
நோக்கமிடப்பட்ட புரவலன்-தகுதியுள்ள கணக்கை அமைப்பின் அங்கீகரிக்கப்பட்ட செயல்முறை மூலம் உருவாக்குங்கள், டிக்கெட்டில் ஒட்டப்பட்ட பகிரப்பட்ட சான்றுக்குப் பதிலாக ஆதரிக்கப்பட்ட சேமிப்பகத்திலிருந்து சான்றுடன். பணிக்குத் தேவையான திட்டச் செயல்பாடுகளை மட்டும் வழங்குங்கள். தோல்வியடைந்த தொலை உள்நுழைவை root கணக்கு, எல்லாவற்றையும்-வழங்கு கொள்கை அல்லது பொதுவான வைல்ட்கார்டு புரவலனாக மாற்றுவது சோதனையைக் கடக்கச் செய்து நீங்கள் சோதித்த கட்டுப்பாட்டை நீக்குகிறது. அவசரமாகச் சேர்த்த அனுமதியே பின்னர் யாரும் நீக்காத அனுமதி.
நோக்கமிடப்பட்ட வழியில் புதிய அமர்வுடன் மறுசோதனை செய்து, பின்னர் எதிர்மறை நிகழ்வுகளைச் சரிபார்க்கவும். தடுக்கப்பட வேண்டிய வழி இன்னும் தடுக்கப்பட்டிருக்க வேண்டும், வழங்கப்படாத செயல்பாடு இன்னும் நிராகரிக்கப்பட வேண்டும். அந்த இரண்டு சரிபார்ப்புகளே சரிசெய்யப்பட்ட கணக்கை விரிவாக்கப்பட்ட கணக்கிலிருந்து பிரிக்கின்றன.
இறுதியாக, கவனிக்கப்பட்ட மூல முகவரியையும் கணக்கின் பெயரையும் சேர்த்துப் பதிவு செய்யுங்கள். சுரங்கப்பாதை அணுகலை வழங்குகிறது; MariaDB இன்னும் தனது சொந்தக் கணக்கைத் தேர்ந்தெடுத்து அங்கீகரிக்கிறது, அடுத்த நபர் உங்கள் முடிவை மீண்டும் உருவாக்க இரண்டு உண்மைகளும் தேவை.