O kill switch bloqueia o tráfego antes de a aplicação VPN arrancar?

Um kill switch pode cobrir ou não a janela anterior ao arranque da sua aplicação, e a diferença é decidida pela política do sistema operativo e não pela página de marketing do cliente. Uma caixa de início automático prova que algo está agendado para arrancar. Não prova que existam regras de bloqueio no momento em que a rede sobe. São dois acontecimentos, e só um deles protege o tráfego.

Percorra a lista de verificação por ordem, porque cada passo estreita o que está realmente a testar.

De onde vem realmente o bloqueio

Existem duas famílias de implementação. Ou a plataforma instala o bloqueio, porque conhece o túnel antes de qualquer aplicação ser executada, ou o cliente instala o bloqueio por si mesmo depois de arrancar. A primeira pode existir antes do início de sessão. A segunda não pode existir antes do seu processo, por mais cedo que esse processo esteja agendado. Identifique de que família depende antes de testar seja o que for.

No Android, a VPN sempre ativa combinada com a definição de bloquear ligações sem VPN é política da plataforma, configurada nas definições do sistema e não apenas dentro do cliente. Em dispositivos geridos pode estar configurada por si. Um cliente que apenas arranca no boot não é o mesmo mecanismo.

Separe a janela do serviço

Uma janela fechada não é prova de que a aplicação da regra parou, e uma janela aberta não é prova de que o túnel está pronto. Muitos clientes separam a interface, o daemon e a aplicação da bandeja. A bandeja é o que vê; o daemon é o que detém as regras.

Teste o componente, não o ícone.

Teste o intervalo de arranque em segurança

O intervalo a testar começa no reinício ou no início de sessão e termina quando o túnel se autentica. As aplicações em segundo plano ligam-se nesse período, e as verificações de atualizações são os infratores habituais. Use atividade inofensiva e o procedimento documentado do fornecedor em vez de bloquear o seu próprio acesso. Depois repita após uma reconexão normal, porque o caminho de reconexão e o caminho de arranque a frio executam código diferente.

Um teste realizado depois de o túnel já estar de pé não prova nada sobre o arranque.

Leia o comportamento de reinício se a persistência for o requisito. Uma definição pode sobreviver na configuração enquanto a sua aplicação começa mais tarde, e ambos os factos importam: a política guardada e o momento em que se torna ativa.

Leia a política por plataforma

O Android expõe o modo sempre ativo e o bloqueio como interruptores separados, e ambos têm de estar ativos para a proteção antes do arranque. O Windows tem um conceito de túnel de dispositivo sempre ativo configurado por política, que não é o mesmo que um cliente em modo de utilizador a arrancar cedo. O OpenVPN Connect documenta o seu próprio comportamento de kill switch por plataforma, e é o âmbito documentado que testa. Não transportar um nome de definição de um sistema para outro assumindo que o significado viajou com ele.

Um perfil que exige uma palavra-passe interativa tem dependências de arranque diferentes das de um túnel de máquina.

O que registar

Anote que mecanismo está em vigor, em que fase se torna ativo e que tráfego foi tentado antes dessa fase. Registe a versão da plataforma, porque este comportamento muda entre versões e entre configurações geridas e pessoais. Note se é o cliente ou o sistema que possui a política, pois isso decide quem pode corrigir uma lacuna. Depois teste novamente após qualquer atualização do cliente ou do sistema operativo.

Se a lacuna for importante, a correção duradoura é a política da plataforma, não um atraso de arranque mais curto.

Essa é a resposta à pergunta original, formulada como condição: um kill switch protege o tráfego antes de a aplicação arrancar apenas quando o bloqueio é instalado por algo que existe antes da aplicação.