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 کے بارے میں کچھ نہیں کہتا، اس لیے قاعدے کے ساتھ اسی نوٹ میں دونوں خاندانوں کے لیے مطلوبہ احاطہ ذکر کریں۔ مقصد ایک مربوط زیرِ انتظام پالیسی ہے، اور اتفاقاً تجزیہ شدہ ٹکڑا اس کا ثبوت نہیں ہے۔