اسپلٹ ٹنلنگ بمقابلہ کمپنی کی پالیسی: کون سا اصول جیتتا ہے

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

چیک باکس پر بحث سے پہلے طے کریں کہ پالیسی کس خصوصیت کی حفاظت کے لیے ہے۔

اصول کے پیچھے کی خصوصیت

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

چوتھا گروہ اینڈ پوائنٹ کی حالت نافذ کرتا ہے: ڈسک انکرپشن کی حالت، پیچ کی سطح، ایجنٹ کی صحت۔ ٹنل بانٹنے سے یہ نہیں بدلتا، البتہ ایجنٹ کی اپنی ٹریفک سے بچنے والا بائی پاس بدل سکتا ہے۔

یہ چار مختلف تقاضے ہیں اور ہر ایک کو مختلف استثنا توڑتا ہے۔ تبدیلی تجویز کرنے سے پہلے تقاضا پڑھیں، کیونکہ لکھنے والا فوراً بتا سکتا ہے کہ کون سا لاگو ہوتا ہے۔ غلط تقاضا پورا کرنے والی تبدیلی کچھ نہیں خریدتی۔

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

جانچیں ترتیب سے چلائیں

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

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

ہر جواب ایک حقیقت ہے، اور استثنا کی درخواست کو حقائق ہی درکار ہوتے ہیں۔ VPN پریشان کن ہے یا نہیں، یہ بحث اُن میں سے نہیں۔ گفتگو شروع ہونے سے پہلے جوابات لکھ لیں۔

تنگ استثنا طلب کریں

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

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

اگر جواب نہیں ہے تو اسے ڈیزائن کا فیصلہ سمجھیں، ایسی رکاوٹ نہیں جسے گھما کر گزرنا ہو۔ اگلا جائزہ اسے دوبارہ کھولنے کی جگہ ہے، ناکام عمل دستاویز کر کے اور کاروباری وجہ منسلک کر کے۔ اس کے گرد گھومنا اُس سے زیادہ خطرہ مول لیتا ہے جتنا یہ استثنا کبھی واجب تھا۔

استثنا کو پائیدار بنائیں

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

resolvectl query intranet.corp.example
curl -sS -o /dev/null -w '%{http_code}
' https://intranet.corp.example/status

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

استثنا، اس کا مقصد اور اُس کے تحت آنے والے اجزاء تعیناتی نوٹس والی جگہ ہی درج کریں۔ غیر دستاویزی استثنا اگلی سہ ماہی کا واقعہ بن جاتا ہے، اور دستاویزی ثابت بن جاتا ہے کہ ڈیزائن حقیقی کام کا بوجھ اٹھاتا ہے۔