Bloquea o kill switch o tráfico antes de que arrinque a aplicación VPN?

Un kill switch pode cubrir ou non a xanela previa ao arranque da súa aplicación, e a diferenza decídea a política do sistema operativo e non a páxina de márketing do cliente. Unha caixa de inicio automático demostra que algo está programado para arrancar. Non demostra que existan regras de bloqueo no momento en que a rede se levanta. Son dous acontecementos, e só un deles protexe o tráfico.

Percorra a lista de comprobación en orde, porque cada paso reduce o que está a probar realmente.

De onde vén realmente o bloqueo

Hai dúas familias de implementación. Ou a plataforma instala o bloqueo, porque coñece o túnel antes de que se execute ningunha aplicación, ou o cliente instala o bloqueo por si mesmo despois de arrancar. A primeira pode existir antes de iniciar sesión. A segunda non pode existir antes que o seu proceso, por temperán que estea programado ese proceso. Determine en que familia se apoia antes de probar nada.

En Android, a VPN sempre activa combinada co axuste de bloquear conexións sen VPN é política da plataforma, configurada nos axustes do sistema e non só dentro do cliente. Nos dispositivos xestionados poden deixala configurada por vostede. Un cliente que simplemente arranca ao iniciar o sistema non é o mesmo mecanismo.

Separe a xanela do servizo

Unha xanela pechada non é proba de que a aplicación da norma se detivese, e unha xanela aberta non é proba de que o túnel estea listo. Moitos clientes separan a interface, o daemon e a aplicación da bandexa. A bandexa é o que vostede ve; o daemon é o que sostén as regras.

Probe o compoñente, non a icona.

Probe o intervalo de arranque con seguridade

O intervalo que hai que probar comeza ao reiniciar ou iniciar sesión e remata cando o túnel se autentica. As aplicacións en segundo plano conéctanse durante ese período, e as comprobacións de actualizacións son os infractores habituais. Use actividade inofensiva e o procedemento documentado do provedor en lugar de bloquear o seu propio acceso. Despois repita tras unha reconexión normal, porque a ruta de reconexión e a de arranque en frío executan código distinto.

Unha proba realizada despois de que o túnel xa estea levantado non demostra nada sobre o arranque.

Lea o comportamento de reinicio se a persistencia é o requisito. Un axuste pode sobrevivir na configuración mentres a súa aplicación comeza máis tarde, e ambos os feitos importan: a política gardada e o momento en que se volve activa.

Lea a política por plataforma

Android expón o modo sempre activo e o bloqueo como conmutadores separados, e ambos deben estar activados para a protección previa ao arranque. Windows ten un concepto de túnel de dispositivo sempre activo configurado mediante política, que non é o mesmo que un cliente en modo usuario que arranca cedo. OpenVPN Connect documenta o seu propio comportamento de kill switch por plataforma, e o alcance documentado é o que vostede proba. Non leve un nome de axuste dun sistema a outro e supoña que o significado viaxou con el.

Un perfil que esixe un contrasinal interactivo ten dependencias de arranque distintas das dun túnel de máquina.

Que rexistrar

Anote que mecanismo está vixente, en que etapa se volve activo e que tráfico se intentou antes desa etapa. Rexistre a versión da plataforma, porque este comportamento cambia entre versións e entre configuracións xestionadas e persoais. Indique se o cliente ou o sistema posúe a política, xa que iso decide quen pode corrixir unha lagoa. Despois volva probar tras calquera actualización do cliente ou do sistema operativo.

Se a lagoa importa, a solución duradeira é a política da plataforma, non un atraso de arranque máis curto.

Esa é a resposta á pregunta orixinal, formulada como condición: un kill switch protexe o tráfico antes de que arranque a aplicación só cando o bloqueo o instala algo que existe antes ca a aplicación.