UFW নিয়মে OpenVPN গেটওয়েকে একটি LAN-এ সীমাবদ্ধ করুন

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

আগে টপোলজি ও অনুমতি লিখে রাখুন

উদাহরণটি ব্যবহার করে একটি Community OpenVPN সার্ভার, যাতে ইউজারস্পেস TUN ডিভাইসের নাম tun0, ক্লায়েন্ট পুল 10.77.0.0/24, এবং একটি সংযুক্ত সাবনেট 192.168.60.0/24 যা আছে lan0-এ। IPv4 ফরওয়ার্ডিং আগেই কাজ করে এবং LAN-এর কাছে পুলে ফেরার রুট আগেই আছে, তাই এখানে কিছুই তাদের মধ্যে অনুবাদের ওপর নির্ভর করে না।

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

গার্ডগুলোকে UFW-এর আগাম গ্রহণের আগে বসান

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

*filter বিভাগে /etc/ufw/before.rules, বিদ্যমান ঘোষণাগুলোর পাশে এবং যেকোনো নিয়ম-লাইনের আগে দুটি চেইন ঘোষণা করুন।

:vpn-src-guard - [0:0]
:vpn-reply-guard - [0:0]

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

-A ufw-before-input -i tun0 -j DROP
-A ufw-before-forward -i tun0 -j vpn-src-guard
-A ufw-before-forward -o tun0 -j vpn-reply-guard

-A vpn-src-guard -o lan0 -d 192.168.60.0/24 -s 10.77.0.0/24 -m conntrack --ctdir ORIGINAL -j RETURN
-A vpn-src-guard -j DROP

-A vpn-reply-guard -i lan0 -d 10.77.0.0/24 -s 192.168.60.0/24 -m conntrack --ctstate RELATED,ESTABLISHED --ctdir REPLY -j RETURN
-A vpn-reply-guard -j DROP

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

প্রতিটি গার্ড কী গ্রহণ ও প্রত্যাখ্যান করে তা পড়ুন

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

পিয়ার-টু-পিয়ার প্যাকেট tun0-এ ঢোকে ও বেরোয়, তাই গন্তব্য যাচাই পর্যন্ত পৌঁছানোর আগেই এটি LAN ইন্টারফেস পরীক্ষায় ব্যর্থ হয়। LAN থেকে ক্লায়েন্টের দিকে নতুন সংযোগও রিপ্লাই দিকের পরীক্ষায় ব্যর্থ হয়, যা ডিফল্টভাবে বিপরীত কলব্যাক পথ বন্ধ করে দেয়।

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

সাবনেট অনুমোদন করুন এবং পাশের দরজাগুলো বন্ধ করুন

আগে রুট অনুমতির প্রিভিউ দেখুন, তারপর প্রয়োগ করতে প্রিভিউ ফ্ল্যাগ নামিয়ে দিন: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24। এরপর ইউজার নিয়মের ক্রম পর্যালোচনা করুন, কারণ আগের প্রত্যাখ্যান পরের অনুমতির ওপর এখনো জেতে। পুরো সাবনেটের অনুমতিও ভুল আকৃতি যখন কেবল একটি হোস্টের HTTPS পোর্ট পৌঁছানোর যোগ্য হওয়া উচিত।

খেয়াল করুন ইনপুট ড্রপ কী করে: টানেল ক্লায়েন্টরা গেটওয়ের নিজের কোনো সেবাতেই পৌঁছাতে পারে না, যার মধ্যে তার LAN ঠিকানায় বাঁধা DNS লিসেনারও আছে। সেখানে DNS হোস্ট করতে ড্রপের আগে ইচ্ছাকৃত ব্যতিক্রম এবং সংশোধিত অনুমতি-চুক্তি দরকার। UFW যদি IPv6 পরিচালনা করে, তবে tun0 এর জন্য before6.rules ফাইলেও মিলানো ড্রপ যোগ করুন, কারণ IPv4 গন্তব্যের তালিকা IPv6 প্যাকেট সম্পর্কে কিছুই বলে না।

প্রিভিউ নয়, লোড হওয়া নীতি যাচাই করুন

রিলোডের প্রিভিউ দেখুন, রক্ষণাবেক্ষণ উইন্ডোতে তা প্রয়োগ করুন, এবং লাইভ রুলসেট পড়ুন।

sudo ufw --dry-run reload
sudo ufw show raw

নিশ্চিত করুন টানেল গার্ডগুলো ডিফল্ট স্টেট ও ICMP অনুমতির আগে দেখা যাচ্ছে। সাধারণ ufw status হাতে-সম্পাদিত before নিয়ম দেখায় না, তাই অপারেটররা মনে করেন নিয়ম নেই, অথচ সেটি আসলে লোড হয়েছে। খণ্ড খুঁজতে না গিয়ে কাঁচা তালিকাটি ওপর থেকে নিচে পড়ুন। গার্ডগুলো যদি স্টেট অনুমতির পরে দেখা যায়, তবে সীমাটি ফাইল যা বলছে তা করছে না।

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

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