EC2 অ্যাক্সেসিবিলিটি জোন জুড়ে: VPN-এর আগে রাউটিং যাচাই করুন
একই VPC-তে দুটি EC2 ইনস্ট্যান্স ইতিমধ্যেই জোন জুড়ে প্রাইভেট রাউটিং শেয়ার করে। আরেকটি টানেল যোগ করার আগে সাবনেট টেবিল ও অ্যাক্সেস নিয়ম যাচাই করুন।
দুটি EC2 ইনস্ট্যান্সের মধ্যে VPN সফটওয়্যার ইনস্টল করার আগে একটি প্রশ্নের উত্তর দিন: তারা কি একই VPC-তে? যদি থাকে, প্রাইভেট পথ ইতিমধ্যেই বিদ্যমান এবং জোন জুড়ে বসানো তা বদলায় না। এই পরিস্থিতিতে বেশিরভাগ কাজ হলো প্রতিটি সাবনেট আসলে কোন রাউট টেবিল ব্যবহার করে তা নিশ্চিত করা, তারপর জানা যে ব্যর্থতাটি আদৌ রাউটিং সমস্যা ছিল কি না। এই নির্দিষ্ট প্রশ্নের জন্য টানেল সাধারণত ভুল উত্তর।
যাচাই 1: একই VPC নাকি ভিন্ন VPC
একটি VPC আঞ্চলিক এবং অ্যাক্সেসিবিলিটি জোন জুড়ে বিস্তৃত, আর প্রতিটি সাবনেট ঠিক একটি জোনের অন্তর্গত। একই VPC-এর ভিন্ন জোনে থাকা দুটি ইনস্ট্যান্স তবুও একই প্রাইভেট রাউটিং ডোমেনের ভিতরে থাকে।
ভিন্ন VPC কখনোই কেবল একটি অঞ্চল বা জোন লেবেল ভাগ করার কারণে প্রাইভেট রুট পায় না। সেই ক্ষেত্রে একটি সমর্থিত সংযোগ এবং আলাদা রুট ও অনুমতি সংক্রান্ত কাজ প্রয়োজন, যা একটি পৃথক সিদ্ধান্ত।
যাচাই 2: সাবনেট রাউট টেবিল কী বলে
প্রকৃত মান দিয়ে বিন্যাসটি লিখে রাখুন। একটি VPC, যার ঠিকানা 10.60.0.0/16 এবং সাবনেট 10.60.1.0/24 ও 10.60.2.0/24, ইনস্ট্যান্স 10.60.1.10 ও 10.60.2.20 -কে VPC-এর লোকাল রুট দিয়ে একটি পথ দেয়।
তারপর প্রথমে পাওয়া টেবিলটির বদলে উভয় সাবনেটের সাথে যুক্ত টেবিলগুলি পরীক্ষা করুন। আরও নির্দিষ্ট ইনস্পেকশন বা অ্যাপ্লায়েন্স রুট বেসলাইনকে অগ্রাহ্য করতে পারে, এবং লোকাল রুটের লক্ষ্যও নতুন কনফিগারেশনে প্রতিস্থাপিত হতে পারে। কনসোলে কোথাও দৃশ্যমান একটি লোকাল রুট প্রমাণ করে না যে উভয় ওয়ার্কলোডই এটি ব্যবহার করে।
VPC যে প্রাইভেট ঠিকানা ও নাম সত্যিই বরাদ্দ করে সেগুলিই ব্যবহার করুন। প্রাইভেট ঠিকানাকে 10 দিয়ে শুরু হতে হয় না, আর স্মৃতি থেকে একটি ঠিকানা বানিয়েই একটি সচল পরিবেশের ভুল রোগনির্ণয় হয়।
যাচাই 3: রাউটিং নাকি অনুমোদন
রাউটিং কেবল প্যাকেটটিকে লক্ষ্যের নেটওয়ার্ক ইন্টারফেস পর্যন্ত পৌঁছায়। লক্ষ্যের সিকিউরিটি গ্রুপকে এখনো উৎস ও পরিষেবাটি গ্রহণ করতে হবে, উৎসের ইগ্রেস নিয়মকে অনুরোধটি অনুমোদন করতে হবে, এবং যেকোনো নেটওয়ার্ক ACL-কে উভয় দিক অনুমোদন করতে হবে, কারণ ACL স্টেটলেস।
তার পরে আছে গেস্ট ফায়ারওয়াল, লিসেনার বাইন্ডিং এবং অ্যাপ্লিকেশনের নিজস্ব পরিচয়। প্রত্যেকেই এমন একটি অনুরোধ প্রত্যাখ্যান করতে পারে যা রাউটিং নিখুঁতভাবে পৌঁছে দিয়েছে।
গ্রহণযোগ্যতা হতে হবে প্রকৃত অ্যাপ্লিকেশন অপারেশন। সফল ping অ্যাপ্লিকেশন অ্যাক্সেস দেয় না বা TLS নাম ও প্রমাণপত্র সঠিক তা প্রমাণ করে না, আর অবরুদ্ধ ping প্রতিষ্ঠা করে না যে প্রতিটি প্রাইভেট পরিষেবা বন্ধ।
যাচাই 4: সত্যিই কি আলাদা সংযোগ দরকার
VPN এখনো নকশায় থাকতে পারে, তবে একটি উল্লিখিত কারণে: এই VPC-কে অফিসের সাথে যুক্ত করা, ল্যাপটপ গ্রহণ করা বা ওভারলে প্রয়োজন মেটানো। এই কারণটি সাধারণ একই-VPC যোগাযোগ থেকে আলাদা।
এটাও মনে রাখুন VPC কী নয়। এটি গৃহস্থালি ইথারনেট সেগমেন্টের সম্প্রসারণ নয়। যে অ্যাপ্লিকেশন ব্রডকাস্ট ডিসকভারির উপর নির্ভর করে তার মূল্যায়নের জন্য আলাদা প্রয়োজন আছে। এটি রাউটিং বাগ নয়, বরং নকশার ফাঁক।
যাচাই 5: এনক্রিপশনের প্রশ্ন
প্রাইভেট ঠিকানা ও অনুমোদন নিয়ম অ্যাপ্লিকেশন স্তরে ক্রিপ্টোগ্রাফিক সুরক্ষা সম্পর্কে কিছুই বলে না। যদি ডেটার প্রান্ত-থেকে-প্রান্ত সুরক্ষা দরকার হয়, তা আসে সেই প্রোটোকল ও পরিচয় মডেল থেকে যা পরিষেবাটি সত্যিই সমর্থন করে।
নকশা নোটে নেটওয়ার্ক-স্তর ও অ্যাপ্লিকেশন-স্তরের দাবি আলাদা রাখুন, কারণ এগুলি মিশিয়ে ফেললেই পর্যালোচনা এমন সুরক্ষার দাবি করে বসে যা কেউ বাস্তবায়ন করেনি।
কী লিখে রাখবেন
উভয় সাবনেট আইডি, প্রতিটির সাথে যুক্ত রাউট টেবিল, সিকিউরিটি গ্রুপ রেফারেন্স এবং যে অ্যাপ্লিকেশন অপারেশন আপনি পরীক্ষা করেছেন তা লিখে রাখুন। এগুলি চারটি তথ্য, এবং এগুলিই এই পথ নিয়ে ভবিষ্যতের বেশিরভাগ বিতর্ক মিটিয়ে দেয়।
কেবল জোন বসানো কখনোই আপনাকে VPN যোগ করতে বলে না, আর প্রাইভেট অনুরোধ কেন ব্যর্থ হলো তাও কখনো ব্যাখ্যা করে না।