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-এর বিজ্ঞাপিত রুটে বরাদ্দ সার্ভিস রেঞ্জ যোগ করা।

ইতিমধ্যে থাকা বিজ্ঞাপনগুলো ধরে রাখুন। সার্ভিস রেঞ্জ যোগ করার ফলে একই BGP সেশন অন্য ট্রাফিকের জন্য বহন করা VPC রুট সরিয়ে ফেলা উচিত নয়, আর পুরো বিজ্ঞাপন সেট প্রতিস্থাপন করা প্রথম সমস্যার পেছনে লুকানো দ্বিতীয় বিভ্রাট। বাইরের ডিভাইসে কার্যকর রুটও দেখুন, কারণ 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-এর ওপর দিয়ে আদৌ পৌঁছানো যায় না।