O bloqueio de VPN do seu iPhone é uma política, não o protocolo

O ícone da VPN mostra conectado, o túnel cai por um instante durante uma troca de rede, e o tráfego que deveria ter sido bloqueado sai pela rede celular. Nada na interface anunciou uma lacuna. A função em que você confiava é uma política do cliente e da plataforma, e um nome de protocolo nas configurações não descreve o que acontece nesse segundo.

Descreva o bloqueio como um contrato sobre estados, não como uma propriedade do IKEv2 ou do On Demand.

O sintoma: o ícone diz conectado

Um ícone reflete a visão que o cliente tem do próprio estado, e essa visão pode ficar atrasada em relação à realidade pelo tempo de uma reconexão. Uma página em cache, uma reconexão rápida ou uma atualização de status escondem o intervalo. A pergunta que vale a pena não é se o ícone estava verde, mas o que o aparelho permitiu enquanto o túnel estava ausente. O mesmo atraso explica por que uma captura de tela do aplicativo é uma prova tão fraca: ela registra um estado, não uma transição.

Essa pergunta só tem resposta se a política a definir.

O que o protocolo mantém de fato

O IKEv2 mantém e renova uma relação IPsec autenticada, e os recursos de mobilidade ajudam a restabelecê-la após uma mudança de endereço. Isso é uma afirmação sobre o ciclo de vida do túnel. Não diz nada sobre a permissão do iPhone de enviar outro tráfego na lacuna, porque essa permissão pertence à plataforma e ao cliente, não à troca de chaves. Um aparelho que se reconecta em menos de um segundo teve mesmo assim uma janela, e é nessa janela que vive o comportamento interessante.

O On Demand é igualmente uma descrição do comportamento de ativação, não uma garantia universal de bloqueio.

O que a plataforma oferece a um desenvolvedor

O Network Extension da Apple expõe controles de escopo do tráfego, e seu guia de roteamento distingue o comportamento de incluir todas as redes das rotas incluídas comuns e lista as exceções do sistema. Existe também um modelo de implantação Always On supervisionado, separado da configuração de conexão automática de um aplicativo pessoal. Se um determinado aplicativo usa algo disso é uma propriedade do aplicativo, não do protocolo que ele fala.

O nome de um botão não é prova de qual API o aplicativo chama.

Leia a função como um contrato

Peça ao fornecedor que especifique cinco estados: ativação inicial, perda inesperada do túnel, desconexão deliberada, saída do aplicativo e reinicialização do aparelho. Coloque as exceções do sistema e qualquer acesso intencional à LAN ao lado dessa lista. Depois pergunte se a função é opcional, imposta pela gestão ou condicionada a um modo de cliente, porque uma pausa escolhida pelo usuário e um bloqueio imposto por uma organização são produtos diferentes. Escreva essas cinco respostas no registro de implantação, porque o próximo revisor fará exatamente essas perguntas.

Uma função que bloqueia numa perda inesperada mas não numa desconexão deliberada é um projeto coerente. Só não é o que a página de marketing descrevia.

Como testar as lacunas

Teste uma transição por vez com tráfego inofensivo, no aplicativo e na família de endereços que lhe interessa. Confirme o que foi permitido durante a lacuna, não o que o ícone mostrou depois. Registre a versão do cliente e a política ao lado do resultado, porque ambos mudam e nenhum é visível na tela de configurações do telefone. É a única forma de separar uma lacuna real de um ícone lento.

Se a resposta importa para a conformidade, peça-a por escrito em vez de deduzi-la de um rótulo de produto.