خود کو باہر بند کیے بغیر فائر وال تبدیلیوں کی جانچ
قاعدہ لاگو ہونے سے پہلے اپنے بازیابی راستوں کو ترتیب دیں، پھر بچ جانے والے سیشن کے بجائے ایسے بہاؤ سے تصدیق کریں جس کا نئی پالیسی کو جائزہ لینا ہے۔
قاعدہ لاگو ہوتا ہے، آپ کے پاس پہلے سے موجود ٹرمینل جواب دیتا رہتا ہے، اور اگلا لاگ اِن مسترد ہوتا ہے۔ یہی خلا اس کنکشن پر فائر وال تبدیلی کی جانچ کی پوری مشکل ہے جسے آپ بدل رہے ہیں۔ کنکشن ٹریکنگ ایک بار فیصلہ کرتی ہے اور پھر دیکھنا بند کر دیتی ہے، اس لیے قائم شدہ بہاؤ ہی واحد جانچ ہے جو نئی پالیسی کو نہیں دیکھ سکتا۔ آگے واپسی کے تین راستوں کا موازنہ کیا جاتا ہے، پھر وہ ترتیب طے کی جاتی ہے جس میں قواعد بدلنے اور جانچنے ہیں۔
بچ جانے والا سیشن ہی کمزورترین ثبوت کیوں ہے
حالت والا فائر وال بہاؤ کے پہلے پیکٹ کا جائزہ لیتا ہے اور اندراج کے زندہ رہنے تک وہی فیصلہ رکھتا ہے۔ بعد میں شامل کیے گئے قواعد ان بہاؤوں پر لاگو ہوتے ہیں جو بعد میں شروع ہوتے ہیں، اسی لیے جس ونڈو میں آپ ٹائپ کر رہے ہیں وہ قابلِ استعمال رہتی ہے جبکہ باقی سب مسترد ہوتے ہیں۔ اس سے آپ جو سیکھتے ہیں وہ چند منٹ پہلے نافذ پالیسی بیان کرتا ہے۔ اسی بہاؤ پر لی گئی کیپچر بھی ایسا فیصلہ دکھاتی ہے جو مشین پہلے ہی کر چکی ہے۔
چلتی ہوئی سیشن کو پیمائش نہیں بلکہ ہنگامی راستہ سمجھیں۔ ہر قابلِ قدر جانچ کو ایسے ماخذ سے نیا بہاؤ کھولنا چاہیے جس کا نیا قاعدہ جائزہ لے گا، اور پہلی جانچ وہی ہونی چاہیے جس کی ناکامی سب سے زیادہ تکلیف دے۔ جب وہی سیشن اندر جانے کا واحد راستہ ہو، تب تبدیلی ابھی کرنے کے لیے تیار نہیں ہے۔
واپسی کے تین راستے، ہر ایک کس چیز پر منحصر ہے اس کے مطابق ترتیب دیے گئے
اختیارات کو اس بنیاد پر ترتیب دیں کہ وہ زیرِ جانچ آلے پر کتنا انحصار کرتے ہیں، کیونکہ قاعدہ غلط ثابت ہونے پر آپ اسی ترتیب کو تھامتے ہیں۔ جو کنسول کبھی فائر وال سے نہیں گزرتا وہ خودمختار ہے، مشق کی گئی واپسی تقریباً ویسی ہی ہے، اور پہلے سے کھلا سیشن ویسا نہیں ہے۔
| Way back in | What it survives | Where it fails |
|---|---|---|
| out-of-band or hypervisor console | a policy that blocks new logins | needs separate access you have already tried |
| rollback rehearsed on that platform | a rule that breaks remote access | fails when nobody ever ran it |
| the session that is already open | the change itself | cannot show whether new flows work |
تبدیلی سے پہلے کنسول کے ذریعے لاگ اِن کریں اور ثابت کریں کہ وہ کام کرتا ہے، کیونکہ جو آؤٹ آف بینڈ راستہ آپ نے کبھی استعمال نہیں کیا وہ نقشہ ہے، متبادل نہیں۔ واپسی اپنی جگہ صرف اسی پلیٹ فارم پر، اسی قواعد کے سیٹ کے ساتھ، منظور شدہ طریقہ کار کی پیروی کرتے ہوئے کی گئی مشق کے بعد حاصل کرتی ہے، زندہ مشین پر فوری تدبیر کے بجائے۔ مراحل لکھیں اور کسی اور سے پڑھوائیں۔ اگر ترتیب مکمل کرنے کے لیے آپ کی یادداشت درکار ہو، تو یہ منصوبہ نہیں ہے۔
ایک تبدیلی، پھر ایک کنکشن جس کا جائزہ لینا ضروری ہے
چل رہا قواعد کا سیٹ اور اس کا مالک فائل محفوظ کریں، پھر ایک ہی تنگ ترمیم کریں۔ فی جانچ ایک تبدیلی نتیجے کو قابلِ نسبت رکھتی ہے؛ ایک ساتھ دو کرنے سے چلتی مشین اور یہ علم کہ کون سی ترمیم نے کام کیا، دونوں نہیں بچتے۔ جہاں پلیٹ فارم کنفیگریشن کو لوڈ کیے بغیر تجزیہ کر سکتا ہو، وہاں پہلے وہی کریں، تاکہ ٹائپنگ کی غلطی اُس وقت پکڑی جائے جب کچھ داؤ پر نہ ہو۔
nft list ruleset > /root/ruleset.before
nft -c -f /etc/nftables.conf
پھر کنسول کے ابھی جڑے رہنے کے دوران، ایسے ماخذ سے نیا سیشن شروع کریں جس سے بدلا ہوا قاعدہ مطابقت رکھے گا۔ کامیاب ہو تو ایک بار دہرائیں، کیونکہ پہلی کوشش ایسے اندراج پر پڑ سکتی ہے جو جدول کے پاس پہلے سے تھا۔ ناکام ہو تو بھی اندر جانے کا راستہ اور واپس لینے کا فیصلہ دونوں باقی رہتے ہیں، اور یہی دستیاب سب سے سستا برا نتیجہ ہے۔
کاؤنٹر، حالت اور فائل مختلف سوالات کے جواب دیتے ہیں
تین مشاہدوں میں سے ہر ایک تنہا قائل دکھ سکتا ہے اور باقی دو کے بارے میں آپ کو گمراہ کر سکتا ہے۔ کاؤنٹر دکھاتے ہیں کہ ابھی بنایا گیا بہاؤ اس قاعدے تک پہنچا یا نہیں جس میں آپ نے ترمیم کی۔ حالت کا جدول دکھاتا ہے کہ مشین کن بہاؤوں کو پہلے سے قائم سمجھتی ہے، اور اسی طرح ٹوٹا ہوا قاعدہ بھی صحت مند دکھ سکتا ہے۔ محفوظ شدہ فائل دکھاتی ہے کہ اگلی ری لوڈ کے بعد آلہ کیا کرے گا، اور ہو سکتا ہے وہ وہی نہ ہو جو ابھی چل رہا قواعد کا سیٹ کر رہا ہے۔
ss -tn state established
کاؤنٹروں کو مجموعے کے بجائے فرق کے طور پر پڑھیں، کیونکہ اہم واحد عدد وہی ہے جسے آپ کے جانچی بہاؤ نے ہلایا۔ جس قاعدے کا کاؤنٹر کبھی نہ بڑھے وہ مطابقت نہیں رکھتا، کاغذ پر کتنا ہی درست دکھے۔ مسترد ہونے کی صورت بھی تصدیق کریں: جس پالیسی نے کبھی کچھ مسترد نہیں کیا اس نے کبھی ثابت نہیں کیا کہ وہ وہ مسترد کرتی ہے جسے آپ روکنا چاہتے تھے۔ جن خاندانوں کو تعیناتی واقعی اٹھاتی ہے ان میں سے ہر ایک میں ایک انٹرفیس سے گزریں، کیونکہ v4 قاعدہ v6 بہاؤ کے بارے میں کچھ نہیں کہتا۔
محفوظ شدہ قواعد کے سیٹ سے بحال کریں، پھر فائل کو ہم آہنگ کریں
جب تبدیلی ناکام ہو، تو لاگ اِن دوبارہ کام کرنے تک اجازت دینے والے قواعد شامل کرنے کے بجائے محفوظ شدہ قواعد کا سیٹ لوڈ کریں۔ ہر اضافی اجازت علامت کو پرسکون کرتی ہے اور ایسا سوراخ چھوڑتی ہے جو واقعے اور اس کی یاد سے زیادہ زندہ رہتا ہے۔ بحال کریں، دوبارہ جڑیں، پھر ناکام موازنہ کو اپنی کوشش کے ریکارڈ کے ساتھ رکھیں۔
کامیاب تبدیلی کے بعد، ڈسک پر موجود فائل چل رہے قواعد کے سیٹ کی وضاحت کرے، اور تصدیق کریں کہ ری لوڈ اسے دوبارہ پیدا کرتی ہے۔ جو زندہ قواعد کا سیٹ اپنی ہی کنفیگریشن فائل سے بھٹک گیا ہے وہ اگلی ری بوٹ کے لیے بچھایا گیا جال ہے۔