برنامه VPN کرش کرد: آیا کیل سوییچ هنوز روشن است؟
کرش می‌تواند مسدودسازی را سر جایش بگذارد یا آن را همراه با فرآیند بردارد، بسته به اینکه چه کسی آن را اجرا می‌کند. پیش از تصمیم‌گیری، کلاینت، سیستم‌عامل و فایروال را بررسی کنید.
از همان‌جا شروع کنید که کاربر شروع می‌کند: پنجره کلاینت رفته است، آیکون در سینی سیستم ناپدید شده و مرورگر یا بارگذاری می‌کند یا نمی‌کند. همین مشاهده به‌تنهایی نمی‌تواند بگوید مسدودسازی دوام آورده است یا نه. پاسخ بستگی دارد به اینکه کدام مؤلفه قواعد را نگه می‌دارد، آیا آن مؤلفه همراه پنجره مرده است و آیا پلتفرم اجرا را بیرون از برنامه نگه می‌دارد. از پنجره به فرآیند، سپس به فایروال و سپس به مسیر واقعی بروید.
اول ریبوت نکنید؛ ریبوت معمولاً شواهد را از بین می‌برد.
از چیزی شروع کنید که هنوز در حال اجراست
پیش از دست زدن به هر چیزی فهرست فرآیندها را باز کنید. کلاینت رومیزی معمولاً به یک فرآیند رابط کاربری و یک سرویس یا دیمن تقسیم می‌شود و کرش در اولی لزوماً دومی را متوقف نمی‌کند. در Windows ممکن است سرویس هنوز در فهرست باشد، در Linux ممکن است واحد هنوز فعال باشد و در Android پس از دادن رضایت، تونل متعلق به سیستم است. این سه واقعیت را به همین ترتیب بخوانید.
اگر دیمن زنده باشد، تونل هم احتمالاً زنده است و پنجره گم‌شده فقط ظاهری است.
Get-Process | Where-Object { $_.ProcessName -match 'vpn|wireguard|openvpn' }
Get-Service | Where-Object { $_.Name -match 'vpn|wireguard|openvpn' }
netsh wfp show state
systemctl status wg-quick@wg0 --no-pager
ps -eo pid,comm,args | grep -E 'openvpn|wg'
nft list ruleset | head -40
مسدودسازی را از مجری بخوانید، نه از برنامه
اگر کلاینت کیل سوییچ خود را با درج قواعد فایروال پیاده‌سازی کند، آن قواعد متعلق به سیستم‌عامل‌اند و از فرآیندی که آن‌ها را ساخته زنده‌تر می‌مانند. آن‌گاه کرش شما را بدون هیچ رابطی برای خاموش کردن مسدود رها می‌کند و این شبیه شبکه خراب است نه محافظت. اگر در عوض مسدودسازی درون مسیر بسته‌های خود کلاینت باشد، کشتن فرآیند در همان لحظه مسدودسازی را برمی‌دارد.
Android این را باز هم طور دیگری مدیریت می‌کند: always-on VPN همراه با lockdown یک تنظیم پلتفرم است، بنابراین مسدودسازی مستقل از فرآیند برنامه باقی می‌ماند و سیستم ممکن است سرویس را دوباره راه‌اندازی کند. برای رفتار دقیق به مستندات پلتفرم مراجعه کنید، نه اینکه فرض کنید با کلاینت رومیزی یکی است.
خروج تمیز را از کرش تشخیص دهید
یک Quit معمولی معمولاً مسیر خاموش‌شدن کلاینت را اجرا می‌کند که قواعد را برمی‌دارد و تونل را عمداً می‌بندد. کرش از آن مسیر می‌گذرد و هر چیزی را که مجری قبلاً نصب کرده باقی می‌گذارد. تفاوت در زمان‌مهر قواعد نسبت به خروج فرآیند و در این دیده می‌شود که آیا رابط تونل قدیمی بدون مالک هنوز وجود دارد.
این تمایز بازیابی شما را تعیین می‌کند: خروج تمیز ممکن است به اتصال تازه نیاز داشته باشد، در حالی که کرش ممکن است نیازمند برداشتن قواعد باقی‌مانده از طریق اقدام تعمیر پشتیبانی‌شده کلاینت باشد.
بدون شکستن کنترل‌های دیگر بازیابی کنید
کلاینت را از طریق جریان کاری مستندش دوباره راه‌اندازی کنید، سپس هر دو نیمه شرط را بررسی کنید: تونل ترافیک را حمل می‌کند و مسدودسازی هنوز وقتی باید اعمال می‌شود. شستن کل فایروال برای بازگرداندن اتصال، کنترل‌های نامرتبط را هم برمی‌دارد و این معاوضه به‌ندرت ارزشش را دارد.
برای کرش تکرارشونده، نسخه کلاینت، بیلد پلتفرم و گزارش‌های محدودی که فروشنده می‌خواهد را جمع کنید. پروفایل کلاینت، کلید خصوصی یا گزارش کامل اتصال برای حساب دیگر برای گزارش کرش لازم نیست و گنجاندن آن‌ها یک پرونده پشتیبانی را به مشکل مدیریت داده تبدیل می‌کند.
یک کرش دلیل نشت نیست. دلیل، بسته‌ای مشاهده‌شده است که از مسیری خارج می‌شود که سیاست باید جلوی آن را می‌گرفت، درست در لحظه‌ای که کلاینت خاموش بود ضبط شده. آن را عمداً با مقصدی بی‌خطر آزمایش کنید و بنویسید کدام لایه اجرا دوام آورد.