শুধু NEW নিয়ম সব WAN পথ বন্ধ করে না

WAN-এ নতুন বহির্গামী সংযোগ প্রত্যাখ্যান করা fail-closed নীতির মতো দেখায়, কিন্তু এটি যতটা মনে হয় তার চেয়ে সংকীর্ণ প্রতিশ্রুতি। আগে থেকেই থাকা ফ্লোর প্যাকেট এই নিয়মে পড়ে না, আর অনেক উত্তরও পড়ে না। এই ফাঁকটি সহজে চোখে পড়ে না, কারণ নিয়মটি পড়া হয় যেন তা ইন্টারফেস ঢাকে, তার উপরকার একটি সংযোগ-অবস্থা নয়। অবস্থা-মিলকে রায় হিসেবে পড়াই মিথ্যা বদ্ধতার অনুভূতি তৈরি করে।

অবস্থা একটি মিলের শর্ত, রায় নয়

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

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

নিয়মটি তার আশপাশসহ পড়ুন

ব্লকের আগে বসানো প্রতিষ্ঠিত ও সংশ্লিষ্ট ট্রাফিকের প্রশস্ত অনুমোদন ব্লকটি মূল্যায়িত হওয়ার আগেই প্যাকেটটিকে ঢুকিয়ে দেয়। পরের কোনো নিয়ম থেকে অবস্থা-শর্ত সরালে তা বদলাবে না, কারণ মূল্যায়ন সেখানে পৌঁছায়ই না। ফল নির্ধারণ করে ক্রম, আর কোন প্যাকেট ওই ক্রমে পৌঁছায় তা নির্ধারণ করে অবস্থা-মিল।

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

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

নিষেধাজ্ঞা অবস্থা থেকে স্বাধীনভাবে প্রকাশ করুন

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

drop-এর বদলে reject বেছে নিলে মিলে যাওয়া ট্রাফিক কীভাবে ব্যর্থ হয় তা বদলায়, কিন্তু নিয়মটি যে প্যাকেট নির্বাচন করে তার সেট বড় করে না। প্রত্যাখ্যাত সংযোগ আর নীরব টাইমআউট একই নির্বাচনের দিকে ইঙ্গিত করা ভিন্ন লক্ষণ।

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

দলে আসলে কে আছে তা যাচাই করুন

উদাহরণটি একটি ইন্টারফেস থেকে একটি প্রিফিক্সের ফরওয়ার্ডেড IPv4 ট্রাফিক কভার করে। এটি IPv6, দ্বিতীয় আপলিং, বা রাউটার নিজে যে ট্রাফিক তৈরি করে সে সম্পর্কে কিছুই বলে না। DNS রিজলভার হিসেবে কাজ করা রাউটার নিজের আপস্ট্রিম কোয়েরি পাঠায়, আর সেগুলো ফরওয়ার্ড চেইন দিয়ে আদৌ যায় না।

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

iptables -S FORWARD
iptables -L FORWARD -v -n
cat /proc/net/nf_conntrack | grep -c ESTABLISHED

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