firewalld লিসেনার নিয়ম বনাম ফরওয়ার্ডিং নীতি: প্রতিটি কী করে

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

দুটি নীতি, একটি টানেল

বাইরের নীতি একটি সহজ প্রশ্নের উত্তর দেয়: এই উৎস থেকে আসা প্যাকেট কি এই হোস্টের UDP 1194-এ পৌঁছাতে পারে? ভেতরের নীতি অন্য প্রশ্নের উত্তর দেয়: ওই টানেলের পেছনের প্রমাণিত ক্লায়েন্ট কি এই গন্তব্যে, এই প্রোটোকলে, এই পোর্টে পৌঁছাতে পারে? প্রথমটি একটি সকেট নিয়ে, দ্বিতীয়টি একটি পথ নিয়ে, আর firewalld এদের ভিন্ন অবজেক্ট দিয়ে মডেল করে কারণ এরা ভিন্ন বিন্দুতে নির্ধারিত হয়। একটি এই হোস্টের সকেটের বৈশিষ্ট্য, অন্যটি এর ভেতর দিয়ে যাওয়া পথের।

ব্যবহারিক ফল হলো, কাজ করা টানেল দ্বিতীয় নীতি সম্পর্কে কিছুই বলে না, আর সঠিক দ্বিতীয় নীতি প্রথমটিকে অপ্রয়োজনীয় করে না।

প্রকৃত বাইরের লিসেনারকে অনুমতি দিন

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

firewall-cmd --get-active-zones
firewall-cmd --zone=public --list-all
firewall-cmd --info-service=openvpn

লিসেনারটি সত্যিই ওই জোনে UDP 1194 হলে, ঠিক সেই পোর্ট ও ট্রান্সপোর্ট খুলুন, তারপর পরীক্ষা করার পরে একই নির্দিষ্ট নিয়মটি স্থায়ী করুন। উৎসভিত্তিক বরাদ্দও পরীক্ষা করুন, কারণ উৎস পরিসরের সঙ্গে বাঁধা একটি জোন ইন্টারফেস জোনের দেখার আগেই ট্রাফিক ধরে ফেলতে পারে।

ডিক্রিপ্ট করা গন্তব্যের অনুমোদন আলাদাভাবে দিন

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

অনুমোদিত উৎসগুলো স্পষ্টভাবে সংজ্ঞায়িত করুন এবং বাকি সবকিছু অস্বীকারে নেমে যেতে দিন। বাইরের সার্ভিসের অনুমতি ওই নীতি নয়, জোনের বিন্যাস যতই অন্যরকম দেখাক।

কেন ইন্টারফেসকে বিশ্বাস করা ভুল শর্টকাট

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

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

তিনটি জিনিস যাচাই করুন, যার মধ্যে একটি অস্বীকারও

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

সার্ভারের নোটে জোন, পোর্ট, ট্রান্সপোর্ট ও নীতি অবজেক্ট লিখে রাখুন। নাহলে এই হোস্টে পরের পরিবর্তনটি একই অনুমান থেকে শুরু হবে।