اگر آپ Identity-Aware Proxy استعمال کرتے ہیں تو کیا آپ کو اب بھی VPN کی ضرورت ہے؟

فرضیہ یہ ہے: جہاں بھی شناخت کو جاننے والا پراکسی اندرونی ایپلیکیشنوں کے سامنے آ جائے، VPN محض سجاوٹ رہ جاتا ہے اور کلائنٹ جا سکتا ہے۔ یہ صرف ایک تنگ صورتحال کے لیے درست ہے — براؤزر میں استعمال ہونے والی ایک تعاملی HTTPS ایپلیکیشن — اور باقی ہر جگہ یہ خاموشی سے ناکام ہو جاتی ہے۔ پراکسی کسی وسیلے کے خلاف درخواست کو اختیار دیتا ہے؛ VPN کلائنٹ کو نیٹ ورک کے دائرے میں داخل کرتا ہے، اور یہ دو حدیں شاز ونادر ملتی ہیں۔ ٹنل کو ریٹائر کرنے سے پہلے ڈائگرام پر لگے مصنوعاتی لیبل نہیں، اپنے لوگوں کے اصل عملیات کا موازنہ کریں۔

دو دروازے مختلف چیزوں کو اختیار دیتے ہیں

ایپلیکیشن کا دروازہ فیصلہ کرتا ہے کہ یہ درخواست، اس شناخت سے، اس محفوظ وسیلے تک پہنچ سکتی ہے یا نہیں۔ Google کا Identity-Aware Proxy جائزہ ٹھیک یہی شکل بیان کرتا ہے: HTTPS ایپلیکیشنوں کے سامنے IAM کردار کے زریعے چلنے والی مرکزی اختیاری تہ۔ حد وسیلہ ہے، اور رسائی کا اکائی درخواست ہے۔ روٹ شدہ VPN کچھ موٹا اور وسیع کرتا ہے: کلائنٹ کو مشخص نیٹ ورک دائرے میں داخل کرتا ہے، اس کے بعد بھی ایپلیکیشن فیصلہ کرتی ہے کہ یہ کلائنٹ کیا کر سکتا ہے۔

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

پراکسی کیا نہیں ڈھانےتا، اور VPN کیا ڈھانتا ہے

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

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

کلائنٹ کا کاری بہاؤ ارکٹیکچر ڈائگرام سے زیادہ طے کرتا ہے

ری ڈائریکٹ اور کبھی کبھھار MFA چیلنج کے ساتھ براؤزر سائن ان بوک مارک پر کلک کرنے والے کے لیے اچھا تجربہ ہے۔ cron کام، CLI یا بلڈ ایجنٹ کے پاس براؤزر نہیں ہوتا اور وہ تعاملی پرامپٹ کا جواب نہیں دے سکتا، لیے اسے مستند غیر تعاملی راستہ یا ٹنل درکار ہے۔ اس ضرورت کا انکشاف عموماً ڈیزائن کے منظور ہونے کے بعد ہوتا ہے۔

ایپلیکیشنوں کو گننے سے پہلے کلائنٹ گنیں۔ ایک ڈیش بورڈ سو لوگوں کی خدمت کر سکتا ہے؛ ایک ڈیٹابیس پورٹ پوری ٹیم کو بلاک کر سکتا ہے۔

ڈیوائس کی صورتحال کسی بھی دروازے کی خاصیت نہیں ہے

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

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

کچھ بھی ریٹائر کرنے سے پہلے متبادل راستے تلاش کریں

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

پھر حوالہ کریں: درج کرنا، اپ ڈیٹز، رسائی ہٹانا اور رات 2 بجے باہر بند ہونے والے کے لیے بحالی کا راستہ۔ پرامپٹ یا کلائنٹ ایپ ہٹانا ذمہ داری کو ٹیموں کے درمیان منتقل کرتا ہے؛ یہ ذمہ داری کو میٹاتا نہیں۔

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