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 పంపిణీ అవసరాన్ని కవర్ చేస్తుంది, ఉత్పత్తి కనెక్షన్ స్ట్రింగ్ను మార్చే ముందు తనిఖీ చేయవలసిన సూచన ఇదే.