VPN کے ذریعے Cloud SQL کا نجی IP: وہ راستہ جسے کوئی برآمد نہیں کرتا

بہت سی ٹیمیں سمجھتی ہیں کہ Cloud SQL کا نجی IP صرف VPC کے اندر سے کام کرتا ہے، اور یہ یقین برقرار رہتا ہے کیونکہ ناکامی ڈیٹا بیس کے مسئلے جیسی لگتی ہے۔ Google ان نیٹ ورکس سے رسائی کی دستاویز کرتا ہے جو Cloud VPN یا Cloud Interconnect کے ذریعے منسلک ہوں۔ ان نیٹ ورکس کو کوئی خاص ڈیٹا بیس خصوصیت نہیں، بلکہ دو راستوں کا تبادلہ درکار ہے جنہیں آدھا کنفیگر چھوڑ دینا آسان ہے۔ ٹنل اوپر آتا ہے، کمپیوٹ انسٹینس جواب دیتے ہیں، اور ڈیٹا بیس کنکشن وقت سے گزر جاتا ہے — یہی وہ امتزاج ہے جو لوگوں کو غلط کنسول تک بھیجتا ہے۔

افسانہ: نجی IP کا مطلب VPC کے لیے نجی ہے

نجی سروسز تک رسائی آپ کے نیٹ ورک اور Google کی ملکیت والے پروڈیوسر نیٹ ورک کے درمیان VPC پیئرنگ ہے۔ سروس کے لیے مختص رینج پروڈیوسر کی طرف ہوتی ہے، اور انسٹینس کا پتہ اسی کے اندر ہوتا ہے۔ اسی پیئرنگ کی وجہ سے آپ کے پروجیکٹ کا ڈیٹا بیس ایسے پتے پر بیٹھ سکتا ہے جہاں آپ کا VPC راستہ بناتا ہے، حالانکہ آپ کے کسی واضح سب نیٹ میں وہ نہیں ہوتا۔

چونکہ یہ پیئرنگ ہے، اس کا پیئرنگ رویہ بھی ہے، بشمول وہ حصہ جہاں حسب ضرورت راستے خودبخود عبور نہیں کرتے۔

افسانہ: کام کرنے والی ٹنل ڈیٹا بیس کا راستہ ساتھ لے جاتی ہے

دو رینجوں کو یہ سفر طے کرنا ہے۔ پہلی کلائنٹ پری فکس ہے: آپ کے مقامی نیٹ ورک کو مخصوص پری فکس کے ساتھ Cloud Router کو معلوم ہونا چاہیے، کیونکہ ڈیفالٹ راستہ وہ درآمد فراہم نہیں کر سکتا جو پروڈیوسر نیٹ ورک کو واپسی کے راستے کے لیے درکار ہے۔ دوسری مختص سروس رینج ہے، جسے بیرونی فریق کو سیکھنا ہوگا تاکہ ڈیٹا بیس کی طرف اس کے پیکٹوں کے پاس جانے کی جگہ ہو۔ یہ مختلف حدوں پر برقرار رکھے جانے والے مختلف راستے ہیں، اور ایک کو ٹھیک کرنا دوسرے کو ٹوٹا چھوڑ دیتا ہے۔

Google کی طرف اس کا مطلب متعلقہ پیئرنگ کنکشنز پر Export custom routes فعال کرنا اور ٹنل کے لیے Cloud Router کے اعلان کردہ راستوں میں مختص سروس رینج شامل کرنا ہے۔

جو اشتہارات پہلے سے موجود ہیں انہیں برقرار رکھیں۔ سروس رینج شامل کرنے سے وہ VPC راستے نہیں ہٹنے چاہئیں جو وہی BGP سیشن دوسری ٹریفک کے لیے لے کر چلتا ہے، اور مکمل طور پر بدلا گیا اشتہارات کا مجموعہ پہلی خرابی کے پیچھے چھپا دوسرا تعطل ہے۔ بیرونی ڈیوائس پر مؤثر راستے بھی دیکھیں، کیونکہ VPN گیٹ وے یا کسی دوسرے سب نیٹ تک پہنچنا صرف ترسیل ثابت کرتا ہے۔

