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

بچ جانے والا سیشن ہی کمزورترین ثبوت کیوں ہے

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

چلتی ہوئی سیشن کو پیمائش نہیں بلکہ ہنگامی راستہ سمجھیں۔ ہر قابلِ قدر جانچ کو ایسے ماخذ سے نیا بہاؤ کھولنا چاہیے جس کا نیا قاعدہ جائزہ لے گا، اور پہلی جانچ وہی ہونی چاہیے جس کی ناکامی سب سے زیادہ تکلیف دے۔ جب وہی سیشن اندر جانے کا واحد راستہ ہو، تب تبدیلی ابھی کرنے کے لیے تیار نہیں ہے۔

واپسی کے تین راستے، ہر ایک کس چیز پر منحصر ہے اس کے مطابق ترتیب دیے گئے

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

Way back inWhat it survivesWhere it fails
out-of-band or hypervisor consolea policy that blocks new loginsneeds separate access you have already tried
rollback rehearsed on that platforma rule that breaks remote accessfails when nobody ever ran it
the session that is already openthe change itselfcannot show whether new flows work

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

ایک تبدیلی، پھر ایک کنکشن جس کا جائزہ لینا ضروری ہے

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

nft list ruleset > /root/ruleset.before
nft -c -f /etc/nftables.conf

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

کاؤنٹر، حالت اور فائل مختلف سوالات کے جواب دیتے ہیں

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

ss -tn state established

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

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

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

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

متعلقہ مضامین