¿Bloquea el kill switch el tráfico antes de que arranque la aplicación VPN?
La protección en el arranque depende de quién instala el bloqueo y cuándo, no de una casilla de inicio automático. Compruebe la política de la plataforma antes de confiar en el cliente.
Un kill switch puede cubrir o no la ventana previa al arranque de su aplicación, y la diferencia la decide la política del sistema operativo y no la página de marketing del cliente. Una casilla de inicio automático demuestra que algo está programado para arrancar. No demuestra que existan reglas de bloqueo en el momento en que la red se levanta. Son dos acontecimientos, y solo uno de ellos protege el tráfico.
Recorra la lista de comprobación en orden, porque cada paso reduce lo que está probando realmente.
De dónde viene realmente el bloqueo
Hay dos familias de implementación. O la plataforma instala el bloqueo, porque conoce el túnel antes de que se ejecute ninguna aplicación, o el cliente instala el bloqueo por sí mismo después de arrancar. La primera puede existir antes de iniciar sesión. La segunda no puede existir antes que su proceso, por temprano que esté programado ese proceso. Determine en qué familia se apoya antes de probar nada.
En Android, la VPN siempre activa combinada con el ajuste de bloquear conexiones sin VPN es política de la plataforma, configurada en los ajustes del sistema y no solo dentro del cliente. En los dispositivos gestionados pueden dejarla configurada por usted. Un cliente que simplemente arranca al iniciar el sistema no es el mismo mecanismo.
Separe la ventana del servicio
Una ventana cerrada no es prueba de que la aplicación de la norma se haya detenido, y una ventana abierta no es prueba de que el túnel esté listo. Muchos clientes separan la interfaz, el demonio y la aplicación de la bandeja. La bandeja es lo que usted ve; el demonio es lo que sostiene las reglas.
Pruebe el componente, no el icono.
Pruebe el intervalo de arranque con seguridad
El intervalo que hay que probar empieza al reiniciar o iniciar sesión y termina cuando el túnel se autentica. Las aplicaciones en segundo plano se conectan durante ese periodo, y las comprobaciones de actualizaciones son los infractores habituales. Use actividad inofensiva y el procedimiento documentado del proveedor en lugar de bloquear su propio acceso. Después repita tras una reconexión normal, porque la ruta de reconexión y la de arranque en frío ejecutan código distinto.
Una prueba realizada después de que el túnel ya esté levantado no demuestra nada sobre el arranque.
Lea el comportamiento de reinicio si la persistencia es el requisito. Un ajuste puede sobrevivir en la configuración mientras su aplicación empieza más tarde, y ambos hechos importan: la política guardada y el momento en que se vuelve activa.
Lea la política por plataforma
Android expone el modo siempre activo y el bloqueo como conmutadores separados, y ambos deben estar activados para la protección previa al arranque. Windows tiene un concepto de túnel de dispositivo siempre activo configurado mediante política, que no es lo mismo que un cliente en modo usuario que arranca pronto. OpenVPN Connect documenta su propio comportamiento de kill switch por plataforma, y el alcance documentado es lo que usted prueba. No lleve un nombre de ajuste de un sistema a otro y suponga que el significado viajó con él.
Un perfil que exige una contraseña interactiva tiene dependencias de arranque distintas de las de un túnel de máquina.
Qué registrar
Anote qué mecanismo está en vigor, en qué etapa se vuelve activo y qué tráfico se intentó antes de esa etapa. Registre la versión de la plataforma, porque este comportamiento cambia entre versiones y entre configuraciones gestionadas y personales. Indique si el cliente o el sistema posee la política, ya que eso decide quién puede corregir una laguna. Después vuelva a probar tras cualquier actualización del cliente o del sistema operativo.
Si la laguna importa, la solución duradera es la política de la plataforma, no un retraso de arranque más corto.
Esa es la respuesta a la pregunta original, formulada como condición: un kill switch protege el tráfico antes de que arranque la aplicación solo cuando el bloqueo lo instala algo que existe antes que la aplicación.