Google Cloud VPC-তে দূরবর্তী ডেভেলপার অ্যাক্সেস: সঠিক পথ বেছে নিন

একজন ডেভেলপারের একটি SSH সেশন, একটি ডেটাবেস পোর্ট বা ডজনখানেক প্রাইভেট সার্ভিসে বিস্তৃত অ্যাক্সেস দরকার, এবং ওই অনুরোধগুলোর প্রত্যেকটি একই প্রশ্নের মতো দেখায়। তা নয়। গন্তব্য, প্রোটোকল ও সংশ্লিষ্ট পরিচয়ই ঠিক করে কোন Google Cloud অ্যাক্সেস পথটি মানানসই, আর ডিফল্টে সবচেয়ে প্রশস্তটি বেছে নিলে এমন কাজ তৈরি হয় যা আপনার নিজের করা দরকার ছিল না।

গন্তব্য ও প্রোটোকল লিখে রাখুন

কাজের সত্যিই যে প্রাইভেট ঠিকানা, পোর্ট ও প্রোটোকল দরকার তা তালিকাভুক্ত করুন, তারপর চিহ্নিত করুন কোন পরিচয়গুলো আলাদাভাবে প্রমাণীকরণ করতে হবে। একটি ডেটাবেস পোর্ট ও একটি প্রাইভেট DNS জোন ভিন্ন প্রয়োজন, আর UDP সার্ভিস নিচের একটি বিকল্পকে সম্পূর্ণভাবে বাদ দেয়। লিখিত তালিকা এটাও দেখায় আপনি কী দিচ্ছেন না। পর্যালোচকরা ঠিক এই অংশটাই জিজ্ঞেস করেন।

লিসেনার খোলার আগেই এটি করুন। তালিকাটি পরে গ্রহণযোগ্যতার পরীক্ষায় পরিণত হয়, আর সংকীর্ণ টানেলকে কেবল ভাগ্যক্রমে কাজ করা প্রশস্ত টানেল থেকে আলাদা করার একমাত্র নির্ভরযোগ্য উপায় এটি।

অল্প কিছু TCP সার্ভিসের জন্য IAP

Identity-Aware Proxy TCP ফরওয়ার্ডিং সার্ভিসটিকে ইন্টারনেটে উন্মুক্ত না করেই উপযুক্ত VM রিসোর্সে একটি প্রমাণীকৃত টানেল দেয়। দৈনন্দিন রূপটি হলো gcloud compute ssh instance-1 --tunnel-through-iap --zone=us-central1-a, আর একটি মাত্র পোর্ট gcloud compute start-iap-tunnel instance-1 5432 --local-host-port=localhost:15432 --zone=us-central1-a দিয়ে স্থানীয়ভাবে ফরওয়ার্ড করা যায়।

তিনটি বিষয় মিলতে হবে: আহ্বানকারীর IAP টানেল অ্যাক্সেসর ভূমিকা দরকার, ফায়ারওয়ালকে IAP সোর্স রেঞ্জ গ্রহণ করতে হবে, এবং গন্তব্যটি ইনস্ট্যান্সে পৌঁছানোযোগ্য হতে হবে। টানেল তৈরির অনুমোদন কোনো ডেটাবেস ক্রেডেনশিয়াল, SSH লগইন বা RDP সেশন নয়, তাই অ্যাপ্লিকেশন প্রমাণীকরণকে তার নিজের জায়গায় রাখুন।

IAP TCP ফরওয়ার্ডিং তৃতীয় স্তরের VPN নয়। এটি TCP-কে নির্বাচিত গন্তব্যে বহন করে, নির্বিচার IP ট্রাফিক বা UDP নয়, এবং কোনো অ্যাপ্লিকেশনের অনেক সার্ভিস জুড়ে প্রাইভেট DNS দরকার হলে এটি খারাপ মানায়।

বিস্তৃত নাগালের জন্য রিমোট-অ্যাক্সেস VPN

