Mac VPN، ڈس کنیکٹ دبانے کے فوراً بعد خود ہی دوبارہ منسلک ہو جاتا ہے
ہر منقطع حالت کو خرابی سمجھنے والا مانیٹر ڈس کنیکٹ بٹن سے لڑے گا۔ ارادے اور مشاہدہ شدہ حالت کو الگ رکھیں، پھر کوششوں کو محدود کریں۔
ڈس کنیکٹ دبانا کام کرتا ہے، اور دس سیکنڈ بعد سرنگ بہرحال واپس آ جاتی ہے۔ یہ لوپ شاذ و نادر ہی VPN کلائنٹ کا غلط رویہ ہوتا ہے؛ یہ ایک ریکوری اسکرپٹ ہے جو ہمیشہ صرف ایک سوال پوچھتا تھا، «کیا یہ نیچے ہے؟»، اور جوڑ کر اس کا جواب دیتا تھا۔ جب آپ صارف کے جواب دیے گئے سوال کو سسٹم کے بتائے گئے سوال سے الگ کرتے ہیں، تو درستگی طویل انتظار کے بجائے تھوڑی سی حالت بن جاتی ہے۔
دو سوال، ایک نہیں
کیا یہ پروفائل ابھی منسلک ہونا چاہیے، اور سسٹم اس لمحے کیا بتا رہا ہے؟ یہ مختلف مالکان کے ساتھ مختلف سوالات ہیں، اور ریکوری پالیسی کو عمل کرنے سے پہلے دونوں چاہیے۔ ارادہ وہ چیز ہے جو آپ کا ٹول طے کرتا اور یاد رکھتا ہے۔ مشاہدہ شدہ حالت وہ چیز ہے جو پلیٹ فارم آپ کو بتاتا ہے۔
| Intent | What you observe | What to do |
|---|---|---|
| Wanted | Dropped unexpectedly | Allow one supported recovery attempt |
| Paused by the user | Disconnected | Do nothing until intent changes |
| Wanted | Already connecting | Wait instead of starting a rival attempt |
| Wanted | Authentication needs a person | Prompt, then stop replaying credentials |
قطاروں کو مقدمات کی فہرست کے بجائے پالیسی کے طور پر پڑھیں۔ دوسری قطار وہ ہے جو زیادہ تر اسکرپٹس چھوڑ دیتے ہیں، اور یہی واحد قطار ہے جو مانیٹر کو ایسی مشین سے الگ کرتی ہے جو اپنے درست ہونے پر اصرار کرتی ہے۔
مشاہدہ شدہ حالت کوئی ترجیح نہیں
Apple کا Network Extension حالت ماڈل connecting, connected, disconnecting, disconnected اور recovery حالتوں کی اطلاع دیتا ہے۔ پانچوں کنکشن بیان کرتی ہیں۔ ان میں سے کوئی یہ نہیں کہتی «صارف نے کہا کہ یہ پروفائل معطل رہے»، کیونکہ یہ کنکشن کی حالت ہی نہیں ہے۔ جو کلائنٹس اس فریم ورک پر نہیں بنے، وہ اپنے معاون کنٹرولز اور حالت کالز ظاہر کرتے ہیں، اور وہ اپنی اصطلاحات میں وہی لکیر کھینچتے ہیں۔
نتیجہ یہ ہے کہ منقطع حالت کی کبھی تنہا تشریح نہیں کی جا سکتی۔ اس کا مطلب کم از کم تین میں سے ایک ہے: سرنگ گر گئی، صارف نے اسے روک دیا، یا سسٹم کوششوں کے درمیان ہے۔ صرف آپ کا اپنا ارادے کا ریکارڈ ہی انہیں الگ کر سکتا ہے۔ وہ ریکارڈ لکھیں، اگر اسے ری بوٹ سے بچنا ہے تو ری اسٹارٹس کے درمیان رکھیں، اور اسے اسی لمحے اپ ڈیٹ کریں جب صارف عمل کرتا ہے، بعد میں لاگ لائن سے اندازہ نہ لگائیں۔
scutil --nc list
scutil --nc status "Office VPN"اس پروفائل کو شروع کرنے کی اور کس کو اجازت ہے
آپ کے مددگار کا وعدہ کردہ توقف اسی پروفائل کے دیگر مالکان جتنا ہی مضبوط ہے۔ On Demand قاعدہ، زیر انتظام ترتیب یا دوسرا کلائنٹ سب کنکشن کی درخواست کر سکتے ہیں، اور آپ کا مددگار ٹوٹا ہوا دکھے گا جبکہ وہ ٹھیک ویسا ہی برتاؤ کر رہا ہوگا جیسا لکھا ہے۔
پروفائل شروع کر سکنے والا ہر طریقہ کار تلاش کریں توقف کا احترام کرنے کا وعدہ کرنے سے پہلے، اور لکھیں کہ کون جیتتا ہے۔ جب کوئی زیر انتظام سروس جان بوجھ کر ذاتی توقف کا آپشن نہیں دیتی، تو یہ پالیسی کے بارے میں منتظم کا فیصلہ ہے، نہ کہ ایسا خلا جسے اسکرپٹ انتظام سے لڑ کر بھرے۔
دوبارہ کوششوں کو بورنگ بنائیں
کوششوں کی تعداد محدود کریں اور ہر ایک کو بدلی ہوئی کسی چیز پر ردعمل دینے والا بنائیں: نیٹ ورک واپس آیا، گیٹ وے نے جواب دیا، اسناد کی درخواست مکمل ہوئی۔ دستیاب نہ ہونے والا گیٹ وے، میعاد ختم شدہ شناخت اور مسترد شدہ دوسرا عنصر تین مختلف جوابات چاہتے ہیں، اور تنگ لوپ تینوں کو ایک ہی دیتا ہے۔
دیکھیں کہ تیز دوبارہ کوشش اسکرین پر واقعی کیا پیدا کرتی ہے۔ صارف کی بند کی ہوئی بار بار آنے والی ڈائیلاگز ایک واضح ناکامی پیغام سے بدتر ہیں، اور وہ لوگوں کو پرامپٹ پڑھے بغیر کلک کرنا سکھاتی ہیں۔
توقف اور ٹریفک پالیسی الگ وعدے ہیں
صارف کی روکی ہوئی سرنگ اکثر ٹریفک کو جان بوجھ کر بلاک رہنے دیتی ہے، اور یہی kill switch طرز کی پالیسی کا پورا مقصد ہے۔ اس کا مطلب ہے کہ توقف کو صرف ایک چیز کا وعدہ کرنا چاہیے: ریکوری رک جاتی ہے۔ اسے خاموشی سے یہ نہیں بدلنا چاہیے کہ نیٹ ورک کس چیز کی اجازت دیتا ہے۔
ٹریفک کے رویے کا الگ سے فیصلہ کریں، اسے توقف کنٹرول کے ساتھ دستاویز کریں، اور سرنگ معطل، ناکام یا غائب ہونے کی صورت میں بھی اسے یکساں رکھیں۔ ورنہ صارف سیکھ جاتا ہے کہ ڈس کنیکٹ دبانے سے کچھ غیر متوقع ہوتا ہے، اور اگلی معاونت ٹکٹ ایسے نیٹ ورک کے بارے میں ہوگی جو «کبھی کبھی بغیر کسی نظر آنے والی وجہ کے کام کرنا بند کر دیتا ہے»۔