EC2-এর শুধু-VPN নিয়ম: সংযুক্ত প্রতিটি সিকিউরিটি গ্রুপকে একমত হতে হবে

আপনি VPN ক্লায়েন্ট পুলের জন্য একটি ইনবাউন্ড নিয়ম যোগ করেন, কিছুই সরান না, তবুও সার্ভিসটি ইন্টারনেট থেকে পৌঁছানো যায়। কিছুই ভাঙা নেই। সিকিউরিটি গ্রুপে এমন কোনো ওভাররাইড, অগ্রাধিকার বা চূড়ান্ত ডিনাই নেই যা সংকীর্ণ নিয়ম জিততে পারে। ইনস্ট্যান্সে সংযুক্ত প্রতিটি গ্রুপ তার নিজের অনুমতিগুলো একটি সম্মিলিত সেটে যোগ করে, আর আপনি যে বিস্তৃত নিয়মটি ভুলে গেছেন সেটি এখনও সেই সেটেই আছে। ইনস্ট্যান্সকে শুধু-VPN বানানোর অর্থ সবগুলো যাচাই করা, একটিতে আরও ভালো শোনানো নিয়ম যোগ করা নয়।

নিয়ম লেখার আগে সার্ভিসটি লিখে নিন

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

অনুবাদ ও রাউটিং জড়িত হয়ে গেলে এই দুই ঠিকানা মানুষের প্রত্যাশার চেয়ে বেশি বার আলাদা হয়ে যায়।

তিনটি সোর্স মডেল, তিনটি আলাদা নিয়ম

প্রাইভেট রাউটেড অ্যাক্সেসে ইনস্ট্যান্সটি ক্লায়েন্ট পুল বা কর্পোরেট রেঞ্জ পায়, পথটি কীভাবে রাউট ও অনুবাদ হয় তার ওপর নির্ভর করে। কর্পোরেট এগ্রেস দিয়ে পৌঁছানো পাবলিক এন্ডপয়েন্টে ইনস্ট্যান্সটি বরং কর্পোরেট NAT ঠিকানা দেখে, এবং কেবল যদি ওই গন্তব্যটি সত্যিই VPN পথ ব্যবহার করে, কারণ স্প্লিট টানেলিং সেটিকে হোম সংযোগে রেখে দিতে পারে। ম্যানেজড Client VPN এন্ডপয়েন্টে নথিভুক্ত অ্যাসোসিয়েশন ও টার্গেট-নেটওয়ার্ক মডেল প্রযোজ্য, আর ক্লায়েন্ট ঠিকানা আসে কনফিগার করা ক্লায়েন্ট CIDR থেকে।

যা কাজ করে না তা হলো VPN গেটওয়েকে সিকিউরিটি গ্রুপের সোর্স হিসেবে উল্লেখ করা। গ্রুপ রেফারেন্স VPC বা পিয়ার্ড নেটওয়ার্কের ভেতরের ইলাস্টিক নেটওয়ার্ক ইন্টারফেসের সাথে মেলে, আর প্যাকেট ফরওয়ার্ড করা গেটওয়ে তাদের একটি নয়।

প্রতিটি সংযুক্ত গ্রুপ জুড়ে সম্মিলনটি পড়ুন

ইনস্ট্যান্সটি খুলুন, এর নেটওয়ার্ক ইন্টারফেস খুঁজুন, এবং এতে সংযুক্ত প্রতিটি সিকিউরিটি গ্রুপ তালিকাভুক্ত করুন। প্রতিটির জন্য আপনার প্রোটোকল ও পোর্ট কভার করে এমন প্রতিটি নিয়ম পরীক্ষা করুন, বিস্তৃত পোর্ট রেঞ্জ ও উভয় ঠিকানা পরিবারসহ। 0.0.0.0/0 থেকে আসা IPv4 নিয়ম আপনাকে ::/0 পরীক্ষা করা থেকে অব্যাহতি দেয় না, আর সব ট্রাফিক অনুমোদনকারী নিয়ম পোর্টের প্রশ্নটি সম্পূর্ণ লুকিয়ে ফেলে। এই ইনভেন্টরির পরেই আপনি বলতে পারবেন সার্ভিসটির কার্যকর অনুমতি কী।

AWS নিয়ম রেফারেন্স সিকিউরিটি গ্রুপকে শুধু-অনুমোদনকারী হিসেবে বর্ণনা করে এবং বলে যে সব সংযুক্ত গ্রুপের নিয়ম একত্রিত হয়, আর এই ব্যর্থতার পেছনের পুরো কৌশল সেটাই।

নেটওয়ার্ক ACL একটি আলাদা, স্টেটলেস নীতি যাতে ক্রমবদ্ধ অনুমোদন ও ডিনাই এন্ট্রি থাকে, এবং সেগুলো ইনস্ট্যান্সের বদলে সাবনেটে মূল্যায়িত হয়।

ডিনাই দেয়াল দিয়ে উত্তর দেবেন না

আপনি যে ফায়ারওয়ালে অভ্যস্ত তা নকল করতে সাবনেট-ব্যাপী NACL ডিনাই যোগ করা ভুল হাতিয়ার এবং ঝুঁকিপূর্ণ। NACL এন্ট্রি ক্রমবদ্ধ ও স্টেটলেস, তাই বিদ্যমান অনুমোদনের উপরে বসানো ডিনাই নীরবে অসম্পর্কিত ট্রাফিক ভাঙে, যার মধ্যে আপনি যে সেশনগুলো ধরে রাখতে চাইছিলেন তার ফেরার পথও পড়ে। বিস্তৃত সিকিউরিটি গ্রুপ অনুমতিটি যে গ্রুপের, সেখানেই ঠিক করুন, তারপর ACL সত্যিই ডিজাইনের অংশ না হলে সেটিকে অপরিবর্তিত রাখুন।

ইনস্ট্যান্স থেকে পাবলিক ঠিকানা সরানো আরও শক্তিশালী নিশ্চয়তা, এবং এটি একটি স্থাপত্য পরিবর্তনও যার প্রশাসনিক ও অ্যাপ্লিকেশন পরিণতি আছে, অনুমোদন তালিকার একটি চেকবক্স নয়।

নতুন সেশনে পরীক্ষা করুন এবং ঢোকার একটি পথ রাখুন

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

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