د VPN له لارې د Cloud SQL شخصي IP: هغه لار چې هیڅوک یې صادرول نه کوي

ډېر ټیمونه باور لري چې د Cloud SQL شخصي IP یوازې د VPC له دننه کار کوي، او دا باور پاتې کېږي ځکه چې ناکامي د ډیټابیس د ستونزې په څېر ښکاري. Google د هغو شبکو له لارې لاسرسی مستند کوي چې د Cloud VPN یا Cloud Interconnect له لارې تړل شوې وي. هغو شبکو ته ځانګړې د ډیټابیس ځانګړتیا نه، بلکې دوه د لارې تبادلې ته اړتیا ده چې نیمګړې پرېښودل یې اسانه دي. تونل پورته کېږي، د محاسبې نمونه ځواب ورکوي، او د ډیټابیس اړیکه وخت تېروي — په دقیق ډول هغه ترکیب چې خلک ناسم کنسول ته لېږي.

افسانه: شخصي IP یعنې د VPC لپاره شخصي

شخصي خدمتونو ته لاسرسی د ستاسو شبکه او د Google په ملکیت کې د تولیدوونکې شبکې ترمنځ VPC peering دی. د خدمت لپاره ځانګړی شوی حد د تولیدوونکي په اړخ کې دی، او د نمونې پته د هغه دننه ده. همدا peering لامل دی چې ستاسو په پروژه کې یو ډیټابیس کولی شي په هغه پته کې وي چې ستاسو VPC ورته لارښوونه کوي، که څه هم ستاسو هیڅ روښانه فرعي شبکه یې نه لري.

ځکه چې peering دی، د peering چلند هم لري، په شمول هغه برخه چې ځانګړي لارې په اتوماتيک ډول نه تېرېږي.

افسانه: کارکوونکی تونل د ډیټابیس لار له ځانه وړي

دوه حدود باید دا سفر وباسي. لومړی د کاروونکي مخکښه ده: ستاسو سیمه ایزه شبکه باید Cloud Router ته په ځانګړو مخکښو معلومه وي، ځکه چې د ډیفالټ لاره نشي کولی هغه واردات وړاندې کړي چې تولیدوونکې شبکه د بېرته راستنېدو لپاره ورته اړتیا لري. دویمه ځانګړې شوې د خدمت حد ده، چې بهرنی اړخ باید زده کړي ترڅو د ډیټابیس لپاره د هغه بنډلې د تلو ځای ولري. دا بېلابېلې لارې دي چې په بېلابېلو پولو کې ساتل کېږي، او یوه سمول بله ماتې پریږدي.

د Google په اړخ دا یعنې په اړوندو peering اړیکو کې Export custom routes فعالول او د تونل لپاره د Cloud Router اعلان شوو لارو ته د ځانګړي شوي خدمت حد اضافه کول.

هغه اعلانونه وساتئ چې مخکې موجود دي. د خدمت حد اضافه کول باید د هغو VPC لارو لرې کول نه وي چې همدا BGP غونډه یې د نور ترافیک لپاره وړي، او یو په بشپړه توګه بدل شوی اعلانونو ټولګه دویم خنډ دی چې د لومړي تر شا پټ دی. په بهرني وسیله کې اغېزمنې لارې هم وګورئ، ځکه چې VPN دروازې یا بلې فرعي شبکې ته رسېدل یوازې ترانسپورت ثابتوي.

افسانه: Cloud SQL Auth Proxy شبکه حل کوي

The Auth Proxy ستاسو د اپلیکیشن او نمونې ترمنځ ملاتړ شوی تصدیق او کوډ شوی ترانسپورت برابروي. دا لاره نه جوړوي. هغه پراکسي چې په کوربه کې پیل شي چې شخصي شبکې ته لار نه لري، به هماغسې ناکامه شي لکه مستقیمه اړیکه، او د هغې ثبتونه به د لامل په اړه لږ ګټور وي. پراکسي هغه کوربه ته لېږدول چې اړیکه لري بدلوي چې د لارې کومه برخه باید کار وکړي، او دا یوه ریښتینې ډیزاین پرېکړه ده نه د مخنیوي لار.

هغه څه چې نه یې کوي دا دي چې ناړیکه لپټاپ ته اجازه ورکړي یوازې شخصي نمونه ته ورسیږي.

افسانه: Private Service Connect هماغه قواعد تعقیبوي

Private Service Connect ستاسو په خپله فرعي شبکه کې endpoint او هغه DNS ترتیب چې تاسو کنټرولوئ کاروي، نو هلته لاره یوه عادي لاره ده هغې پتې ته چې تاسو یې مالک یاست. د peering صادراتو تنظیمات په دې ډیزاین نه تطبیق کېږي، او د peering بدلونونو کاپي کول په PSC ځای پرځای کې خطر زیاتوي پرته له دې چې رسېدنه زیاته کړي.

دواړه تاسو ته شخصي پته درکوي؛ ورتهوالی هماغه ځای پای ته رسېږي.

لاره په سم ترتیب کې وآزمویئ

له بهرني کاروونکي لومړی د ډیټابیس TCP endpoint وآزمویئ. بشپړ شوی TCP لاس ورکول یعنې لارښوونه، فایر وال او اورېدونکی ټول په ځای کې دي، او بله آزموینه اجازه شوې تصدیق شوې عملیه ده. په هغه وخت کې د تصدیق ردېدل په حقیقت کې ښه خبر دی، ځکه چې ثابتوي د ډیټابیس اورېدونکي ځواب ورکړی. د ICMP وخت تېرېدل د ډیټابیس لاسرسي په اړه نژدې هېڅ نه وایي، ځکه ډېرې لارې هغه غورځوي او TCP په اسانۍ وړاندې لېږي.

که ستاسو د کاروونکو حدود له RFC 1918 بهر وي، مخکې له دې چې نتیجه وګورئ چې ډیزاین نه ملاتړ کېږي، د لارې د صادراتو او د شبکې د اجازې اضافي غوښتنې وګورئ.

له اړیکې سره څلور شیان ثبت کړئ: بهرنۍ مخکښه، ځانګړې شوې د خدمت حد، اړوندې peering اړیکې او هغه روټر چې اعلان کوي. همدا څلور ټول شخصي لاره تشریح کوي، او هغه افسانه بدلوي چې Cloud SQL یا تل پراکسي ته اړتیا لري یا په بشپړه توګه د VPN له لارې نه رسېدل کېږي.