UFW-এর before.rules-এ VPN NAT কোথায় বসে এবং কীভাবে পরীক্ষা করবেন

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

শেল কমান্ড কোনো রিস্টোর ফাইল নয়

iptables -t nat দিয়ে শুরু হওয়া একটি লাইন iptables বাইনারির জন্য নির্দেশ, আর UFW যে ফাইল পড়ে সেটি একটি সম্পূর্ণ রুলসেটের বর্ণনা। পার্থক্যটি কেবল বাহ্যিক নয়: রিস্টোর ফরম্যাটকে জানতে হয় এটি কোন টেবিলে আছে, কোন চেইনগুলো বিদ্যমান এবং টেবিলটি কোথায় শেষ হয়। ওই নথিতে পেস্ট করা একটি কমান্ড হয় সিনট্যাক্স ত্রুটি, নয়তো আরও খারাপ, ভুল টেবিলে সংযুক্ত একটি নিয়ম। ফ্রেমওয়ার্ক এই ফাইলগুলো রিস্টোর টুলের মাধ্যমে লোড করে ঠিক কারণ সেগুলো ক্রমিক নয়, ঘোষণামূলক।

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

ফ্র্যাগমেন্টটি বিদ্যমান টেবিল অংশের ভিতরে রাখুন

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

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.55.0.0/24 -o ens3 -j MASQUERADE
COMMIT

উপরের পুল ও ইন্টারফেস আপনার নিজের জন্য প্লেসহোল্ডার; কপি করার মতো অংশটি হলো গঠন। ফাইলে যদি ইতিমধ্যে একটি *nat অংশ থাকে, তবে দ্বিতীয় একটি খোলার বদলে ওই অংশের ভিতরেই নিয়মটি যোগ করুন, কারণ ফরম্যাট প্রতি টেবিলে একটি COMMIT আশা করে এবং একই টেবিলের জন্য দুটি অংশ হলো এমন একটি মেরামত যা ঘটার অপেক্ষায় আছে। ডিস্ট্রিবিউশনের চেইন সংজ্ঞাগুলো অক্ষত রাখুন, ভেন্ডর তার নিজের ইন্টিগ্রেশনের জন্য যোগ করা যেকোনোটি সহ। UFW ফ্রেমওয়ার্ক ম্যানুয়াল before, user ও after ফাইল এবং একটি মিলতে থাকা COMMIT-এর প্রয়োজনীয়তা নথিভুক্ত করে।

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

প্রার্থীটি প্রয়োগ না করেই পরীক্ষা করুন

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

sudo cp /etc/ufw/before.rules /root/before.rules.bak
sudo iptables-restore --test < /root/before.rules.bak
echo "exit: 0"

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

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

ফরওয়ার্ডিং, NAT ও অ্যাক্সেস পলিসি আলাদা রাখুন

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

sysctl net.ipv4.ip_forward
sudo iptables -t nat -S POSTROUTING
sudo iptables -S FORWARD

ওই তিনটি আউটপুট একসাথে পড়ুন, এক এক করে নয়। ফরওয়ার্ডিং নিষ্ক্রিয় থাকা একটি masquerade নিয়ম এমন ক্লায়েন্ট তৈরি করে যা সংযুক্ত হয় কিন্তু কোথাও পৌঁছায় না, যা ক্লায়েন্টের দিক থেকে ঠিক রাউটিং ত্রুটির মতো দেখায় এবং মানুষকে ভুল ফাইলে পাঠায়। ফিল্টার টেবিলই হলো যেখানে অতিরিক্ত প্রশস্ত accept লুকিয়ে থাকে, তাই সেখানে থাকার সময় এর ডিফল্ট পলিসি দেখুন।

রিলোড, প্রত্যাখ্যান ও VPN হারানো যাচাই করুন

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

sudo ufw reload
sudo ufw status verbose
sudo iptables -t nat -L POSTROUTING -n -v

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

IPv4 NAT IPv6 সম্পর্কে কিছু বলে না, তাই নিয়মের সঙ্গে একই নোটে উভয় পরিবারের জন্য উদ্দিষ্ট কভারেজ উল্লেখ করুন। সুসংগতভাবে পরিচালিত পলিসি হলো লক্ষ্য, এবং যে ফ্র্যাগমেন্ট হঠাৎ পার্স হয়েছে তা তার প্রমাণ নয়।