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 |
ردیف‌ها را به‌عنوان یک سیاست بخوانید، نه فهرستی از موارد. ردیف دوم همان است که بیشتر اسکریپت‌ها جا می‌اندازند، و تنها ردیفی است که یک پایشگر را از ماشینی که اصرار دارد حق با اوست جدا می‌کند.
وضعیت مشاهده‌شده یک ترجیح نیست
مدل وضعیت Network Extension اپل حالت‌های connecting، connected، disconnecting، disconnected و recovery را گزارش می‌کند. هر پنج حالت اتصال را توصیف می‌کنند. هیچ‌یک نمی‌گوید «کاربر خواست این پروفایل متوقف بماند»، چون این اصلاً حالت اتصال نیست. کلاینت‌هایی که بر آن چارچوب ساخته نشده‌اند، کنترل‌های پشتیبانی‌شده و فراخوانی‌های وضعیت خودشان را ارائه می‌دهند، و همان مرز را با واژگان خودشان می‌کشند.
نتیجه این است که وضعیت قطع‌شده هرگز به‌تنهایی قابل تفسیر نیست. یعنی یکی از دست‌کم سه چیز: تونل افتاد، کاربر آن را متوقف کرد، یا سیستم میان تلاش‌هاست. فقط سابقه قصد خودتان می‌تواند آن‌ها را از هم جدا کند. آن سابقه را بنویسید، اگر باید از راه‌اندازی دوباره جان سالم به در ببرد آن را در میان راه‌اندازی‌ها نگه دارید، و آن را در لحظه‌ای که کاربر عمل می‌کند به‌روز کنید، نه اینکه بعداً از یک خط گزارش استنباطش کنید.
scutil --nc list
scutil --nc status "Office VPN"چه کس دیگری مجاز است این پروفایل را شروع کند
توقف‌دهی‌ای که کمک‌کننده شما وعده می‌دهد فقط به‌اندازه دیگر مالکان همان پروفایل قوی است. یک قاعده On Demand، یک پیکربندی مدیریت‌شده یا یک کلاینت دوم همه می‌توانند اتصال بخواهند، و کمک‌کننده شما خراب به نظر می‌رسد در حالی که دقیقاً مطابق نوشته رفتار می‌کند.
همه سازوکارهایی را که می‌توانند پروفایل را شروع کنند پیدا کنید پیش از آنکه وعده احترام به توقف بدهید، و بنویسید کدام برنده است. وقتی یک سرویس مدیریت‌شده عامدانه یک گزینه توقف شخصی را دریغ می‌کند، این تصمیم مدیر درباره سیاست است، نه شکافی که اسکریپت با جنگیدن با مدیریت پر کند.
تلاش‌های دوباره را کسل‌کننده کنید
تعداد تلاش‌ها را محدود کنید و هر یک را به چیزی که تغییر کرده پاسخگو کنید: شبکه برگشت، دروازه پاسخ داد، اعلان اعتبارنامه کامل شد. دروازه در دسترس نبودن، هویت منقضی‌شده و عامل دوم ردشده سه پاسخ متفاوت لازم دارند، و یک حلقه تنگ به هر سه یک پاسخ می‌دهد.
ببینید یک تلاش دوباره سریع واقعاً چه چیزی روی صفحه تولید می‌کند. گفت‌وگوهای تکراری که کاربر رد می‌کند بدتر از یک پیام خطای روشن هستند، و مردم را آموزش می‌دهند که بدون خواندن از اعلان‌ها رد شوند.
توقف و سیاست ترافیک وعده‌های جداگانه‌ای هستند
تونلی که کاربر متوقف کرده اغلب ترافیک را عمداً مسدود نگه می‌دارد، که تمام هدف یک سیاست به سبک kill switch است. این یعنی توقف باید دقیقاً یک چیز را وعده بدهد: بازیابی متوقف می‌شود. نباید بی‌صدا تغییر دهد که شبکه چه چیزی را مجاز می‌داند.
رفتار ترافیک را جداگانه تعیین کنید، آن را کنار کنترل توقف مستند کنید، و چه تونل متوقف باشد، چه شکست خورده و چه غایب، آن را سازگار نگه دارید. وگرنه کاربر یاد می‌گیرد که زدن قطع اتصال کار غیرقابل پیش‌بینی می‌کند، و بلیت پشتیبانی بعدی درباره شبکه‌ای است که «گاهی بدون دلیل قابل مشاهده از کار می‌افتد».