একাধিক গন্তব্য, প্রোটোকল বা প্রাইভেট DNS জোন দরকার হলে VM বা সমর্থিত অ্যাপ্লায়েন্সে স্পষ্টভাবে পরিচালিত একটি রিমোট-অ্যাক্সেস VPN ভালো রূপ। এই স্থাপনাটি Google-পরিচালিত Cloud VPN থেকে আলাদা: ক্লায়েন্ট পরিচয় নিবন্ধন, সফটওয়্যার আপডেট, ক্লায়েন্ট রুট ও VPC ফেরত-রুট আপনার দায়িত্বে।

শুধু পাবলিক লিসেনার নয়, পুরো তালিকাটি পরিকল্পনা করুন। টানেল পুল, তার দিকে ফেরত যাওয়া VPC রুট, ফরওয়ার্ডিং নিয়ন্ত্রণ, DNS রিজলিউশন ও প্রতি-সার্ভিস অ্যাক্সেস নীতি অন্তর্ভুক্ত করুন। যে VPN সংযোগ করে কিন্তু অভ্যন্তরীণ নাম সমাধান করতে পারে না, সেটি ডেভেলপারের কার্যপ্রবাহকে ঠিক ততটাই সম্পূর্ণভাবে ব্যর্থ করে যতটা কখনো সংযোগ না-করা VPN করে।

Cloud VPN একটি সাইট গেটওয়ে, ল্যাপটপ প্রোফাইল নয়

Google Cloud VPN IPsec-এর মাধ্যমে পিয়ার গেটওয়েগুলোকে সংযুক্ত করে, আর এর সাধারণ প্রশ্নোত্তর সেই সাইট-থেকে-সাইট ভূমিকাকে ক্লায়েন্ট-থেকে-গেটওয়ে অ্যাক্সেস থেকে আলাদা করে। টানেল তৈরি করলে কর্মচারী ল্যাপটপে যে প্রোফাইল আমদানি করেন তা তৈরি হয় না। কেউ Cloud VPN প্রোফাইল চাইলে এই পার্থক্যটি গুরুত্বপূর্ণ। উত্তরটি ভিন্ন একটি পণ্য।

গেটওয়ে যা ভালো করে, তা হলো অফিস নেটওয়ার্কের পেছনের মেশিনগুলোকে VPC-তে একটি রুট দেওয়া। এটি প্রত্যেক কর্মচারীকে প্রমাণীকরণ করে না বা অ্যাপ্লিকেশন অনুমতি দেয় না, তাই ওই নীতিগুলো নেটওয়ার্ক ও অ্যাপ্লিকেশন স্তরে থাকে যেখানে পরিচয়ভিত্তিকভাবে প্রয়োগ করা যায়।

যাচাই করুন ও লিখে রাখুন

প্রথমে সবচেয়ে সংকীর্ণ গন্তব্য পরীক্ষা করুন, তারপর যেটির DNS দরকার, তারপর যে গন্তব্য প্রত্যাখ্যাতই থাকতে হবে। প্রতিটি পরীক্ষা সেই একই ক্লায়েন্ট থেকে চালান যা উৎপাদনে পথটি ব্যবহার করবে, কারণ প্রশাসকের ওয়ার্কস্টেশন থেকে সফল পরীক্ষা ভিন্ন নেটওয়ার্কের ডেভেলপার ল্যাপটপ সম্পর্কে খুব কম প্রমাণ করে।

নির্বাচিত মডেল, এটি যে গন্তব্যগুলো কভার করে, যে পরিচয়গুলো প্রমাণীকরণ করে এবং পথ অনুপলব্ধ হলে ব্যর্থতার আচরণ লিখে রাখুন। এই রেকর্ডই পরবর্তী অনুরোধকে নথিভুক্ত নকশায় একটি গন্তব্য যোগ করার বদলে টানেলটি নীরবে প্রশস্ত করার হাত থেকে বিরত রাখে।