Cloud SQL Auth Proxy vs డేటాబేస్‌కు నేరుగా VPN మార్గం
Auth Proxy మరియు నేరుగా VPN మార్గం ఒకే సమస్యలోని వేర్వేరు సగభాగాలను పరిష్కరిస్తాయి. మొదట కనెక్టర్ అనుమతి, పోర్టులు మరియు డేటాబేస్ లాగిన్ పోల్చండి.
VPN లో ఉన్న ల్యాప్‌టాప్ నుండి ప్రైవేట్ Cloud SQL ఇన్‌స్టాన్స్‌కు చేరుకోవడానికి రెండు సమంజసమైన మార్గాలు ఉన్నాయి. ఒకటి మీకు ఇప్పటికే ఉన్న మార్గం ద్వారా ఇన్‌స్టాన్స్ ప్రైవేట్ చిరునామాకు నేరుగా కనెక్షన్. రెండవది Cloud SQL Auth Proxy, ఇది loopback పై విని Cloud SQL కు కనెక్షన్‌ను తానే తెరుస్తుంది. ఇవి పోటీ ఉత్పత్తుల కంటే, ఆధారాలు ఎవరి దగ్గర ఉన్నాయి మరియు మార్గం ఎవరి దగ్గర ఉంది అనే ప్రశ్నకు రెండు వేర్వేరు సమాధానాలు. తప్పు ఎంపిక సాధారణంగా నెట్‌వర్క్ లోపంగా చదవబడే అనుమతి లోపంగా కనిపిస్తుంది.
నేను జట్టు ముందు ఉంచే పోలిక ఇది, ఆ తర్వాత నిజంగా నిర్ణయించే తనిఖీలు.
ఒకే ఇన్‌స్టాన్స్‌కు రెండు మార్గాలు
నేరుగా మార్గం మీ నెట్‌వర్క్ నుండి ప్రాజెక్ట్ VPC లోకి వెళ్లే private-services-access మార్గాన్ని ఉపయోగిస్తుంది. మీ క్లయింట్ ఇన్‌స్టాన్స్ ప్రైవేట్ చిరునామాతో PostgreSQL మాట్లాడుతుంది, మరియు కనెక్షన్ రూటింగ్, firewall నియమాలు మరియు డేటాబేస్ ఆధారాలపై జీవిస్తుంది లేదా చనిపోతుంది.
ప్రాక్సీ మార్గం అదే మార్గాన్ని ఉపయోగిస్తుంది కానీ స్థానిక ప్రక్రియను జోడిస్తుంది. ప్రాక్సీ మీ అప్లికేషన్ default credentials తో Google API కి ప్రామాణీకరిస్తుంది, కనెక్టర్ ద్వారా ఇన్‌స్టాన్స్‌కు కనెక్షన్ తెరుస్తుంది మరియు మీ క్లయింట్ PostgreSQL గా పరిగణించే loopback పోర్టును అందిస్తుంది. రెండు దూకుడ్లు మూడు అవుతాయి, మధ్యది IAM అనుమతిని మోస్తుంది. VPN మార్గం ఇంకా మీ నిర్వహణలోనే ఉంటుంది, మరియు ప్రాక్సీ దాన్ని ఆ తనిఖీకి ప్రత్యామ్నాయంగా ఎప్పుడూ భావించదు.
ప్రతి మార్గం నిజంగా ఏమి అనుమతిస్తుంది
అత్యంత ముఖ్యమైన భేదం ఏమిటంటే ప్రతి ఎంపిక మీ తరపున ఏమి అనుమతించగలదు:
| Question | Direct private IP | Auth Proxy |
|---|---|---|
| Who proves identity to the network | Your client, through the VPN and a database login | The proxy, through IAM to Google's API |
| IAM role needed for the connector | None | Cloud SQL Client or equivalent |
| Database user authentication | Always required | Still required unless IAM database authentication is enabled |
| Shape of the local leg | Client to instance | Client to loopback, proxy to instance |
ప్రాక్సీ IAM తనిఖీ మరియు డేటాబేస్ లాగిన్ రెండు వేర్వేరు ద్వారాలు, ఒకదాని గుండా వెళ్లడం మరొకటి తెరవదు. ప్రాక్సీని ఆన్ చేసి అప్లికేషన్ ఖాతా ఇకపై అవసరం లేదని భావించే జట్టు నెట్‌వర్కింగ్‌కు ఎటువంటి సంబంధం లేని పాస్‌వర్డ్ వైఫల్యాలపై మధ్యాహ్నం గడుపుతుంది.
పోర్టులు మరియు మార్గాలు, పక్కపక్కన
ప్రాక్సీకి API కోసం బయటకు వెళ్లే TCP 443 మరియు ఇన్‌స్టాన్స్ కనెక్షన్ కోసం TCP 3307 అవసరం, రెండూ Google యొక్క Auth Proxy అవలోకనంలో వివరించబడ్డాయి. మీ VPN మార్గం రెండవదాన్ని కవర్ చేస్తుంది; మొదటిది సాధారణంగా సాధారణ మార్గం ద్వారా బయటకు వెళ్తుంది.
నేరుగా కనెక్షన్‌కు ఇన్‌స్టాన్స్ PostgreSQL పోర్టు ప్రైవేట్ మార్గం ద్వారా చేరుకోగలిగి ఉండాలి, ఇది పూర్తిగా భిన్నమైన firewall సంభాషణ. మీ నెట్‌వర్క్ జట్టు క్లయింట్ సబ్‌నెట్ల నుండి 443 బయటకు మాత్రమే అనుమతిస్తే, ప్రాక్సీ ఎటువంటి నియమ మార్పు లేకుండా సరిపోతుంది, నేరుగా మార్గం సరిపోదు. ఈ ఒక్క వాస్తవం ఏదైనా నిర్మాణ ప్రాధాన్యత కంటే ఎక్కువసార్లు ఎంపికను నిర్ణయిస్తుంది.
రెండు మార్గాలలో ఏదీ ఇన్‌స్టాన్స్‌కు పబ్లిక్ చిరునామా ఉండాలని కోరదు, ఏదీ దాన్ని జోడించడాన్ని సమర్థించదు.
ప్రాక్సీ సహాయపడని చోటు
ప్రాక్సీ తప్పిపోయిన మార్గాన్ని సరిచేయదు. private-services-access మార్గం లేకపోతే, లేదా VPN దాన్ని తీసుకువెళ్లకపోతే, కనెక్టర్ విఫలమవుతుంది, అయితే స్థానిక శ్రోత ఇంకా అక్కడే కూర్చుని వింటూ ఉంటుంది, గందరగోళంగా ఉండే భాగం అదే.
మీ అప్లికేషన్ మరియు ప్రాక్సీ మధ్య భాగాన్ని కూడా ఇది రక్షించదు. ఒక ల్యాప్‌టాప్‌లో ఆ భాగం loopback మరియు బాగానే ఉంటుంది. సహోద్యోగి చేరుకోగలిగేలా శ్రోతను wildcard చిరునామాకు కట్టినట్లయితే, మీరు ప్రామాణీకరణ లేని డేటాబేస్ గేట్‌వేను నిర్మించి దాన్ని సౌలభ్యం అన్నారు. దాన్ని loopback లోనే ఉంచి, సహోద్యోగి తన సొంత ఆధారాలను పొందనివ్వండి.
మరియు ఇది Private Service Connect మరియు private services access లను పరస్పరం మార్చుకోగలిగేవిగా చేయదు. PSC ఇన్‌స్టాన్స్‌కు దాని సొంత DNS ఏర్పాటు మరియు --private-ip రూపానికి బదులుగా --psc పిలుపు అవసరం.
ఎంచుకోండి, ఆపై ఏ విధంగానైనా ధృవీకరించండి
మార్గంలో IAM, స్వల్పకాలిక ఆధారాలు మరియు ఇన్‌బౌండ్ firewall లో ఎటువంటి మార్పు అక్కరలేనప్పుడు ప్రాక్సీని ఎంచుకోండి.
మద్దతు ఉన్న క్లయింట్ ఇప్పటికే బలమైన డేటాబేస్ ఆధారాలను కలిగి ఉండి, నెట్‌వర్క్ జట్టు పోర్టును తెరవడానికి సిద్ధంగా ఉంటే నేరుగా మార్గాన్ని ఎంచుకోండి. ఏ విధంగానైనా, విజయవంతమైన కనెక్షన్‌కు బదులుగా నిజమైన క్వెరీతో ధృవీకరించండి: కనెక్ట్ అవ్వండి, తెలిసిన పట్టికపై ఒక పఠనాన్ని అమలు చేయండి, మరియు మీ సెషన్ గురించి సర్వర్ ఏమి చూస్తుందో తనిఖీ చేయండి.
VPN తిరిగి కనెక్ట్ అయిన తర్వాత, గడువు ముగిసిన ఆధారం, తప్పిపోయిన ప్రైవేట్ మార్గం మరియు డేటాబేస్ లాగిన్ తిరస్కరణను మూడు వేర్వేరు వైఫల్యాలుగా పరిగణించండి. వాటిలో ఒకటి మాత్రమే నెట్‌వర్క్ సమస్య, మరియు ఒకటి మాత్రమే ఎప్పుడైనా firewall నియమాన్ని మార్చడానికి దారితీయాలి.