این test کافی برای تعیین که آیا من killswitch کار می کند?

به نوبه خود در من vpn و اتصال به وب سایت (من می دانم که آی پی آدرس خود) و سپس قطع ارتباط vpn است که صفری است که مرورگر من بود با استفاده از خاتمه می یابد. در نگاه Wireshark که برای دیدن اگر کامپیوتر من همه اتصالات که ادرس وب سایت ساخته شده است. اگر نه آن killswitch شبکه اختصاصی مجازی کار می کند پس از آن می رسد. (هنگامی که بیش از vpn, این فقط نشان می دهد اتصال به سرور vpn, بنابراین تا زمانی که آن آی پی سایت های که متصل به معنی در بدون vpn را نشان می دهد نیست، خوب به نظر می رسد)

این کافی است؟ هوشمندانه تر راه بروید در این مورد وجود دارد؟ (من می خوام به Wireshark، فقط آن را کردم).

خرید فیلترشکن

2 دیدگاه برای “این test کافی برای تعیین که آیا من killswitch کار می کند?”

  1. Smartest to least smart:

    1. Virtual network / virtual router: disable all host traffic except through guest VM instance running VPN [leak proof]
    2. Virtual guest with VPN [leak proof]
    3. Router with VPN client + policy routing [leak proof, but how do you **know** all the time. Firmware can change. Router can change]
    4. Software firewall block all traffic except from LAN-LAN, VPN provider, and VPN interface [leak proof, but can be tampered or disabled]
    5. Routing rules. Requires advanced knowledge of routing for that OS [leaks implementation dependent]
    6. VPN provider client with verified kill switch [leak proof unstable, providers change software all the time]
    7. Application binding to network interface [leak proof, but specific to only a few applications. Configuration mistakes can happen at any time]
    8. Network monitoring script [potentially leaky]
    9. Application monitoring script [assumed leaky]
    10. Manually shutting down router [very leaky]
    11. Manually shutting down applications or client machines [extremely leaky]

    If your setup is an application monitoring script, you can see it ranks very low in that list with a high chance of leaks.

    None of the first four can leak, assuming they are tested to work the first time and nothing unexpected changes. The 5th is riskier because it depends on implementation.

    The 6th relies on VPN provider software competence – surprisingly few providers have leak-proof clients in all circumstances – and there are no guarantees their software will not change adversely.

    The rest are probably not worth the effort, since a leak is a leak. Extent here is only to show the likelihood of leaks, not to indicate acceptance of any leaks at all.

دیدگاه‌ها بسته شده‌اند.