فائر وال کے قاعدے کی تبدیلی کام نہیں کر رہی: قواعد کی ترتیب اور کنکشن کی حالت

آپ نے قاعدہ تبدیل کیا، قواعد کا مجموعہ دوبارہ لوڈ کیا، اور سرنگ بالکل پہلے کی طرح برتاؤ کر رہی ہے۔ اس نتیجے کی دو عام وجوہات ہیں، اور ان کے لیے مختلف جانچیں درکار ہیں۔ یا تو نیا قاعدہ پہلے ہی پیکٹ قبول کر چکے سابقہ قاعدے کے بعد ہے، یا جو تبادلہ آپ دیکھ رہے ہیں وہ ٹریک شدہ کنکشن ہے جسے تبدیلی کبھی دوبارہ نہیں پرکھتی۔ فائل میں موجود قاعدہ نیت ظاہر کرتا ہے؛ پیکٹ کا فیصلہ وہ فعال راستہ کرتا ہے جس سے وہ ملتا ہے۔ نیچے دی گئی جانچیں ترتیب سے کریں اور اس دوران واپسی کا راستہ کھلا رکھیں۔

قواعد کی ترتیب اور کنکشن کی حالت الگ الگ خرابیاں ہیں

ترتیب شدہ زنجیریں اوپر سے نیچے تک پرکھی جاتی ہیں، اور حتمی فیصلے تک پہنچنے والا پہلا قاعدہ اس زنجیر میں گزر ختم کر دیتا ہے۔ کسی احتیاط سے لکھے گئے لاک ڈاؤن قاعدے کے اوپر وسیع اجازت رکھیں، تو لاک ڈاؤن قاعدہ محض دستاویز بن جاتا ہے: وہ مجموعے میں ہے، اس کا شمار کنندہ صفر ہے، اور کوئی پیکٹ کبھی اس تک نہیں پہنچے گا۔ وہی متن کسی دوسری زنجیر پر لاگو کرنے سے بھی کچھ ثابت نہیں ہوتا۔ nftables میں بنیادی زنجیریں ترجیحات کے مطابق ہک سے جڑتی ہیں، اس لیے ایک زنجیر کی اجازت کسی دوسرے ہک یا ترجیح کی دوسری زنجیر کو وہی پیکٹ دیکھنے سے نہیں روکتی۔

کنکشن ٹریکنگ دوسری علامت پیدا کرتی ہے، اور باہر سے وہ بالکل ویسی ہی دکھتی ہے۔ جب بہاؤ حالت کی جدول میں آ جاتا ہے، زنجیر کے اوپری حصے کے قریب established-or-related اجازت آپ کے نئے قاعدے پر غور سے پہلے ہی واپس آ جاتی ہے۔ NAT میپنگز میں بھی یہی خصوصیت ہے: ترجمہ اسی وقت طے ہو گیا تھا جب بہاؤ شروع ہوا، اس لیے تبدیل شدہ postrouting قاعدہ پہلے سے چل رہے سیشن کو دوبارہ نہیں لکھتا۔ یہی وجہ ہے کہ تبدیلی 09:00 بجے نئے کنکشن کے لیے کام کرتی دکھتی ہے اور 08:55 بجے کسی کے کھولے سیشن کے لیے کچھ نہیں کرتی۔

کلاؤڈ سکیورٹی گروپس تیسرا ماڈل شامل کرتے ہیں جو iptables پر سیکھنے والوں کو پکڑتا ہے۔ ان کے اندر آنے والے قواعد اجازتوں کی فہرست ہیں جو پہلی مطابقت کی چال کے بجائے مجموعے کے طور پر پرکھی جاتی ہے، وہ حالت والے ہیں، اور اجازت کا قاعدہ ہٹانے سے پہلے سے ٹریک ہو رہے بہاؤ ختم نہیں ہوتے۔ ایسا مفہوم نہ رکھنے والے پلیٹ فارم پر پہلی مطابقت کا مفہوم فرض کرنا پراعتماد مگر غلط نتائج تک لے جاتا ہے۔

فعال قواعد کا مجموعہ پڑھیں، وہ فائل نہیں جو آپ نے تبدیل کی

کرنل اس وقت جو نافذ کر رہا ہے اس سے شروع کریں۔ محفوظ شدہ ترتیب جو کبھی لاگو نہ ہوئی، حیران کن طور پر بہت سے غیر تبدیل شدہ رویوں کی وضاحت کرتی ہے، اور اسے خارج کرنے میں صرف ایک حکم لگتا ہے:

nft list ruleset
iptables-save

پھر پوچھیں کہ آپ کے قاعدے تک پہنچا بھی جاتا ہے یا نہیں۔ پیکٹ شمار کنندگان اس کا براہ راست جواب دیتے ہیں، اور نیت کے بارے میں کسی بھی استدلال سے بہتر جواب دیتے ہیں:

