UFW কিল সুইচ আপনার VPN ব্লক করছে? পিয়ারকে অনুমতি দিন

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

কেন tun0-এ অনুমতি প্রথমে কিছুই মেলায় না

সেশন থাকার পরে ক্লায়েন্ট tun0 তৈরি করে। যে ডেটাগ্রামগুলি সেই সেশন তৈরি করে সেগুলি 1194 পোর্টে প্রোভাইডারের ঠিকানায় পাঠানো সাধারণ UDP প্যাকেট, এবং সেগুলি ভৌত উৎস ঠিকানা নিয়ে wlan0 বা eth0 দিয়ে বের হয়। allow out on tun0 কেবল সেই ট্রাফিকের সাথে মেলে যার আউটগোয়িং ইন্টারফেস tun0, তাই হ্যান্ডশেকের সময় এটি কিছুই মেলায় না।

এর উপরে default deny outgoing বসালে বাইরের প্যাকেটগুলি ইন্টারফেস আবির্ভাবের আগেই ফেলে দেওয়া হয়। ক্লায়েন্ট আবার চেষ্টা করে, সময় শেষ হয়, এবং TLS বা হ্যান্ডশেক ব্যর্থতার কথা জানায়, যা মানুষকে সার্টিফিকেট ও MTU খুঁজতে পাঠায়, অথচ ফায়ারওয়াল নিঃশব্দে সংযোগটি খেয়ে ফেলে। যে নিয়মটি আপনার ট্রাফিক ধরে রাখার কথা ছিল, সেটিই সেই ট্রাফিক ধরে রাখতে বাধা দিচ্ছে।

প্রতিক্ষিপ্ত সমাধান লিকটিকে স্থায়ী করে। sudo ufw allow out on wlan0, অথবা ডিফল্ট আবার অনুমতিতে ফিরিয়ে দেওয়া টানেল তুলে দেয় এবং মেশিনটিকে কিল সুইচ ছাড়া রেখে দেয়: পরের বার টানেল পড়লে সবকিছু ভৌত অ্যাডাপ্টারের উপর দিয়ে আবার শুরু হয়। ঠিক সেই দুটি সম্পাদনায় আমি একটি দুপুর হারিয়েছি, তার আগে যে আমি আসলে কোন প্যাকেট ফিল্টার করছি তা বুঝতে পারিনি।

দুই সেট প্যাকেটের যা দরকার

আপনার ট্রাফিক দুইবার, দুই আকারে ফায়ারওয়াল অতিক্রম করে। ভেতরের প্যাকেট টানেল ঠিকানা থেকে tun0 দিয়ে বের হয়। বাইরের প্যাকেট ভৌত ঠিকানা থেকে পিয়ারের কাছে যায়, এবং তারেই কেবল তারে দৃশ্যমান। প্রতি আকারে একটি নিয়ম:

sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow out to 203.0.113.10 port 443 proto tcp comment 'tcp fallback'

ঠিকানা ও পোর্ট আপনার নিজের প্রোফাইলের দিয়ে প্রতিস্থাপন করুন। WireGuard পিয়াররা সাধারণত 51820/udp-এ উত্তর দেয়; TCP 443 দিয়ে চলা OpenVPN প্রোফাইলের বদলে সেই পোর্ট দরকার। বিবরণ ভিন্ন, আকার নয়: দুটি নিয়মই সংকীর্ণ, এবং একসাথে তারা নির্ধারণ করে টানেল বন্ধ থাকাকালে মেশিনটি কেবল কোন গন্তব্যগুলিতে পৌঁছাতে পারে।

ক্রম দ্বিতীয় কল্পকাহিনি। কাঁচা iptables-এ আপনি চেইনটি উপর থেকে নিচে পড়েন এবং কোন নিয়ম জেতে তা যুক্তি দেন। ufw আপনার টাইপ করা তালিকার পাতলা মোড়ক নয়; এটি আপনার নিয়মগুলি নিজের চেইনে কম্পাইল করে এবং সন্নিবেশ বিন্দু বেছে নেয়। ufw status সেগুলি ufw-এর ক্রমে ছাপায়, আপনার ক্রমে নয়। যখন কোনো নিয়ম উপেক্ষিত মনে হয়, তুলনা করুন ufw show added থেকে সংকলিত সেটের সাথে iptables -S | grep ufw কিছু পুনর্লিখনের আগে।

ব্যতিক্রমটি এক ঠিকানা চওড়া থাকতে হবে

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

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

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

টানেল দরকার হওয়ার আগেই নীতিটি তৈরি করুন

ufw enable একবারে পুরো নীতি প্রয়োগ করে এবং নিজের চেইন পুনরায় লোড করে, আর চালু ফায়ারওয়ালে ডিফল্ট নীতি বদলালেও সেগুলি পুনরায় লোড হয়। ufw ম্যানুয়াল সতর্ক করে যে এটি SSH-এর মতো বিদ্যমান সংযোগ ফেলে দিতে পারে। তাই কমান্ডগুলি এই ক্রমে যায়, SSH নিয়ম সক্রিয় করার আগে এবং একটি কনসোল সেশন খোলা রেখে:

sudo ufw default deny incoming
sudo ufw default deny outgoing
sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status verbose

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

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

ব্লক করা অবস্থা পরীক্ষা করুন, এবং পূর্বাবস্থা রাখুন

অপরীক্ষিত কিল সুইচ একটি অনুমান. ইচ্ছাকৃতভাবে ক্লায়েন্ট সংযোগ বিচ্ছিন্ন করুন এবং একটি পৃষ্ঠা লোড করার চেষ্টা করুন: এটি ব্যর্থ হতে হবে। আবার সংযোগ করুন এবং কোনো নিয়ম না ছুঁয়েই তা ফিরে আসতে হবে। sudo ufw status verbose ডিফল্ট ও লগিং অবস্থা নিশ্চিত করে, এবং ufw status numbered দেখায় কোন পরীক্ষামূলক নিয়মটি মুছতে হবে যখন তা তার উদ্দেশ্য ছাড়িয়ে যায়।

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

sudo ufw reset
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable

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