VPN வழியாக MySQL: சேவையகத்தைச் சரிபார்க்கவும், குறியாக்கம் மட்டுமல்ல
தவறான ஹோஸ்டுக்கான குறியாக்கமும் தவறே. ssl-mode மதிப்புகளை ஒப்பிடுங்கள், பிறகு நீங்கள் நோக்கிய சேவையகத்தைப் பெயரிடும், அதை நிரூபிக்கும் இணைப்பை இயக்குங்கள்.
நீங்கள் 10.20.4.15 க்கு இணைப்பைச் சேமிக்கிறீர்கள், VPN விழுகிறது, இன்னும் கிளையண்ட் இணைக்கிறது. இது நல்ல செய்தி அல்ல. தனிப்பட்ட முகவரி என்பது நீங்கள் இருக்கும் எந்த ரவுட்டிங் சூழலுக்குள்ளும் ஒரு இடம், மேலும் பல நெட்வொர்க்குகள் அதே வரம்புகளைப் பயன்படுத்துகின்றன. கிளையண்ட் ஒரு MySQL சேவையகத்தை அடைந்தது, ஒருவேளை உங்களுடையதை அல்ல.
திருத்தத்தில் இரண்டு பாதிகள் உள்ளன, அவற்றில் ஒன்று மட்டுமே நெட்வொர்க்கைப் பற்றியது. இணைப்பை அதன் நோக்கிய பாதையில் வைத்திருங்கள், கிளையண்ட் பேசும் சேவையகத்தை அங்கீகரிக்கச் செய்யுங்கள். முதல் பாதி VPN உதவும் இடம்; இரண்டாவது பாதியை உள்ளமைக்க வேண்டும்.
சரியாக எதற்கு குறியாக்கப்பட்டுள்ளது?
TLS உரையாடலை நடுவில் உள்ள யாரிடமிருந்தும் பாதுகாக்கிறது, கிளையண்ட் சரிபார்க்காவிட்டால் முனை தன்னை யார் என்று கூறிக்கொள்கிறது என்பது பற்றி எதுவும் சொல்லவில்லை. நம்பகமான அதிகாரத்திற்கு எதிராகச் சரிபார்க்கப்படும் சான்றிதழ், சான்றிதழ் அந்த அதிகாரத்திடமிருந்து வந்தது என்பதை நிரூபிக்கிறது. நீங்கள் அடைய நோக்கிய ஹோஸ்ட் பெயருக்கு சான்றிதழ் வழங்கப்பட்டது என்பதை அது நிரூபிக்கவில்லை, இவை வேறுபட்ட கேள்விகள்.
இது கோட்பாட்டு இடைவெளி அல்ல. கேப்டிவ் போர்ட்டல்கள், தவறான VRF பிழைகள் மற்றும் ஒன்றோடொன்று மேலெழும் முகவரி திட்டங்கள் அனைத்தும் உங்களுடன் TLS பேச்சுவார்த்தை நடத்த முழுமையாகத் தயாராக இருக்கும் சேவையகத்தை உருவாக்குகின்றன. கிளையண்ட் குறியாக்கத்தை மட்டும் கோரினால், அமர்வு தனிப்பட்டது ஆனால் தவறான தரவுத்தளத்தை நோக்கியது.
எனவே தொடர்புடைய கேள்வி இணைப்பு குறியாக்கப்பட்டுள்ளதா என்பதல்ல, நீங்கள் நோக்கிய அடையாளத்திற்கு குறியாக்கப்பட்டுள்ளதா என்பதே. MySQL இன் கிளையண்டில், அந்த வேறுபாடு முழுவதும் ssl-mode அமைப்பில் வாழ்கிறது.
நடைமுறையில் ஐந்து ssl-mode மதிப்புகள்
ஐந்து மதிப்புகள் உள்ளன, அவற்றில் ஒன்று மட்டுமே இந்த கையேட்டின் கேள்விக்குப் பதிலளிக்கிறது. அட்டவணை ஒவ்வொன்றின் பெயர் குறிப்பிடுவதை அல்ல, உண்மையில் என்ன உத்தரவாதம் அளிக்கிறது என்பதைப் பட்டியலிடுகிறது.
| Mode | What it guarantees |
|---|---|
DISABLED | No TLS at all; everything on the wire is readable |
PREFERRED | Tries TLS and falls back to plaintext when the account and server allow it, so it is not a fail-closed requirement |
REQUIRED | Refuses to connect without TLS, and does not validate the certificate |
VERIFY_CA | Validates the server certificate against the configured CA and does not check the hostname |
VERIFY_IDENTITY | Validates the CA and checks that the certificate names the host the client used |
இந்தக் கட்டுரையின் கேள்விக்கு கடைசி வரி மட்டுமே பதிலளிக்கிறது. PREFERRED தனியாகக் கவனிக்கத் தக்கது, ஏனெனில் அமைதியாக எளிய உரைக்கு விழும் கிளையண்ட் மறுக்கும் கிளையண்டை விட மோசமானது: குறியாக்கம் உள்ளது என்று நீங்கள் நம்புகிறீர்கள், பாக்கெட் பிடிப்பு அதற்கு உடன்படவில்லை.
இன்று இயக்கக்கூடிய இணைப்பு
கீழே உள்ள கட்டளை பயன்படுத்த வேண்டிய வடிவம், இரண்டு இடைநிலைகளுடன்: அங்கீகரிக்கப்பட்ட தரவுத்தளப் பெயர் மற்றும் அங்கீகரிக்கப்பட்ட சேனல் மூலம் பெற்ற CA கோப்பு. இரண்டில் ஒன்றையும் சேவையகம் முதல் தொடர்பில் வழங்குவதிலிருந்து எடுக்கக்கூடாது.
mysql --host=db.corp.example --user=app_reader \
--ssl-mode=VERIFY_IDENTITY \
--ssl-ca=/approved/path/ca.pem --password--password மதிப்பு இல்லாமல் கேட்கிறது, இது ரகசியத்தை செயல்முறை பட்டியலுக்கும் உங்கள் ஷெல் வரலாற்றுக்கும் வெளியே வைக்கிறது. இது பகிரப்பட்ட ஜம்ப் ஹோஸ்ட்களில் பெரிய பயனைத் தரும் சிறிய பழக்கம், அங்கு கட்டளை வரி மற்ற பயனர்களுக்குத் தெரியும்.
இது தோல்வியடையும் போது, பிழை உரை நிகழ்வுகளை உள்ளுணர்வை விடச் சிறப்பாகப் பிரிக்கிறது. CA தோல்வி என்பது சங்கிலி சரிபார்க்கப்படவில்லை என்பதாகும், சேவையகச் சான்றிதழுக்கு எந்த CA கையொப்பமிட்டது என்று பார்க்க வேண்டும். ஹோஸ்ட் பெயர் தோல்வி என்பது சங்கிலி சரியாக உள்ளது, பெயர் பொருந்தவில்லை என்பதாகும், இது பொதுவாக தவறான சேவையகத்திற்கு அல்ல, சரியான சேவையகத்திற்கு தவறான பெயரில் இணைந்தீர்கள் என்று பொருள்.
கட்டளைத் தூண்டல் தோன்றுவது கடவுச்சொல் ஏற்கனவே அனுப்பப்பட்டது என்பதற்கான சான்றல்ல, தோல்வியடைந்த இணைப்பு கிளையண்டிலிருந்து எதுவும் வெளியேறவில்லை என்பதை நிரூபிக்கவில்லை. கடந்த நிகழ்வை மீண்டும் கட்டமைக்கிறீர்கள் என்றால், கிளையண்ட், அதன் உள்ளமைவு, அங்கீகார செருகுநிரல் மற்றும் தோல்வியடைந்த நிலையை அடையாளம் காணுங்கள். இறுதிப் பிழைச் செய்தியிலிருந்து வெளிப்பாட்டை மதிப்பிடுவது ஊகம்.
பெயர் சுரங்கப்பாதையிலிருந்து வரும்போது
உள்ளூர் போர்ட் பகிர்வு அடையாளச் சரிபார்ப்பை மக்களை ஆச்சரியப்படுத்தும் விதத்தில் உடைக்கிறது. ஒரு உள்ளூர் போர்ட்டை தரவுத்தளத்திற்குப் பகிர்ந்து localhost உடன் இணைந்தால், கிளையண்ட் சான்றிதழை localhost க்கு எதிராகச் சரிபார்க்கிறது, அந்தப் பெயருக்கு எந்தச் சான்றிதழும் வழங்கப்படவில்லை. இணைப்பு முற்றிலும் பாதுகாப்பாக இருக்கலாம், சரிபார்ப்பு இருந்தபோதிலும் தோல்வியடையும், இது சரிபார்ப்பு நோக்கியபடி செயல்படுவதாகும்.
இரண்டு நேர்மையான பதில்கள் உள்ளன. பகிரப்பட்ட முனைக்கு லூப்பேக் முகவரிக்குத் தீர்க்கப்பட்டு சேவையகச் சான்றிதழில் தோன்றும் பெயரைக் கொடுங்கள், அல்லது கிளையண்ட் உண்மையான அடையாளத்தைச் சரிபார்க்கும் வகையில் ஹோஸ்ட் பெயரை முதல் முதல் இறுதி வரை பயன்படுத்துங்கள். முதலாவது உருவாக்குநர்களுக்கு வசதியானது, சான்றிதழ் வேலை தேவை; இரண்டாவது சிந்திக்க எளிதானது, தானியங்கிக்கு பெரும்பாலும் சரியான இயல்புநிலை. பகிர்வு வேலை செய்ய சரிபார்ப்பை முடக்குவது நீங்கள் சேர்க்க முயன்ற பண்பைத் தூக்கி எறிகிறது.
ஏற்றுக்கொள்ளல் மூன்று நிபந்தனைகள்
ஏற்றுக்கொள்ளல் சோதனையை மூன்று தனித்தனி கூற்றுகளாக எழுதுங்கள்: இணைப்பு நோக்கிய பாதையைப் பயன்படுத்தியது, குறியாக்கம் விருப்பமல்ல தேவையாக இருந்தது, சேவையகத்தின் அடையாளம் நம்பகமான பொருளுக்கு எதிராகச் சரிபார்க்கப்பட்டது. பச்சை VPN ஐகான் அவற்றில் எதையும் நிறுவவில்லை.
GUI கிளையண்ட்கள் மற்றும் MariaDB க்கு, கொடியின் எழுத்துப்பிழை அப்படியே பொருந்தும் என்று கருதுவதற்குப் பதிலாக விற்பனையாளரின் சொந்த ஆவணங்களைப் பாருங்கள். MySQL குறியாக்கப்பட்ட இணைப்பு ஆவணம் முறைகளுக்கு இடையிலான வேறுபாடுகளையும் CA விநியோகத் தேவையையும் உள்ளடக்குகிறது, உற்பத்தி இணைப்புச் சரத்தை மாற்றும் முன் சரிபார்க்க வேண்டிய குறிப்பு இதுவே.