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 விதியை மாற்ற வழிவகுக்க வேண்டும்.