VPC-তে VPN কাজ করে, কিন্তু ম্যানেজড সেবার সময় শেষ হয়
টানেল আপনার প্রান্তে শেষ হয়, প্রোভাইডারের সামনের দরজায় নয়। রুট পরিবর্তনের আগে লক্ষ্যকে VM-এ হোস্ট করা, VPC-তে সংযুক্ত বা শুধু পাবলিক হিসেবে শ্রেণীবদ্ধ করুন।
VPN-এর মাধ্যমে একটি ম্যানেজড ডেটাবেসে পৌঁছানো সাধারণত এমন একটি কারণে ব্যর্থ হয় যা কেউ রানবুকে লেখেনি: টানেল আপনার নেটওয়ার্কের প্রান্তে শেষ হয়, অথচ সেবাটি কখনও তার আপনার দিকে ছিল না। রুট টেবিল সঠিক দেখায়, টানেল সক্রিয় বলে জানায়, এবং সংযোগ তবুও সময় শেষ করে। নিচের চারটি পরীক্ষা ক্রমে করুন এবং যে পরীক্ষার সফলতার শর্ত পূরণ হয় না সেখানেই থামুন, কারণ এর পরের প্রতিটি পরীক্ষা ধরে নেয় আগেরগুলো পূর্ণ হয়েছে।
পরীক্ষা এক: শেষ বিন্দুটি আসলে কোথায় থাকে?
একটি VPN গেটওয়ে এমন দুটি নেটওয়ার্ক যুক্ত করে যাদের ঠিকানা আপনি নিয়ন্ত্রণ করেন। ম্যানেজড সেবা প্রোভাইডারের নিজের সামনের দরজার পেছনে চলে, এবং সেই দরজা পণ্যের ওপর নির্ভর করে তিনটি আকারের একটি নেয়। কোন আকারের সঙ্গে কাজ করছেন না জানলে কোনো রুট কাজই সাহায্য করবে না, কারণ ব্যর্থতা রুটের ব্যর্থতাই নাও হতে পারে।
| Shape | What it means | Pass condition |
|---|---|---|
| Software on your VM | Ordinary subnet addressing | Route and security group permit the client |
| Attached to your VPC | Private, but only inside that VPC | Endpoint associated, source allowed, route present |
| Provider-hosted, public endpoint | Optional private link, not private by default | A private endpoint exists and DNS points at it |
নষ্ট হওয়া বেশিরভাগ বিকেল আসে এই শ্রেণীবিভাগ বাদ দিয়ে সোজা রুট টেবিলে যাওয়া থেকে। প্রোভাইডার-হোস্টেড সেবা যার পাবলিক শেষ বিন্দু আছে, চিত্র যা-ই বলুক আপনার টানেলের পেছনে নেই, এবং VPC-তে সংযুক্ত সেবা কখনও পাবলিক DNS উত্তরে দেখা যাবে না।
পরীক্ষা দুই: ElastiCache-এর মতো VPC-তে সংযুক্ত সেবা
এ ধরনের ক্যাশ আপনার নিজের VPC-র ভেতরে ঠিকানা পায় এবং ইন্টারনেটমুখী কোনো শ্রোতাই তাদের নেই। একই VPC-তে শেষ হওয়া ক্লায়েন্ট VPN তাদের কাছে পৌঁছাতে পারে, তবে তিনটি শর্ত একসঙ্গে মিললেই। ক্যাশের শেষ বিন্দুটি আপনার টানেল যে সাবনেট দেখতে পায় তার সঙ্গে যুক্ত থাকতে হবে, তার নিরাপত্তা গোষ্ঠীকে আপনার ক্লায়েন্টরা যে ঠিকানা থেকে আসে তা অনুমোদন করতে হবে, এবং ক্লায়েন্ট পাশে ক্যাশ সাবনেট ঢেকে রাখা রুট দরকার।
সাধারণ ভুল হলো ধরে নেওয়া যে কাছাকাছি কোথাও একটি সংযোগও গণ্য হয়। VPN-কে অন্য VPC-তে যুক্ত করা, বা কেবল peering-এর ওপর নির্ভর করা ক্যাশের নিরাপত্তা গোষ্ঠী বা তার সাবনেটের রুট টেবিল আপনার ক্লায়েন্ট পর্যন্ত বিস্তৃত করে না। বিদ্যমান টানেল অন্য কোথাও শেষ হলে সেই VPC-র ভেতরে রাখা জাম্প হোস্ট বা VPN সার্ভারই স্বাভাবিক বিকল্প। এমন বিকল্প ডিজাইন নয়, একটি চক্কর, এবং রানবুকে তা-ই বলে চিহ্নিত করা উচিত।
পরীক্ষা তিন: পাবলিক নামযুক্ত PaaS শেষ বিন্দু
Azure Database for PostgreSQL একটি পাবলিক সার্ভার নাম উপস্থাপন করে। এটি আপনাকে এমন ব্যক্তিগত ঠিকানা দেয় না যা hosts ফাইলে পিন করে গেটওয়ে দিয়ে রুট করা যায়। ভার্চুয়াল নেটওয়ার্ক সেবা শেষ বিন্দু সীমিত করে কোন সাবনেট একটি রিসোর্সে পৌঁছাতে পারে; তারা VPN দিয়ে আসা অন-প্রেমিস ক্লায়েন্টকে অনুমোদন করে না।
ব্যক্তিগত অ্যাক্সেস পাওয়ার মানে ব্যক্তিগত শেষ বিন্দু বা ব্যক্তিগত লিঙ্ক ডিজাইন আনা, তারপর ব্যক্তিগত DNS জোন যোগ করা যাতে পাবলিক নাম ইন্টারনেটের বদলে ওই শেষ বিন্দু দিয়ে উত্তর দেয়। সেবা শেষ বিন্দুর নিয়মের সঙ্গে যুক্ত VPN আরেকটি স্থাপত্য যা কেবল চিত্রে একই রকম দেখায়। App Service একই যুক্তি বিপরীত দিক থেকে অনুসরণ করে: VNet সংহতি অ্যাপকে VNet-এ বাইরের কল করতে দেয়, এবং এটি আপনার টানেল থেকে ভেতরে আসা ব্যক্তিগত পথ তৈরি করে না। তাই ভেতরে আসা ব্যক্তিগত অ্যাক্সেসের জন্য ব্যক্তিগত শেষ বিন্দু, App Service পরিবেশ বা অ্যাপের সামনে রাখা গেটওয়ে দরকার, আর এর মধ্যে কোনটি ব্যবহার করতে পারবেন তা প্ল্যানের ওপর নির্ভর করে।
পরীক্ষা চার: নিজের সামনের দরজাওয়ালা পণ্য
Firebase Hosting-কে Cloud VPN-এ যুক্ত করা যায় না, কারণ হোস্টিং স্তর একটি বৈশ্বিক সামনের অংশ, প্রকল্পের VPC-র ভেতরের কিছু নয়। নথিভুক্ত বিকল্প হলো নিয়ন্ত্রিত প্রবেশ বিন্দু নিজেই তৈরি করা, প্রক্সি ইনস্ট্যান্স বা বাকেটে সমর্থিত লোড ব্যালেন্সার দিয়ে। যেভাবেই হোক সাইটটি খাঁটি হোস্টিং পণ্য থাকা ছেড়ে এমন পরিকাঠামো হয়ে যায় যা এখন আপনি চালান। টানেল এটি ঢেকে দেবে বলে কেউ প্রতিশ্রুতি দেওয়ার আগে এই বিনিময়ের নাম দেওয়া উচিত।
Private API Gateway VPC সেবার দিকের বেশি কাছে: interface ধরনের VPC শেষ বিন্দু এমন হোস্টনাম প্রকাশ করে যার উত্তরগুলো ব্যক্তিগত ঠিকানা, এবং আপনার প্রাঙ্গণ থেকে ট্রাফিক টানেল বা নিবেদিত আন্তঃসংযোগ দিয়ে আসে। শেষ বিন্দুটি API-র সঙ্গে যুক্ত থাকতে হবে, এবং সার্টিফিকেট ও হোস্টনাম কলকারীরা যে কাস্টম ডোমেইন ব্যবহার করে তার সঙ্গে মিলতে হবে।
Google Cloud VPN টানেল নামের সঙ্গে নয়, পিয়ার IP ঠিকানার সঙ্গে বাঁধা পড়ে। DNS ফরওয়ার্ডিং আলাদাভাবে কনফিগার করা হয়, তাই টানেল সম্পূর্ণ সুস্থ থাকলেও দূরের ব্যক্তিগত জোনে অনুসন্ধান এখনও ব্যর্থ হতে পারে।
তারপর সীমানা খুঁজুন
VPC-র ভেতরের VM থেকে একই সংযোগ চালান। সেখানে সফল হয়ে VPN ক্লায়েন্ট থেকে ব্যর্থ হলে, ব্যবধান ক্লায়েন্টের পথ ও সেবার শেষ বিন্দুর মধ্যে: একটি রুট, নিরাপত্তা গোষ্ঠী, শেষ বিন্দু নীতি বা নাম। দুটি প্রচেষ্টাই ব্যর্থ হলে সেই নেটওয়ার্কের কিছুই সেবায় পৌঁছাতে পারে না, এবং VPN কখনও বাধা ছিল না।
getent hosts db.internal.example
nc -vz db.internal.example 5432নামের অনুসন্ধান ও পোর্ট পরীক্ষা আলাদাভাবে করুন, কারণ সেগুলো ভিন্ন কারণে ব্যর্থ হয় এবং জোড়াটি বলে দেয় পথের কোন অর্ধেক ভাঙা। পাবলিক ঠিকানায় সমাধান হওয়া একটি নাম আপনাকে বলে যে ব্যক্তিগত DNS জোন চালু নেই।