نقصان زدہ ہوسٹ پر ایمرجنسی سوئچ کیا ڈھکتا ہے اسے کیسے جانچیں

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

سرور سے نہیں، کلائنٹ سے شروع کریں

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

لہٰذا پہلے یہ طے کرنا ہے کہ اس ڈیوائس کی پالیسی کس کی ہے اور اسے کیا اوور رائیڈ کرنے کی اجازت ہے۔ منظم ورک مشین پر جواب عام طور پر ادارے کا اینڈ پوائنٹ ایجنٹ ہوتا ہے، اور ذاتی VPN ان صلاحیتوں کو ختم نہیں کرتا، ٹنل کیسے بھی ترتیب دیا گیا ہو۔

پہلا مرحلہ: ان راستوں پر بلاک کی تصدیق کریں جنہیں آپ ڈھانپنے کا خیال کرتے ہیں

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

curl -m 5 -sS -o /dev/null -w '%{http_code}
' https://example.com
ping -c 2 1.1.1.1
ip route
nft list ruleset   # or: iptables -S

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

کلائنٹ کے allow-LAN اختیار کے آن اور آف ہونے پر وہی کمانڈز دہرائیں۔ وہی ٹوگل سب سے زیادہ حیرتوں کی جگہ ہے، کیونکہ یہ اس راستے کو دوبارہ کھولتا ہے جو باقی پالیسی نے بند کرنے کے لیے لکھا تھا۔

دوسرا مرحلہ: DNS اور IPv6 کو الگ راستوں کے طور پر جانچیں

ناموں کا حل وہ خلا ہے جو زیادہ تر نفاذ سے بچ جاتا ہے، کیونکہ استفسار سسٹم ریزولور کے علاوہ کسی اور چیز سے باہر جا سکتا ہے۔ ایسے آلے سے پوچھیں جو آپ کی ریزولور ترتیب کو نظر انداز کرے، اور وہیں v6 طرف بھی جانچیں:

dig +short example.com
dig +short @1.1.1.1 example.com
curl -6 -m 5 -sS https://example.com -o /dev/null -w '%{http_code}
'
ip -6 route

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

براؤزر اسے باہر سے پڑھنا مشکل بناتے ہیں، کیونکہ DNS over HTTPS کے لیے ترتیب دیا گیا براؤزر استفسار کو HTTPS درخواست سے حل کرتا ہے: استفسار صرف اتنا ہی بلاک ہے جتنا اس سرے تک پورٹ 443 بلاک ہے۔ جس ہوسٹ پر پالیسی مقامی سب نیٹ کی اجازت دیتی ہے، وہاں وہ درخواست اب بھی LAN کے ریزولور تک پہنچ سکتی ہے۔

تیسرا مرحلہ: نیٹ ورک کی نمائش کو اینڈ پوائنٹ کی نمائش سے الگ کریں

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

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

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

چوتھا مرحلہ: وہ دعویٰ لکھیں جس کی آپ کے ٹیسٹ کی تائید ہے

قطعی رابطہ ٹیسٹ کے بعد آپ مخصوص حقائق بتا سکتے ہیں: کون سی ایپس ناکام ہوئیں، کون سے راستے رکے، DNS اور IPv6 نے کیسا رویہ دکھایا، اور ٹنل گرنے پر بلاک قائم رہا یا نہیں۔ آپ یہ نہیں کہہ سکتے کہ آپریٹنگ سسٹم صاف ہے، اور یہ بھی نہیں کہہ سکتے کہ دور سرے کی کوئی سروس آپ کا لاگ ان نجی رکھے گی۔

دونوں مسائل الگ رکھیں اور ہر ایک کو اس کا اپنا کنٹرول دیں:

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

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