Bloqueja el kill switch el trànsit abans que s'iniciï l'aplicació VPN?

Un kill switch pot cobrir o no la finestra prèvia a l'inici de la seva aplicació, i la diferència la decideix la política del sistema operatiu, no la pàgina de màrqueting del client. Una casella d'inici automàtic demostra que alguna cosa està programada per iniciar-se. No demostra que existeixin regles de bloqueig en el moment en què la xarxa s'aixeca. Són dos esdeveniments, i només un d'ells protegeix el trànsit.

Feu la llista de verificació en ordre, perquè cada pas restringeix què esteu provant realment.

D'on ve realment el bloqueig

Hi ha dues famílies d'implementació. O la plataforma instal·la el bloqueig, perquè coneix el túnel abans que s'executi cap aplicació, o el client instal·la el bloqueig ell mateix després d'iniciar-se. La primera pot existir abans d'iniciar la sessió. La segona no pot existir abans que el seu procés, per aviat que estigui programat aquest procés. Identifiqueu de quina família depeneu abans de provar res.

A l'Android, la VPN sempre activa combinada amb el paràmetre de bloquejar connexions sense VPN és política de la plataforma, configurada als paràmetres del sistema i no només dins del client. Als dispositius gestionats us la poden configurar. Un client que només s'inicia en arrencar no és el mateix mecanisme.

Separeu la finestra del servei

Una finestra tancada no és prova que l'aplicació de la norma s'hagi aturat, i una finestra oberta no és prova que el túnel estigui preparat. Molts clients separen la interfície, el dimoni i l'aplicació de la safata. La safata és el que veieu; el dimoni és el que manté les regles.

Proveu el component, no la icona.

Proveu l'interval d'inici amb seguretat

L'interval que cal provar comença en reiniciar o iniciar sessió i acaba quan el túnel s'autentica. Les aplicacions de fons es connecten durant aquest període, i les comprovacions d'actualitzacions són els infractors habituals. Feu servir activitat inofensiva i el procediment documentat del proveïdor en lloc de bloquejar el vostre propi accés. Després repetiu-ho després d'una reconnexió normal, perquè el camí de reconnexió i el d'inici en fred executen codi diferent.

Una prova feta quan el túnel ja està aixecat no demostra res sobre l'inici.

Llegiu el comportament en reiniciar si la persistència és el requisit. Un paràmetre pot sobreviure a la configuració mentre la seva aplicació comença més tard, i tots dos fets importen: la política desada i el moment en què esdevé activa.

Llegiu la política per a cada plataforma

L'Android exposa el mode sempre actiu i el bloqueig com a commutadors separats, i tots dos han d'estar activats per a la protecció prèvia a l'inici. Windows té un concepte de túnel de dispositiu sempre actiu configurat per política, que no és el mateix que un client en mode usuari que s'inicia aviat. OpenVPN Connect documenta el seu propi comportament de kill switch per plataforma, i l'abast documentat és el que proveu. No passeu el nom d'un paràmetre d'un sistema a un altre i doneu per fet que el significat ha viatjat amb ell.

Un perfil que requereix una contrasenya interactiva té dependències d'inici diferents de les d'un túnel de màquina.

Què cal registrar

Anoteu quin mecanisme està en vigor, en quina etapa esdevé actiu i quin trànsit s'ha intentat abans d'aquella etapa. Registreu la versió de la plataforma, perquè aquest comportament canvia entre versions i entre configuracions gestionades i personals. Noteu si el client o el sistema posseeix la política, ja que això decideix qui pot corregir una llacuna. Després torneu a provar-ho després de qualsevol actualització del client o del sistema operatiu.

Si la llacuna importa, la solució duradora és la política de la plataforma, no un retard d'inici més curt.

Aquesta és la resposta a la pregunta original, formulada com a condició: un kill switch protegeix el trànsit abans que s'iniciï l'aplicació només quan el bloqueig l'instal·la alguna cosa que existeix abans que l'aplicació.