iptables -L FORWARD -v -n --line-numbers
nft list chain inet filter forward

حقیقی جانچ کی کوشش کے بعد صفر پیکٹ والا لاک ڈاؤن قاعدہ پالیسی کا مسئلہ نہیں، یہ مقام کا مسئلہ ہے۔ اسے ہٹانا ایک سطر کی تبدیلی ہے، اور نحو ہی وہ چیز ہے جس نے اصل خرابی پیدا کی۔ iptables میں -I شروع میں داخل کرتا ہے اور -A آخر میں شامل کرتا ہے؛ nftables میں insert قاعدہ زنجیر کے شروع میں رکھتا ہے جبکہ add آخر میں شامل کرتا ہے۔ جب قاعدے کو جیتنا ہی ہو، تو اتفاقاً لوڈ ہوئی ترتیب پر بھروسا کرنے کے بجائے اسے واضح کہیں۔

ثابت کریں کہ بہاؤ ٹریک ہو رہا ہے یا نہیں

قاعدے کو قصوروار ٹھہرانے سے پہلے دیکھیں کہ ٹریفک واقعی ٹریک شدہ کنکشن ہے یا نہیں۔ پوری حالت کی جدول بہانے کے بجائے مخصوص بہاؤ کے بارے میں پوچھیں:

conntrack -L -p tcp --dport 1194
conntrack -E -p tcp --dport 1194

فہرست حالت اور باقی وقت کی حد دکھاتی ہے، اور اسی طرح آپ قائم شدہ سیشن کو نئی کوشش سے الگ کرتے ہیں؛ واقعات کا موڈ پیش رفت کے ساتھ ہی تازہ کاری چھاپتا ہے، جو کلائنٹ کو دوبارہ جوڑتے وقت مفید ہے۔ اگر آپ کچھ چھونے سے پہلے ہی بہاؤ قائم شدہ حالت میں موجود ہو، تو فلٹر قواعد کی کوئی بھی تدوین اس کی قسمت نہیں بدلے گی۔ یہ فائر وال میں خرابی نہیں، یہ حالت والی فلٹرنگ کا معاہدہ ہے۔

پیداواری گیٹ وے پر پوری جدول خالی کرنے کے شارٹ کٹ کی مزاحمت کریں۔ conntrack -F دستیاب ہے، اور یہ مشین پر ہر ٹریک شدہ بہاؤ کو بھی تباہ کرتا ہے، بشمول وہ انتظامی سیشن جس سے آپ کام کر رہے ہیں اور وہ سرنگ جو آپ کا شیل لے کر چلتی ہے۔ انفرادی اندراجات اس وقت حذف کیے جا سکتے ہیں جب واقعی ضرورت ہو، لیکن نئے ماخذ پورٹ سے نیا بہاؤ عام طور پر زیادہ صاف تجربہ ہوتا ہے۔

کچھ راستے ٹریک نہیں ہوتے، اور وہ اُلٹا برتاؤ کرتے ہیں۔ raw جدول میں notrack کے طور پر نشان زد ٹریفک، عام ہک سے بچنے والی کچھ سرنگیں، اور وہ غیر متناسب روٹنگ جو بہاؤ کو دو گیٹ ویز کے درمیان تقسیم کرتی ہے — سب ایک ایک کر کے پرکھے جانے والے پیکٹ یا ایسی حالت پیدا کرتے ہیں جو دونوں سروں پر کبھی نہیں بنتی۔ اگر ہر پیکٹ پر شمار کنندگان حرکت کریں، تو ترتیب پر شک کرنے سے پہلے ایسے راستے پر شک کریں۔

واپسی کے راستے کے ساتھ نئے بہاؤ سے جانچیں

دور رسائی کاٹ سکنے والے قاعدے کی جانچ سے پہلے بحالی کا راستہ بنائیں: فراہم کنندہ کا کنسول، سیریل کنسول، بینڈ سے باہر انتظامی پتہ، یا دوسرا انٹرفیس جسے قاعدہ نہیں پہچان سکتا۔ رول بیک ٹائمر مناسب ساتھی ہے، کیونکہ جانچ کے دوران آپ کا سیشن مر جائے تب بھی یہ سابقہ قواعد کا مجموعہ بحال کر دے گا۔

پھر ایسے تبادلے سے جانچیں جسے حالت پہلے ہی ڈھانپ نہیں سکتی تھی۔ کلائنٹ منقطع کر کے دوبارہ جوڑیں تاکہ نیا پانچ کا مجموعہ بنے، اور ایسا ہوتے وقت دونوں سرے دیکھیں:

tcpdump -ni eth0 'tcp port 1194'
journalctl -k -n 50 --no-pager

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

قاعدے کے ساتھ مقصد اور مقام درج کریں

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

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