کیل‌سوئیچ در فهرست امکانات تقریباً هیچ چیز درباره آنچه هنگام افتادن تونل رخ می‌دهد نمی‌گوید. یک پیاده‌سازی فرایندهای انتخابی را می‌بندد، دیگری فیلترهای بسته را در مرز سیستم‌عامل نصب می‌کند و سومی فقط تلاش می‌کند دوباره متصل شود. تفاوت در ثانیه‌های پس از خرابی دیده می‌شود، نه در صفحه تنظیمات. این بررسی‌ها را به ترتیب انجام دهید و در اولین موردی که نمی‌توانید صادقانه پاسخ دهید توقف کنید، چون پوشش واقعی شما همان‌جا تمام می‌شود.

نخست سازوکار اعمال را نام ببرید

پایان دادن به فرایندها ویژگی چرخه عمر برنامه است. پس از تشخیص خرابی تونل، برنامه‌های انتخابی را می‌یابد و می‌بندد. هر چیزی که فرایند اصلی نیست زنده می‌ماند: سرویس‌های کمکی، همگام‌سازی پس‌زمینه و هر برنامه‌ای که یک ثانیه بعد آغاز شود، هر یک چرخه عمر و زمان‌بندی خود را دارند.

فیلتر بسته ویژگی سیستم‌عامل است. ترافیکی را که مسیر مجاز را دنبال نمی‌کند رد می‌کند، که وعده‌ای قوی‌تر است، اما تنها تا آنجا که قاعده واقعاً با آن مطابقت دارد. خانواده نشانی، رابط، برنامه‌های استثناشده و استثناها این را تعیین می‌کنند، نه برچسب داخل کلاینت.

آیا مسدودسازی از کلاینت بیشتر می‌ماند؟

چهار پرسش را به این ترتیب بپرسید: در خرابی، در خروج دستی، در خروج از حساب و در راه‌اندازی مجدد چه می‌شود. قاعده‌ای که خود کلاینت نگه می‌دارد معمولاً در خاموشی مرتب حذف می‌شود و اغلب پس از خرابی باقی می‌ماند. قاعده‌ای که در انبار پلتفرم نصب شود می‌تواند برعکس عمل کند: هم از کلاینت و گاهی از حذف نصب جان سالم به در ببرد.

کلاینت را در میانه یک دانلود طولانی ببندید و ببینید انتقال متوقف می‌شود یا ادامه می‌یابد.

به دنبال سوراخ‌های معمول بگردید

IPv6 اولین است. قاعده‌ای که برای نشانی‌های IPv4 نوشته شده ترافیک IPv6 را دست‌نخورده می‌گذارد و بسیاری از کلاینت‌ها فقط نیمه v4 را می‌نویسند. دومی رابط است: اتصال USB، آداپتور Wi-Fi دوم و مودم سلولی ممکن است در قاعده‌ای که به اتصال اصلی محدود است گنجانده نشوند. برنامه‌های استثناشده و استثناهای شبکه محلی سومی هستند.

در Windows می‌توانید قاعده‌های نصب‌شده را بخوانید به‌جای اعتماد به کلید: Get-NetFirewallRule -DisplayName '*VPN*' و netsh wfp show filters هر دو نشان می‌دهند چه چیزی وجود دارد. در Linux، iptables -S، ip6tables -S و nft list ruleset موارد رایج را پوشش می‌دهند و مقایسه هر سه نکته اصلی است.

DNS همان نشتی معمول است

مسدود کردن TCP در حالی که UDP 53 باز می‌ماند به شما کیل‌سوئیچ بسیار قانع‌کننده‌ای می‌دهد که هنوز به هر پرسش نام میزبان پاسخ می‌دهد. همین موضوع وقتی رخ می‌دهد که DNS به یک حل‌کننده روی رابط دیگر سپرده شود، یا وقتی کلاینت فقط v4 را مسدود می‌کند و حل‌کننده از طریق v6 در دسترس است.

با افتادن تونل، یک نام شناخته‌شده را حل کنید و ببینید پاسخی برمی‌گردد. اگر برگردد، ترافیک کاملاً مسدود نیست، هر چه نماد وضعیت بگوید.

گذار را آزمایش کنید، نه کلید را

خاموش کردن VPN از منوی خودش یک خاموشی مرتب است و مورد مرتب را هر پیاده‌سازی خوب انجام می‌دهد. گذاری که اهمیت دارد گذار خشن است: فرایند تونل را بکشید، شبکه را بیرون بکشید، بگذارید سرور پاسخ دادن را متوقف کند. سپس درخواستی آغاز کنید و ببینید شکست می‌خورد یا بی‌صدا از پیوند فیزیکی استفاده می‌کند.

نتیجه یک لپ‌تاپ به تلفن یا روتر منتقل نمی‌شود. APIهای پلتفرم متفاوت، پیش‌فرض‌های متفاوت، و در Android تفاوت آشکار است: حالت always-on با مسدودسازی را سیستم اعمال می‌کند نه کلاینت، پس وقتی کلاینت کار نمی‌کند همچنان کار می‌کند. راهنمای VPN اندروید این تقسیم را توصیف می‌کند.

راهی برای بازگشت نگه دارید

مسدودسازی در سطح سیستم حالت خرابی معکوس دارد. فیلترهایی که از کلاینت بیشتر می‌مانند می‌توانند پس از حذف نصب ماشین را کاملاً بی‌شبکه بگذارند، که یک تماس پشتیبانی بدون علت آشکار است. پیش از فعال کردن هر کیل‌سوئیچی که قاعده‌های پلتفرم را می‌نویسد، یادداشت کنید چگونه حذف می‌شود و مسیر تعمیر فروشنده را جایی که می‌توانید پیدا کنید نگه دارید.

اگر نمی‌توانید به بررسی‌های خرابی، IPv6، DNS و گذار برای کلاینت خود پاسخ دهید، آن را کلیدی در سطح برنامه با شکاف‌های شناخته‌شده بدانید و بر همان اساس برنامه‌ریزی کنید.

مقالات مرتبط