VPN හි ඇති ලැප්ටොප් පරිගණකයකින් පුද්ගලික Cloud SQL අවස්ථාවකට ළඟා වීමට සාධාරණ ක්‍රම දෙකක් තිබේ. එකක් නම් ඔබට දැනටමත් ඇති මාර්ගය හරහා අවස්ථාවේ පුද්ගලික ලිපිනයට සෘජු සම්බන්ධතාවයයි. අනෙක Cloud SQL Auth Proxy වන අතර, එය loopback මත සවන් දෙමින් Cloud SQL වෙත සම්බන්ධතාවය තමන්ම විවෘත කරයි. මේවා තරඟකාරී නිෂ්පාදනවලට වඩා, සත්‍යාපනය කා අතේද සහ මාර්ගය කා අතේද යන ප්‍රශ්නයට වෙනස් පිළිතුරු දෙකකි. වැරදි තේරීම සාමාන්‍යයෙන් ජාල දෝෂයක් ලෙස කියවෙන අවසර දෝෂයක් ලෙස මතු වේ.

මම කණ්ඩායමක් ඉදිරියේ තබන සංසන්දනය මෙයයි, ඉන් පසුව ඇත්තටම තීරණය කරන පරීක්ෂණ.

එකම අවස්ථාවට මාර්ග දෙකක්

සෘජු මාර්ගය ඔබේ ජාලයේ සිට ව්‍යාපෘතියේ VPC වෙත private-services-access මාර්ගය භාවිත කරයි. ඔබේ සේවාලාභියා අවස්ථාවේ පුද්ගලික ලිපිනය සමඟ PostgreSQL කථා කරන අතර, සම්බන්ධතාවය මාර්ගකරණය, firewall නීති සහ දත්ත සමුදා සත්‍යාපන මත ජීවත් වේ හෝ මිය යයි.

ප්‍රොක්සි මාර්ගය එම මාර්ගයම භාවිත කරයි නමුත් ස්ථානීය ක්‍රියාවලියක් එකතු කරයි. ප්‍රොක්සිය ඔබේ යෙදුමේ default credentials සමඟ Google API වෙත සත්‍යාපනය කරයි, සම්බන්ධකය හරහා අවස්ථාවට සම්බන්ධතාවයක් විවෘත කරයි, සහ ඔබේ සේවාලාභියා PostgreSQL ලෙස සලකන loopback වරායක් ලබා දෙයි. පැනීම් දෙකක් තුනක් බවට පත් වන අතර, මැද ඇති එක IAM අවසරය දරයි. VPN මාර්ගය තවමත් ඔබේ නඩත්තුවේ ය, සහ ප්‍රොක්සිය එය කිසිදා එම පරීක්ෂාවට ආදේශකයක් ලෙස නොසලකයි.

එක් එක් මාර්ගය ඇත්තටම අවසර දෙන්නේ කුමක්ද

වඩාත් වැදගත් වෙනස වන්නේ එක් එක් විකල්පය ඔබ වෙනුවෙන් අවසර දිය හැකි දේය:

QuestionDirect private IPAuth Proxy
Who proves identity to the networkYour client, through the VPN and a database loginThe proxy, through IAM to Google's API
IAM role needed for the connectorNoneCloud SQL Client or equivalent
Database user authenticationAlways requiredStill required unless IAM database authentication is enabled
Shape of the local legClient to instanceClient 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 නීතියක් වෙනස් කිරීමට හේතු විය යුතුය.

අදාළ ලිපි