Cloud SQL Auth Proxy بمقابلہ ڈیٹا بیس تک براہِ راست VPN راستہ
Auth Proxy اور براہِ راست VPN راستہ ایک ہی مسئلے کے مختلف نصف حل کرتے ہیں۔ پہلے کنیکٹر کی اجازت، پورٹس اور ڈیٹا بیس میں لاگ اِن کا موازنہ کریں۔
VPN پر موجود لیپ ٹاپ سے نجی Cloud SQL انسٹانس تک پہنچنے کے دو معقول راستے ہیں۔ ایک تو اُس راستے سے انسٹانس کے نجی پتے پر براہِ راست رابطہ جو آپ کے پاس پہلے سے ہے۔ دوسرا Cloud SQL Auth Proxy ہے، جو loopback پر سنتا ہے اور Cloud SQL سے رابطہ خود کھولتا ہے۔ یہ مقابلہ کرنے والی مصنوعات سے زیادہ اِس سوال کے دو مختلف جواب ہیں کہ اسناد کس کے پاس ہیں اور راستہ کس کے پاس ہے۔ غلط انتخاب عام طور پر اجازت کی خرابی کی صورت میں سامنے آتا ہے، جسے نیٹ ورک کی خرابی کی طرح پڑھا جاتا ہے۔
یہ ہے وہ موازنہ جو میں کسی ٹیم کے سامنے رکھوں گا، اور اُس کے بعد وہ جانچیں جو واقعی فیصلہ کرتی ہیں۔
ایک ہی انسٹانس تک دو راستے
براہِ راست راستہ آپ کے نیٹ ورک سے منصوبے کے VPC تک جانے والے private-services-access راستے کو استعمال کرتا ہے۔ آپ کا کلائنٹ انسٹانس کے نجی پتے کے ساتھ PostgreSQL بولتا ہے، اور رابطہ روٹنگ، firewall قواعد اور ڈیٹا بیس کی اسناد پر زندہ رہتا ہے یا مر جاتا ہے۔
پراکسی راستہ وہی راستہ استعمال کرتا ہے مگر ایک مقامی عمل شامل کرتا ہے۔ پراکسی آپ کی ایپلیکیشن کی default credentials کے ساتھ Google API پر تصدیق کرتی ہے، کنیکٹر کے ذریعے انسٹانس سے رابطہ کھولتی ہے اور ایک loopback پورٹ فراہم کرتی ہے جسے آپ کا کلائنٹ PostgreSQL سمجھتا ہے۔ دو چھلانگیں تین ہو جاتی ہیں، اور درمیانی والی 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 قاعدہ بدلنے تک لے جانا چاہیے۔