ফায়ারওয়াল নিয়মের পরিবর্তন কাজ করছে না: নিয়মের ক্রম ও সংযোগের অবস্থা

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

নিয়মের ক্রম ও সংযোগের অবস্থা আলাদা ত্রুটি

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

সংযোগ ট্র্যাকিং দ্বিতীয় উপসর্গটি তৈরি করে এবং বাইরে থেকে সেটি হুবহু একই দেখায়। প্রবাহটি স্টেট টেবিলে ঢোকার পর, চেইনের উপরের দিকে থাকা প্রতিষ্ঠিত-বা-সম্পর্কিত অনুমতি আপনার নতুন নিয়ম দেখার আগেই ফিরে যায়। NAT ম্যাপিংয়েরও একই ধর্ম: প্রবাহ শুরু হওয়ার সময়ই রূপান্তরটি স্থির হয়ে গিয়েছিল, তাই সম্পাদিত postrouting নিয়ম ইতিমধ্যে চলা একটি সেশন পুনর্লিখন করে না। এ কারণেই একটি পরিবর্তন 09:00-এ নতুন সংযোগের জন্য কাজ করছে বলে মনে হয়, আর 08:55-এ কেউ খোলা সেশনের জন্য কিছুই করছে না বলে মনে হয়।

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

সক্রিয় রুলসেট পড়ুন, আপনি যে ফাইলটি সম্পাদনা করেছেন সেটি নয়

কার্নেল এখন যা প্রয়োগ করছে তা দিয়ে শুরু করুন। সংরক্ষিত কিন্তু কখনো প্রয়োগ না করা কনফিগারেশন আশ্চর্যজনক সংখ্যক অপরিবর্তিত আচরণ ব্যাখ্যা করে, এবং এটি বাদ দিতে একটিমাত্র কমান্ড লাগে:

nft list ruleset
iptables-save

তারপর জিজ্ঞাসা করুন, আপনার নিয়মে আদৌ পৌঁছানো হচ্ছে কি না। প্যাকেট কাউন্টার সরাসরি এর উত্তর দেয়, এবং অভিপ্রায় নিয়ে যেকোনো যুক্তির চেয়ে ভালো উত্তর দেয়:

iptables -L FORWARD -v -n --line-numbers
nft list chain inet filter forward

সত্যিকারের পরীক্ষার চেষ্টার পরেও শূন্য প্যাকেটের লকডাউন নিয়ম কোনো নীতি-সমস্যা নয়, এটি অবস্থান-সমস্যা। এটি সরানো এক লাইনের পরিবর্তন, আর সিনট্যাক্সই ঠিক সেটি যা মূল বাগটি ঘটিয়েছিল। iptables-এ -I ঢোকায় আর -A শেষে যোগ করে; nftables-এ insert চেইনের শুরুতে নিয়ম বসায় আর add শেষে যোগ করে। যখন একটি নিয়মকে জিততেই হবে, তখন হঠাৎ লোড হওয়া ক্রমে ভরসা না করে সেটি স্পষ্ট করে বলুন।

প্রবাহটি ট্র্যাক হচ্ছে কি না তা প্রমাণ করুন

নিয়মকে দোষ দেওয়ার আগে যাচাই করুন ট্রাফিকটি আদৌ ট্র্যাক করা সংযোগ কি না। পুরো স্টেট টেবিল উগরে না দিয়ে নির্দিষ্ট প্রবাহটির কথা জিজ্ঞাসা করুন:

conntrack -L -p tcp --dport 1194
conntrack -E -p tcp --dport 1194

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

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

কিছু পথ ট্র্যাক হয় না, এবং তারা উল্টোভাবে আচরণ করে। raw টেবিলে notrack চিহ্নিত ট্রাফিক, সাধারণ হুক এড়িয়ে যাওয়া কিছু টানেল, এবং দুই গেটওয়ের মধ্যে প্রবাহ ভাগ করা অসমমিত রাউটিং—সবই এমন প্যাকেট তৈরি করে যা একবারে একটি করে মূল্যায়িত হয়, বা এমন অবস্থা যা দুই প্রান্তেই কখনো তৈরি হয় না। প্রতি প্যাকেটে কাউন্টার নড়লে, ক্রমকে সন্দেহ করার আগে সেই ধরনের পথকে সন্দেহ করুন।

ফিরে আসার পথসহ নতুন প্রবাহ থেকে পরীক্ষা করুন

রিমোট অ্যাক্সেস কেটে দিতে পারে এমন নিয়ম পরীক্ষার আগে একটি পুনরুদ্ধার পথ তৈরি করুন: প্রোভাইডার কনসোল, সিরিয়াল কনসোল, আউট-অব-ব্যান্ড ম্যানেজমেন্ট ঠিকানা, বা এমন দ্বিতীয় ইন্টারফেস যা নিয়মটি মেলাতে পারে না। রোলব্যাক টাইমার একটি যুক্তিসঙ্গত সঙ্গী, কারণ পরীক্ষার মাঝপথে আপনার সেশন মরে গেলেও এটি আগের রুলসেট ফিরিয়ে আনবে।

তারপর এমন বিনিময় দিয়ে পরীক্ষা করুন যা ইতিমধ্যে অবস্থা দ্বারা আচ্ছাদিত হতে পারত না। ক্লায়েন্ট বিচ্ছিন্ন করে আবার সংযুক্ত করুন যাতে নতুন পাঁচটি তৈরি হয়, এবং তা ঘটার সময় দুই প্রান্তই দেখুন:

tcpdump -ni eth0 'tcp port 1194'
journalctl -k -n 50 --no-pager

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

নিয়মের সঙ্গে উদ্দেশ্য ও অবস্থান লিখে রাখুন

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

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