ڈاؤن اسکرپٹ یا فائر وال اصول: رساؤ کو کون روکتا ہے؟
کٹ جانے پر انٹرفیس نیچے کرنا سخت طریقہ ہے اور اکثر اجازتوں کے بغیر چلتا ہے۔ اس کا موازنہ ایسے فائر وال اصول سے کریں جو گرنے کے بعد بھی قائم رہے اور خلا بند کرے۔
دو ڈیزائن ایک ہی بات کا وعدہ کرتے ہیں: جب سرنگ گرتی ہے، کچھ بھی کھلے طور پر باہر نہیں جاتا۔ ایک ٹیئر ڈاؤن پر اسکرپٹ چلا کر انٹرفیس کاٹ دیتا ہے۔ دوسرا فائر وال اصول نافذ رکھتا ہے اور VPN کلائنٹ سے کچھ نہیں مانگتا۔ یہ اس میں مختلف ہیں کہ کس کو کارروائی کا اختیار ہے، خلا کے دوران کیا ہوتا ہے اور بعد میں مشین دوبارہ آن لائن کیسے آتی ہے۔ ان تین نکات پر موازنہ کرنا اس بحث سے زیادہ مفید ہے کہ کون سخت ہے۔
ایک ہی کام، دو طریقے
کلائنٹ سرنگ اٹھتے وقت اور ٹیئر ڈاؤن کے وقت ہک چلا سکتا ہے، بشرطیکہ پروفائل اسکرپٹ چلانے کی اجازت دے۔ وہ ہک کلائنٹ کے زندگی کے چکر کے اندر، اسی لمحے چلتا ہے جب کنکشن بند ہوتا ہے۔ فائر وال اصول اس کے برعکس نظام کی ملکیت ہے اور اسے پروا نہیں کہ کلائنٹ چل رہا ہے، کریش ہوا یا مارا گیا۔
| Property | Teardown script | Firewall unit |
|---|---|---|
| Runs when the client is killed | No | Yes |
| Needs privilege at teardown time | Usually yes | Configured once, at boot |
| Acts on the whole machine | Often, including recovery paths | Only on the flows it matches |
وہی جدول پوری دلیل ہے۔ جو اسکرپٹ صرف صاف بندش پر چلے وہ اس صورت کو ڈھکتا ہے جس کی آپ کو سب سے کم فکر تھی؛ اہم صورت کریش یا نیٹ ورک کا غائب ہونا ہے، اور دونوں میں سے کوئی صاف ٹیئر ڈاؤن نہیں دیتا۔
ٹیئر ڈاؤن ہک کیا کر سکتا ہے اور کیا نہیں
درج شدہ نمونہ نیٹ ورک انٹرفیس سے گزرتا ہے اور loopback کے سوا سب کچھ نیچے کر دیتا ہے۔ جب طبعی آلہ نیچے ہو تو سرنگ سے باہر کچھ نہیں نکل سکتا، اور یہی درست ارادہ ہے۔
#!/bin/sh
for dev in /sys/class/net/*; do
name=$(basename "$dev")
[ "$name" = lo ] || ip link set dev "$name" down
doneیہ مقامی نیٹ ورک، مشین کی میزبانی والی ہر سروس اور وہ راستہ بھی نیچے کر دیتا ہے جو آپ مسئلہ ٹھیک کرنے کے لیے استعمال کرتے۔ لیپ ٹاپ پر وائرلیس آلے کو بعد میں کبھی کبھی ہاتھ سے بدلنا پڑتا ہے، اس لیے مختصر خلل مرمت کے سیشن میں بدل جاتا ہے۔ اس سے بدتر، ہک کو ان میں سے کچھ بھی کرنے کی اجازت نہ ہو: جب کلائنٹ اختیارات چھوڑ دیتا ہے، ٹیئر ڈاؤن اسکرپٹ بغیر اختیار والے اکاؤنٹ میں چلتا ہے، اور انٹرفیس کی ہر تبدیلی اجازت کی غلطی سے ناکام ہوتی ہے جو اسی لمحے لکھی جاتی ہے جب کوئی لاگ نہیں پڑھتا۔
ہک پر بھروسہ کرنے سے پہلے دیکھیں کہ کلائنٹ کیسے شروع ہوتا ہے۔ root کے طور پر ہاتھ سے چلانے پر کام کرنے والا اسکرپٹ بوٹ پر شروع ہونے والی سروس کے بارے میں کچھ ثابت نہیں کرتا۔
فائر وال اصول کیا مختلف کرتا ہے
جو اصول صرف سرنگ کی ٹریفک کی اجازت دیتا ہے وہ کلائنٹ پروسیس کے جانے کے بعد بھی کام کرتا رہتا ہے، کیونکہ کرنل اس پروسیس پر منحصر نہیں۔ اصول زیادہ تنگ بھی ہے: یہ صرف انہی بہاؤ کو روکتا ہے جن سے میل کھاتا ہے اور loopback، مقامی ذیلی نیٹ اور بحالی کے راستے کو تنہا چھوڑ دیتا ہے، اسی لیے مشین کو پھنسا ہوا نہیں چھوڑتا۔
قیمت یہ ہے کہ اصول میزبان فائر وال کا مالک ہی لکھے اور سنبھالے، اور اسے اس سرنگ آلے کا نام دینا پڑتا ہے جو کلائنٹ واقعی بناتا ہے۔ اس کا مطلب ہے کہ اصول اور پروفائل ساتھ سنبھالنے پڑیں گے؛ نام بدلا ہوا انٹرفیس ایسی فائر وال چھوڑ جاتا ہے جو سب کچھ روکتی ہے اور کچھ نہیں سمجھاتی۔
کوئی طریقہ دوسرے کو غیر ضروری نہیں بناتا۔ ترمیم کے بعد کبھی دوبارہ لوڈ نہ ہونے والا فائر وال اصول کبھی نہ چلنے والی اسکرپٹ جتنا ہی خیالی ہے۔
خلا ہے یا نہیں یہ persist-tun طے کرتا ہے
جب سرنگ آلہ منقطع ہونے سے بچ جاتا ہے تو اس کی طرف جانے والے راستے بھی بچ جاتے ہیں۔ پھر ٹریفک کو دوبارہ موڑنے کے بجائے پھینک دیا جاتا ہے، اس لیے طے شدہ راستہ طبعی گیٹ وے کی طرف واپس نہیں گرتا۔ یہی رویہ کسی بھی فائر وال اصول کے شامل ہونے سے پہلے ہی رساؤ کو غیر متوقع بناتا ہے۔
اس ترتیب کے بغیر آلہ اور اس کے ساتھ راستے ہٹا دیے جاتے ہیں، اور طے شدہ راستہ دوبارہ طبعی گیٹ وے کی طرف جا سکتا ہے۔ ایسا ہوگا یا نہیں یہ پلیٹ فارم اور کلائنٹ پر منحصر ہے، اور اسی لیے حالت کو ماننے کے بجائے دیکھنا چاہیے۔ ترتیب کو kill switch کا حصہ سمجھیں، کارکردگی کا اختیار نہیں۔
دوبارہ جڑنے کا راستہ زندہ رکھیں، پھر چار حالتیں جانچیں
سخت پابندی کلائنٹ کو دوبارہ جڑنے سے بھی روک سکتی ہے، کیونکہ باقی سب کے مسترد ہونے کے دوران بھی کلائنٹ کو طبعی گیٹ وے کے ذریعے سرور تک راستہ چاہیے۔ سرنگ اٹھنے سے پہلے اسی ایک پتے کے لیے میزبان راستہ نصب کریں، اور پہلے نام حل کریں، کیونکہ جب آپ کو اس کی ضرورت ہو تب تک DNS بلاک ہو سکتا ہے۔
ip route add 198.51.100.20/32 via 192.168.0.1 dev wlan0پھر لیبل نہیں، حالتیں تصدیق کریں۔ چار لمحے جان بوجھ کر آزمائیں: سرنگ کے بغیر سرد آغاز، صحت مند سیشن، وہ گراوٹ جسے کسی نے نہیں مانگا، اور بحالی کے بعد کا سیشن۔ ہر لمحے طے شدہ راستہ پڑھیں اور ایک درخواست کریں جس کا اخراجی پتہ نظر آئے۔ سرنگ نیچے ہونے پر ہار ماننے والی ایپلیکیشن میل کلائنٹ یا اپ ڈیٹر کے بارے میں کچھ نہیں کہتی، اس لیے آخری جانچ ایک پس منظر ایپلیکیشن کے ساتھ دہرائیں۔ اصول، انٹرفیس کے نام اور بحالی کے مراحل لکھ لیں، کیونکہ جس kill switch کو کوئی تصدیق نہیں کر سکتا وہ محض افواہ ہے۔