আপনি একটি টানেল ইন্টারফেস আশা করেন, সেটি খোঁজেন, আর ফায়ারওয়ালে মেলানোর মতো কিছু পাওয়া যায় না। এটি পলিসি-ভিত্তিক গেটওয়ে-এর জন্য স্বাভাবিক: এনক্রিপ্ট করা বিনিময় ভৌত ইন্টারফেসে আসে, এবং এরপর ফরওয়ার্ড হওয়া ডিক্রিপ্ট করা ভেতরের প্যাকেটও একই ইন্টারফেসে আসতে দেখা যায়। tun0 নেই, কারণ কিছুই এটি তৈরি করেনি।

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

দুটি প্যাকেট, একটি ইন্টারফেস

আগমনের দিকটি কল্পনা করুন। ESP বা UDP-এনক্যাপসুলেটেড প্যাকেট আসে, কার্নেল মিলে যাওয়া পলিসি খুঁজে সেটি ডিক্রিপ্ট করে এবং পরিষ্কার প্যাকেটটি ফরওয়ার্ডিং পথে দেয়। কেবল ইন্টারফেসের নাম দেখে এমন নিয়ম ওই প্যাকেটকে একই তারে আসা অন্য যেকোনো ট্রাফিক থেকে আলাদা করতে পারে না।

এটিকে আলাদা করে প্যাকেটের সঙ্গে যুক্ত আগমনের নিরাপত্তা পথের প্রসঙ্গ। nftables এটি meta ipsec exists হিসেবে দেখায়, যা সত্য হয় যখন প্যাকেটটি IPsec নিরাপত্তা পথ দিয়ে এসেছে। এটি ক্লায়েন্ট পুল, গন্তব্য ও সেবার সঙ্গে মিলিয়ে দিন, নিয়মটি নিরাপদ হওয়ার মতো যথেষ্ট নির্দিষ্ট হয়ে যাবে।

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

ফরওয়ার্ডিং নিয়মটি লিখুন

ধরে নিন 10.90.0.0/24-এ ক্লায়েন্টসহ একটি প্রমাণিত IPv4 রিমোট-অ্যাক্সেস সেবা এবং 203.0.113.40-এ একটি অনুমোদিত গন্তব্য আছে। ওই প্রবাহের জন্য নিয়মের একটি খণ্ড এমন দেখায়।

meta ipsec exists ip saddr 10.90.0.0/24 \
  ip daddr 203.0.113.40 tcp dport 443 \
  oifname "eth0" counter accept

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

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

বাইরের বিনিময়ের অনুমতিগুলো আলাদা। গেটওয়ের ইনপুট পথের সেই IKE ও ESP বা UDP-এনক্যাপসুলেশন পোর্টগুলো দরকার যা এটি আসলে ব্যবহার করে, এবং ওই অনুমতিগুলো ভেতরের ডিক্রিপ্ট করা প্যাকেট সম্পর্কে কিছুই অনুমোদন করে না। দুটো মিশিয়ে ফেললে কর্মক্ষম টানেল এমন ফায়ারওয়াল পায় যা সবকিছু ফরওয়ার্ড করে।

আগমনের প্রসঙ্গ নির্গমনের প্রসঙ্গ নয়

একই ধরনের অভিব্যক্তি rt ipsec দিয়ে অন্য দিকটি ঢাকে, যা একটি প্যাকেট যে নির্গমন নিরাপত্তা সংযোগ ব্যবহার করবে তা বর্ণনা করে। এটি ভিন্ন প্রশ্নের উত্তর দেয়: এই প্যাকেট কোথা থেকে এসেছে নয়, বরং এর পরের ধাপে এটি সুরক্ষিত থাকবে কি না।

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

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

NAT কোনো ফায়ারওয়াল সিদ্ধান্ত নয়

ব্যক্তিগত ক্লায়েন্ট পুল থেকে ইন্টারনেটমুখী ট্রাফিকের সাধারণত উৎস অনুবাদ দরকার যাতে উত্তর ফিরতি পথ পায়। কিন্তু অন্য নির্গমন IPsec পলিসির জন্য নির্বাচিত ট্রাফিককে তার প্রয়োজনীয় অব্যাহতি ধরে রাখতে হয়, আর পরবর্তী সুরক্ষা সিদ্ধান্তের কথা না ভেবে প্রতিটি ব্যক্তিগত উৎস মাস্কারেড করা তা ভেঙে দেয়।

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

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

সঠিক ভেতরের সেবাটি যাচাই করুন

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

nftables রেফারেন্স meta ipsec, rt ipsec এবং দিক-নির্দিষ্ট অভিব্যক্তিগুলো নথিভুক্ত করে, আর আপনার ইনস্টল করা সংস্করণের সঙ্গে সিনট্যাক্স মেলানোর জায়গা ঠিক সেখানেই। পরিধিটাও স্পষ্ট রাখুন: এটি একটি IPv4 উদাহরণ, IPv6 সম্পর্কে এটি কিছু বলে না, আর এটি ইচ্ছামতো পাবলিক পোর্ট ফরওয়ার্ডিংকে VPN সেবার অংশ বানায় না।

সম্পর্কিত নিবন্ধ