VPN-এর জন্য ক্লাউড সিকিউরিটি গ্রুপ: লিসেনার খুলুন, সব নয়

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

নিয়মের আগে প্রোটোকলের নাম বলুন

একটি নিয়ম হলো একটি প্রোটোকল, একটি পোর্ট রেঞ্জ ও একটি সোর্স। WireGuard UDP-তে শোনে, সাধারণত 51820। OpenVPN সাধারণত UDP বা TCP 1194, এটি কীভাবে কনফিগার হয়েছে তার উপর নির্ভর করে। IPsec-এর IKE বিনিময় দরকার UDP 500 ও 4500-এ, সাথে ESP প্রোটোকল নিজেই, যা পোর্ট নয় বরং একটি প্রোটোকল নম্বর। অন্য নিয়মগুলো TCP বলে TCP অনুমান করাই এমন নিয়ম তৈরি করে যা ঠিক দেখায় কিন্তু কিছুর সাথে মেলে না।

লিসেনার চলমান সার্ভিস থেকে পড়ুন, কোনো টিউটোরিয়াল থেকে নয়. একটি ঠিকানায় বাঁধা ডেমন অন্য ঠিকানায় আসা ট্রাফিক গ্রহণ করবে না।

সোর্সকে ডিজাইন যে ক্লায়েন্ট রেঞ্জ অনুমোদন করে তাতে সীমাবদ্ধ করুন, পুরো ইন্টারনেটে নয়।

সিকিউরিটি গ্রুপ স্টেটফুল; সাবনেট ACL নয়

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

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

কার্যকর পলিসি হলো যা সংযুক্ত তার সমষ্টি, আপনি যেই ফাইল সম্পাদনা করেছেন তা নয়।

হোস্ট ফায়ারওয়াল আলাদা একটি সীমা

ক্লাউড পলিসি ট্রাফিককে নেটওয়ার্ক ইন্টারফেস পর্যন্ত অনুমোদন করে, তারপর অপারেটিং সিস্টেম ঠিক করে ডেমন তা দেখবে কি না। ডিফল্ট ডিনাই পলিসি সহ হোস্ট ফায়ারওয়াল সিকিউরিটি গ্রুপ যে প্যাকেট অনুমোদন করেছে তা ফেলে দেবে, আর ক্লাউড কনসোল কোনো ডিনাই দেখাবে না কারণ তার কখনো মত ছিল না। প্যাকেট যে ক্রমে তাদের মুখোমুখি হয় সেই ক্রমে দুটোই যাচাই করুন।

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

ইন্টারফেসে ক্যাপচার আপনাকে বলে কোন সীমা প্যাকেটটি ফেলেছে।

লিসেনার অনুমোদন করা মানে ক্লায়েন্টদের রাউট করা নয়

যে VPN গেটওয়ে ক্লায়েন্ট ট্রাফিক ফরওয়ার্ড করে তার খোলা পোর্টের বেশি কিছু দরকার। IP ফরওয়ার্ডিং, টানেল ইন্টারফেস থেকে গন্তব্য নেটওয়ার্কে ফ্লো অনুমোদনকারী পলিসি, এবং প্রায়ই ইন্টারফেসে সোর্স-গন্তব্য চেক নিষ্ক্রিয় করা দরকার যাতে প্ল্যাটফর্ম তার প্রতি ঠিকানাহীন ট্রাফিক বাতিল না করে। এর কিছুই লিসেনার নিয়ম তৈরি করে না।

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

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

ফেরার পথ রাখুন, তারপর নিয়ম সংকুচিত করুন

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

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

সংযুক্তিটাও নথিভুক্ত করুন, নইলে প্রতিস্থাপনকারী ইন্টারফেস নীরবে পলিসি হারাবে।