افسانہ: Cloud SQL Auth Proxy نیٹ ورک حل کرتا ہے

The Auth Proxy آپ کی ایپلیکیشن اور انسٹینس کے درمیان معاون تصدیق اور خفیہ کردہ ترسیل فراہم کرتا ہے۔ یہ راستہ نہیں بناتا۔ نجی نیٹ ورک تک راستہ نہ رکھنے والے ہوسٹ پر شروع کیا گیا پراکسی بالکل ویسے ہی ناکام ہوگا جیسے براہ راست کنکشن ہوتا، اور اس کے لاگ وجہ کے بارے میں کم مددگار ہوں گے۔ پراکسی کو ایسے ہوسٹ پر منتقل کرنا جس میں کنیکٹیوٹی ہے، بدلتا ہے کہ راستے کا کون سا حصہ کام کرنا چاہیے، اور یہ کوئی حیلہ نہیں بلکہ حقیقی ڈیزائن فیصلہ ہے۔

جو یہ نہیں کرتا وہ یہ ہے کہ منقطع لیپ ٹاپ کو صرف نجی انسٹینس تک پہنچنے دے۔

افسانہ: Private Service Connect وہی قواعد اپناتا ہے

Private Service Connect آپ کے اپنے سب نیٹ میں endpoint اور آپ کے کنٹرول والی DNS ترتیب استعمال کرتا ہے، اس لیے وہاں جانے والا راستہ آپ کی ملکیت والے پتے تک عام راستہ ہے۔ پیئرنگ ایکسپورٹ ترتیبات اس ڈیزائن پر لاگو نہیں ہوتیں، اور پیئرنگ تبدیلیوں کو PSC تعیناتی میں نقل کرنا رسائی بڑھائے بغیر خطرہ بڑھاتا ہے۔

دونوں آپ کو نجی پتہ دیتے ہیں؛ مشابہت وہیں ختم ہو جاتی ہے۔

راستے کو درست ترتیب میں جانچیں

بیرونی کلائنٹ سے پہلے ڈیٹا بیس کا TCP endpoint جانچیں۔ مکمل شدہ TCP ہینڈ شیک کا مطلب ہے کہ روٹنگ، فائر وال اور سننے والا سب جگہ پر ہیں، اور اگلا امتحان اجازت یافتہ تصدیق شدہ عمل ہے۔ اس وقت تصدیق کا مسترد ہونا دراصل اچھی خبر ہے، کیونکہ یہ ثابت کرتا ہے کہ ڈیٹا بیس کا سننے والا جواب دے چکا ہے۔ ICMP کا وقت گزرنا ڈیٹا بیس تک رسائی کے بارے میں تقریباً کچھ نہیں کہتا، کیونکہ بہت سے راستے TCP کو آسانی سے آگے بھیجتے ہوئے اسے گرا دیتے ہیں۔

اگر آپ کی کلائنٹ رینجیں RFC 1918 سے باہر ہیں، تو یہ نتیجہ اخذ کرنے سے پہلے کہ ڈیزائن غیر معاون ہے، اضافی روٹ ایکسپورٹ اور نیٹ ورک اجازت کی ضروریات کا جائزہ لیں۔

کنکشن کے ساتھ چار اشیاء درج کریں: بیرونی پری فکس، مختص سروس رینج، متعلقہ پیئرنگ کنکشنز اور اعلان کرنے والا روٹر۔ یہ چاروں پورا نجی راستہ بیان کرتے ہیں، اور اس افسانے کی جگہ لیتے ہیں کہ Cloud SQL کو یا تو ہمیشہ پراکسی درکار ہے یا VPN پر بالکل پہنچا نہیں جا سکتا۔