کیا UFW کا کِل سوئچ آپ کا VPN روک رہا ہے؟ ہم منصب کو اجازت دیں

آپ نے چیک لسٹ پر عمل کیا: باہر جانے سے انکار، ٹنل کی اجازت، ufw فعال کریں۔ پھر کلائنٹ ہینڈ شیک پر انتظار کرتا ہے اور کبھی جڑتا نہیں، یا جڑتا ہے اور کوئی صفحہ لوڈ نہیں ہوتا۔ دونوں ناکامیاں ایک ہی خلا سے آتی ہیں۔ ٹنل کو وجود دینے والا اصول غائب ہے، کیونکہ ٹنل وہ انٹرفیس نہیں جس سے آپ کے پیکٹ باہر جاتے ہیں۔

tun0 پر اجازت شروع میں کسی چیز سے کیوں نہیں ملتی

سیشن ہونے کے بعد کلائنٹ tun0 بناتا ہے۔ وہ سیشن بنانے والے ڈیٹا گرام عام UDP پیکٹ ہیں جو پورٹ 1194 پر فراہم کنندہ کو بھیجے جاتے ہیں، اور وہ جسمانی ماخذ پتے کے ساتھ 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 کا ایک نامزد استثنا ہے، فعال کرنا اجازتوں کے بعد آیا، اور ٹنل کھینچنے سے عام ٹریفک مرتی ہے مگر کلائنٹ ہمیشہ کے لیے نہیں مرتا۔