آپ کا اسکرپٹ VPN شروع کرتا ہے؛ اسے تیار نہیں کرتا
اسٹارٹ کمانڈ کو ایسا کنکشن درکار ہے جو پہلے سے موجود اور منظور شدہ ہو۔ تیاری کو سیشن کنٹرول سے الگ رکھیں، ورنہ اسکرپٹ صرف آپ کے Mac پر کام کرے گا۔
آپ ایک اسکرپٹ لکھتے ہیں جو کنکشن کے نام کے ساتھ scutil --nc start چلاتا ہے، یہ آپ کے Mac پر کام کرتا ہے، اور دفتر کی ہر نئی انسٹال شدہ مشین پر ناکام ہوتا ہے۔ اسکرپٹ خراب نہیں ہے۔ اس سے وہ کام مانگا جا رہا ہے جو یہ کبھی نہیں کر سکا: موجودہ کنکشن شروع کرنا نیا بنانے کے ویسا ہی عمل نہیں ہے۔
تیاری اور سیشن کنٹرول دو مالکان والے دو کام ہیں، اور الٹ فرض کرنے والا ورک فلو جہاں لکھا گیا اسی مشین پر ہر امتحان پاس کرے گا۔
اسٹارٹ کمانڈ اصل میں کس سے بات کرتا ہے
سیشن کنٹرول کمانڈ ایسی ترتیب کو مخاطب کرتا ہے جو پہلے سے موجود اور پہلے سے منظور شدہ ہے۔ یہ نظام سے کہتا ہے کہ وہ نام والا کنکشن اوپر لائے، پہلے محفوظ کردہ سرور سیٹنگز، شناخت کے حوالوں اور پالیسی کو استعمال کرتے ہوئے۔ اگر وہ کبھی انسٹال نہیں ہوئے تو شروع کرنے کے لیے کچھ نہیں۔
اسی لیے ناکامی نئے ہارڈویئر پر ظاہر ہوتی ہے، منتظم کے لیپ ٹاپ پر نہیں۔ لیپ ٹاپ مہینے پہلے ایسے شخص نے تیار کیا تھا جو یہ کرنا بھول گیا۔ اسٹارٹ کمانڈ کو گزشتہ سہ ماہی میں کسی کے تار لگانے والی دروازے کی گھنٹی سمجھیں۔ اسے دبانا تار لگانے کے برابر نہیں ہے۔
VPN ترتیب کے تین مالکان
تنظیم کے زیر انتظام پروفائل ڈیوائس مینجمنٹ سے آتا ہے۔ پروفائل سرور کے پتے، تصدیق کا انتظام اور وہ پالیسی رکھتا ہے جس کی تنظیم کو ضرورت ہے، اور VPN منتظم وہ شخص ہے جو یہ فراہم کرتا ہے۔ اسکرپٹ کو فہرست میں ملی نمایشی نام سے وہ سیٹنگز دوبارہ نہیں بنانی چاہئیں۔
مقامی ذاتی VPN ترتیب Apple کے Network Extension API کے ذریعے بنائی جاتی ہے، جو اندرونی IPsec اور IKEv2 پروٹوکولز کا احاطہ کرتا ہے۔ یہ ایک ایپلیکیشن انٹرفیس ہے جس میں محفوظ کرنے کا مرحلہ اور صارف کی منظوری شامل ہے، ایسا shell کمانڈ نہیں جو وینڈر کی فراہم کردہ ہر قسم کی سرنگ خاموشی سے بنائے۔
تیسری پارٹی کا کلائنٹ تیسرا معاملہ ہے جس کا اپنا درآمدی فارمیٹ، اپنا انتظامی آلہ اور اکثر اپنا مراعات یافتہ معاون ہوتا ہے۔ اس کا سیشن اسی وینڈر کے عمل کی ملکیت ہے۔ ملتے جلتے نام کی نظام خدمت تلاش کرنا اس بات کا ثبوت نہیں کہ کوئی نظام کمانڈ سرنگ کو کنٹرول کرتا ہے، اور ایسا فرض کرنا ایسے اسکرپٹ پیدا کرتا ہے جو کام کرتے دکھتے ہیں جب تک وینڈر کلائنٹ کو اپ ڈیٹ نہ کرے۔
مقامی تیاری میں محفوظ کرنا اور منظوری شامل ہے
Apple کا ماڈل ہے لوڈ کریں، تبدیل کریں، محفوظ کریں۔ ایپلیکیشن آغاز کے بعد اپنے پہلے محفوظ کرنے سے پہلے موجود ترجیحات لوڈ کرتی ہے، ترتیب بدلتی ہے اور پھر اسے محفوظ کرتی ہے۔ جب محفوظ نہ ہو سکے تو اطلاع دیتی ہے، اور اس نتیجے کو نظر انداز کرنا تیاری کی ناکامی کو تین مراحل بعد کنکشن کی ناکامی بنا دیتا ہے۔
پہلے محفوظ کرنے کے لیے صارف کا ایپلیکیشن منظور کرنا بھی ضروری ہے۔ یہ جان بوجھ کر بنائی گئی حفاظتی حد ہے، اور اس کا مطلب ہے کہ نئے Mac پر پہلا اجرا متعامل ہوتا ہے، اگرچہ بعد کے ہر کنیکٹ اور ڈسکنیکٹ کو خودکار کیا جا سکتا ہے۔ پہلے اجرا کو انسان کی موجودگی والا انسانی کام سمجھ کر منصوبہ بنائیں۔ دوسرے اجرا سے خودکار کریں، اور یہ بات رن بک میں لکھیں تاکہ کوئی ناممکن کا وعدہ نہ کرے۔ مکمل غیر نگرانی والے پہلے اجرا کا وعدہ کرنے والا تعیناتی منصوبہ ایسی چیز کا وعدہ کرتا ہے جو پلیٹ فارم پیش نہیں کرتا۔
Apple یہ بھی تجویز کرتا ہے کہ API پر انحصار سے پہلے کنفیگریشن پروفائل کے ساتھ سرور کی مطابقت کی تصدیق کریں۔ یہ جانچ پہلے کرنے سے «سرور اس کلائنٹ کو قبول نہیں کرے گا» اور «کلائنٹ نے کبھی سیٹنگز محفوظ نہیں کیں» الگ ہو جاتے ہیں، اور یہ مختلف ٹیموں کے لیے مختلف ٹکٹ ہیں۔
دہرایا جانے والا اسٹارٹ کمانڈ کیا فرض کر سکتا ہے
تیاری کے بعد اسکرپٹ اپنے مالک کے انٹرفیس کے ذریعے محفوظ طریقے سے موجودہ کنکشن کو نشانہ بنا سکتا ہے۔ اسے کنکشن کی مستحکم شناخت اور آپ کی مطلوبہ کارروائی دیں، اور کچھ نہیں۔ اسے اندازہ لگایا گیا ترجیحی راستہ نہیں پڑھنا چاہیے، اور یہ نہیں فرض کرنا چاہیے کہ مینو میں دکھایا گیا نام پورے نظام میں منفرد ہے۔
مقامی کنکشنز کے لیے scutil --nc start جیسی نام والی سیشن درخواست ایک کنٹرول کارروائی ہے۔ یہ سرور سیٹنگز انسٹال نہیں کرتی، اسناد درآمد نہیں کرتی اور پہلے محفوظ کرنے کی اجازت نہیں دیتی۔ اسے زنجیر کا آخری مرحلہ سمجھیں، کبھی پوری زنجیر نہیں۔
راز کمانڈ لائن دلائل اور عام تشخیصی آؤٹ پٹ سے باہر رکھیں۔ تعیناتی نے جو بھی شناخت کا طریقہ چنا ہو، اسٹارٹ کمانڈ کو اسی پر انحصار کرنا چاہیے، اور shell کی تاریخ میں چپکایا گیا پاس ورڈ کسی بھی جائزے میں ایک دریافت ہے۔
دو قبولیت جانچ
پہلی جانچ تیاری ہے: نئی انسٹال شدہ Mac لیں اور ثابت کریں کہ ترتیب موجود ہے، صحیح منتظم کی ملکیت ہے اور مکمل طور پر منظور شدہ ہے۔ کنیکٹیویٹی جانچنے سے پہلے یہ کریں، کیونکہ غیر تیار مشین پر کنکشن ٹیسٹ اسکرپٹ کے بارے میں کچھ ثابت نہیں کرتا۔
دوسری جانچ سیشن ہے: کنیکٹ ہوں، مجاز وسیلے تک پہنچیں اور صاف طریقے سے ڈسکنیکٹ ہوں۔ اب ہر ناکامی کا مالک ہے، اور دو کام الگ کرنے کا یہی عملی فائدہ ہے۔ غائب پروفائل ترسیل کا مسئلہ ہے، محفوظ کرنے کی غلطی منظوری کا مسئلہ ہے، مسترد لاگ ان تصدیق کا مسئلہ ہے، اور کامیاب آغاز کے بعد وقت کا ختم ہونا سیشن کی تہہ ہے۔ ان میں سے کوئی بھی «اسکرپٹ خراب ہے» نہیں۔