قطع شدن VPN هنگام خاموش شدن صفحه: کدام چرخه عمر؟
صفحه قفل‌شده می‌تواند کلاینت را معلق کند، یک نگاشت را منقضی کند یا یک نشست برنامه را بکشد. یک آزمون کنترل‌شده آن‌ها را پیش از هر تغییری در تنظیمات جدا می‌کند.
انتقال همان لحظه‌ای که صفحه تاریک می‌شود متوقف می‌شود و نشان چند ثانیه بعد آن را دنبال می‌کند. سه چیز متفاوت این تصویر را می‌سازند: فرایند کلاینت محدود می‌شود، مسیر بی‌کار می‌ماند و نگاشتش را از دست می‌دهد، یا برنامه نشستی را از دست می‌دهد که تونل هرگز متوجه آن نشد. هر کدام شواهد خودش را دارد و هر راه‌حل به لایه‌ای متفاوت تعلق دارد. ترتیب زیر آن‌ها را با یک آزمون کنترل‌شده به جای جستجوی یک‌باره همه تنظیمات جدا می‌کند.
سه خرابی که یکسان به نظر می‌رسند
فرایند پس‌زمینه محدودشده ارسال keepalive را متوقف می‌کند و طرف مقابل در نهایت تونل را مرده اعلام می‌کند. نگاشت بی‌کاری روی مسیر ممکن است در حال خواب دستگاه منقضی شود، بنابراین ترافیک برگشتی هرگز به کلاینتی نمی‌رسد که هنوز کاملاً زنده است. برنامه می‌تواند اتصال خودش را از دست بدهد در حالی که تونل برپا می‌ماند، که کادر خطایی با نشان VPN سالم در پشت آن تولید می‌کند. از دید کاربر، هر سه به صورت قطع VPN هنگام خاموش شدن صفحه خوانده می‌شوند.
این تمایز مهم است، زیرا راه‌حل‌ها در عمل یکدیگر را نقض می‌کنند. معاف کردن کلاینت از محدودیت‌های انرژی حالت اول را درست می‌کند و برای نگاشت منقضی‌شده کاری نمی‌کند. طولانی‌تر کردن keepalive حالت دوم را درست می‌کند و در سوم باتری را هدر می‌دهد، جایی که از ابتدا هیچ چیز شبکه‌ای غلط نبود.
حالت فعال و بی‌کار را تحت کنترل مقایسه کنید
همه چیز را ثابت نگه دارید: همان دستگاه، همان شبکه، همان نقطه پایانی، همان برنامه. صفحه را برای بازه کوتاه ثابتی قفل کنید و سه مشاهده را یادداشت کنید: آیا کلاینت قطع اتصال را گزارش می‌کند، آیا درخواست تازه هنگام باز کردن قفل کار می‌کند، و آیا انتقال موجود ادامه یافت. سپس با یک keepalive یا درخواست دوره‌ای در حال اجرا تکرار کنید و دو اجرا را مقایسه کنید. یک متغیر تغییرکرده بین دو اجرا از یک هفته گزارش داستانی بهتر است.
زمان به دفترچه تعلق دارد. قطع شدن پس از نود ثانیه بوی نگاشت یا بازه keepalive می‌دهد، در حالی که قطع شدن در لحظه قفل به تعلیق فرایند اشاره دارد. هم محرک و هم بازه را یادداشت کنید، چون تلاش بعدی چیزی برای مقایسه لازم دارد.
سیاست پس‌زمینه پلتفرم را بخوانید
در اندروید چرخه عمر سرویس VPN بخشی از پلتفرم است و always-on و block-without-VPN دو کلید جدا با اثرهای جدا هستند. کلاینتی که always-on نیست می‌تواند وقتی سیستم منابع را پس می‌گیرد متوقف شود و هیچ تنظیمی در برنامه آن را تغییر نمی‌دهد. iOS محدودیت‌های پس‌زمینه خودش را بر فراهم‌کننده تونل اعمال می‌کند و رفتار مستندشده با یک سرویس‌دهنده رومیزی که صرفاً به کار ادامه می‌دهد متفاوت است. مستندات پلتفرم را برای همان مؤلفه بخوانید، نه یک راهنمای عمومی بهینه‌سازی باتری.
دستگاه‌های مدیریت‌شده لایه دیگری اضافه می‌کنند. یک سیاست می‌تواند تنظیم شخصی را زیر پا بگذارد، بنابراین تغییری که کار می‌کند در تازه‌سازی بعدی سیاست به حالت قبل برمی‌گردد. اگر نیاز واقعی است از فرایند استثنای پشتیبانی‌شده سازمان استفاده کنید و بنویسید چرا این استثنا وجود دارد.
دستگاه پس از بیدار شدن چه می‌کند
اتصال مجدد خودکار همان مسدود کردن ترافیک در طول شکاف نیست. هر دو را بررسی کنید: آیا تونل برمی‌گردد و آیا برنامه‌ای که در طول شکاف تلاش کرد بفرستد بدون محافظت بیرون رفت. کلاینتی که در دو ثانیه دوباره وصل می‌شود اما در ثانیه اول یک پرس‌وجوی DNS را نشت می‌دهد برای دستگاه کاری سیاست خرابی نادرست دارد. با درخواست‌های بی‌خطر و مقصدی که کنترلش می‌کنید آزمایش کنید.
بازیابی برنامه سومین پرسش است. تونلی که برمی‌گردد نشست SSH زمان‌گذشته را تعمیر نمی‌کند و کاربران اغلب آن از دست رفتن نشست را خرابی VPN گزارش می‌کنند. محرک، ساخت کلاینت و زمان دقیق را با هم در گزارش نگه دارید، چون همان ترکیب یک چرخه عمر قابل پیش‌بینی خاموشی صفحه را از سروری که مستقل از دستگاه شکست می‌خورد جدا می‌کند.