Blochează kill switch-ul traficul înainte ca aplicația VPN să pornească?

Un kill switch poate acoperi sau nu fereastra de dinainte ca aplicația lui să pornească, iar diferența este decisă de politica sistemului de operare, nu de pagina de marketing a clientului. O casetă de pornire automată dovedește că ceva este programat să pornească. Nu dovedește că regulile de blocare există în momentul în care rețeaua urcă. Sunt două evenimente și doar unul dintre ele protejează traficul.

Parcurgeți lista de verificare în ordine, pentru că fiecare pas restrânge ceea ce testați de fapt.

De unde vine de fapt blocarea

Există două familii de implementare. Fie platforma instalează blocarea, pentru că știe de tunel înainte ca vreo aplicație să ruleze, fie clientul instalează singur blocarea după ce pornește. Prima poate exista înainte de autentificare. A doua nu poate exista înaintea procesului său, oricât de devreme ar fi programat acel proces. Identificați pe ce familie vă bazați înainte de a testa ceva.

Pe Android, VPN-ul mereu activ combinat cu setarea care blochează conexiunile fără VPN este politică a platformei, configurată în setările sistemului și nu doar în interiorul unui client. Pe dispozitivele administrate poate fi setată pentru dumneavoastră. Un client care doar pornește la boot nu este același mecanism.

Separați fereastra de serviciu

O fereastră închisă nu este dovada că aplicarea regulii s-a oprit, iar o fereastră deschisă nu este dovada că tunelul este pregătit. Mulți clienți separă interfața, daemonul și aplicația din tavă. Tava este ceea ce vedeți; daemonul este ceea ce ține regulile.

Testați componenta, nu pictograma.

Testați intervalul de pornire în siguranță

Intervalul de testat începe la repornire sau la autentificare și se termină când tunelul se autentifică. Aplicațiile din fundal se conectează în acea perioadă, iar verificările de actualizare sunt vinovații obișnuiți. Folosiți activitate inofensivă și procedura documentată a furnizorului în loc să vă blocați propriul acces. Apoi repetați după o reconectare normală, pentru că traseul de reconectare și traseul de pornire la rece rulează cod diferit.

Un test făcut după ce tunelul este deja ridicat nu dovedește nimic despre pornire.

Citiți comportamentul la repornire dacă persistența este cerința. O setare poate supraviețui în configurație în timp ce aplicarea ei începe mai târziu, iar ambele fapte contează: politica salvată și momentul în care devine activă.

Citiți politica pentru fiecare platformă

Android expune mereu activ și blocarea ca întrerupătoare separate, iar ambele trebuie să fie pornite pentru protecția dinaintea pornirii. Windows are un concept de tunel de dispozitiv mereu activ configurat prin politică, care nu este același lucru cu un client în modul utilizator care pornește devreme. OpenVPN Connect își documentează propriul comportament de kill switch pentru fiecare platformă, iar domeniul documentat este ceea ce testați. Nu mutați numele unei setări dintr-un sistem în altul și nu presupuneți că sensul a călătorit cu el.

Un profil care cere o parolă interactivă are dependențe de pornire diferite de cele ale unui tunel de mașină.

Ce să înregistrați

Notați ce mecanism este în vigoare, în ce etapă devine activ și ce trafic a fost încercat înainte de acea etapă. Înregistrați versiunea platformei, pentru că acest comportament se schimbă între versiuni și între configurațiile administrate și cele personale. Observați dacă clientul sau sistemul deține politica, deoarece asta decide cine poate remedia o lacună. Apoi retestați după orice actualizare a clientului sau a sistemului de operare.

Dacă lacuna contează, soluția durabilă este politica platformei, nu o întârziere de pornire mai scurtă.

Acesta este răspunsul la întrebarea inițială, formulat ca o condiție: un kill switch protejează traficul înainte ca aplicația să pornească doar atunci când blocarea este instalată de ceva ce există înaintea aplicației.