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 নিয়ম পরিবর্তনের দিকে নিয়ে যাওয়া উচিত।