Always On VPN versus VPN On Demand no iPhone: o que implementar

Dois iPhones podem ambos dizer VPN e comportar-se de forma totalmente diferente. O On Demand abre um túnel quando uma regra coincide, e o usuário ainda pode desativá-lo nos Ajustes. O Always On gerenciado mantém a cobertura imposta num dispositivo supervisionado, inclusive nos momentos em que o túnel não consegue subir. Escolha perguntando o que precisa ser verdade quando o usuário não faz nada, e depois teste as transições em vez do estado estável. Os passos abaixo seguem a ordem em que uma implantação realmente falha.

Passo 1: estabeleça o que o dispositivo consegue impor

O Always On é um recurso para dispositivos supervisionados. Se o parque não é supervisionado, a conversa termina antes de começar, e nenhuma chave de payload transforma um telefone não supervisionado num imposto. Confirme a supervisão pelo lado da gestão e pelo dispositivo, e depois confirme quem assinou o perfil.

No telefone: Ajustes, depois Geral, depois VPN e gestão de dispositivos. A entrada do perfil indica o proprietário, e um perfil pessoal instalado manualmente parece diferente de um entregue por um serviço de gestão. Não deduza a imposição do nome do perfil nem de um rótulo de marketing do fornecedor; o rótulo não é a política da plataforma.

Anote três fatos antes de tocar na configuração: supervisionado ou não, perfil gerenciado ou pessoal, e qual cliente carrega o túnel. Cada passo seguinte depende desses três, e transferir comportamento de um telefone pessoal para um perfil gerenciado é como uma implantação é aprovada contra uma base errada.

Passo 2: leia as regras on-demand, não o nome do recurso

O On Demand é uma lista de regras avaliadas em ordem. Cada regra nomeia uma ação e as condições que a selecionam, e as condições são a parte interessante: tipo de interface, SSID de Wi-Fi, sufixo de domínio DNS ou um URL de sondagem. Um conjunto de regras que nunca coincide é um recurso que nunca conecta.

<key>OnDemandRules</key>
<array>
  <dict>
    <key>Action</key><string>EvaluateConnection</string>
    <key>InterfaceTypeMatch</key><string>WiFi</string>
    <key>SSIDMatch</key><array><string>Office-WiFi</string></array>
  </dict>
</array>

Leia todo o array e faça duas perguntas por regra: esta condição pode algum dia ser verdadeira neste parque, e o que acontece quando nenhuma regra coincide? Redes corporativas renomeiam pontos de acesso, fundem SSIDs e mudam sufixos DNS, e cada uma dessas edições desliga silenciosamente uma regra da realidade.

A condição de sufixo DNS é a que mais falha em campo, porque o sufixo que um telefone relata numa rede de convidados não é o que o resolvedor corporativo atende. Verifique o nome que o dispositivo realmente resolve antes de confiar na regra.

Passo 3: teste as transições, não a conexão estática

Um túnel que está no ar enquanto você olha prova muito pouco. Execute cada transição de propósito e registe o que o dispositivo faz, usando o mesmo recurso privado todas as vezes para que os resultados sejam comparáveis:

• Entre numa rede onde uma regra deveria coincidir, depois peça o recurso privado e confirme que carrega.
• Passe para a rede móvel com o app em segundo plano, traga-o para a frente e repita o pedido.
• Conecte-se a um Wi-Fi com portal cativo e veja se o portal é alcançável ou se a imposição o bloqueia antes de poder autenticar.
• Desative o túnel manualmente num dispositivo supervisionado e verifique se ele volta sozinho, e com que rapidez.

Execute a mesma lista num dispositivo não supervisionado se tiver um. A diferença entre os dois resultados é o comportamento real da implantação, e é a parte que uma captura de ecrã de um túnel conectado nunca mostra.

Passo 4: conheça as duas formas de falha

A cobertura imposta falha bloqueando. Quando o túnel não se estabelece, o dispositivo perde o acesso normal à internet junto com os recursos privados, e o usuário vive um telefone online mas incapaz de navegar. Reconexão e bloqueio são observações separadas, por isso registe as duas em vez de tratar a falta de internet como um único sintoma.

O On Demand falha por não disparar. A regra não coincide, nenhum túnel aparece, e o recurso privado simplesmente expira. É fácil diagnosticar mal como problema do servidor, porque o cliente comporta-se exatamente como configurado.

Um portal cativo fica entre os dois: precisa de conectividade antes de o túnel existir, por isso uma política que bloqueia tudo até o túnel subir precisa de um caminho documentado através do portal. Decida isso no desenho, não no balcão de ajuda.

Passo 5: verifique e depois ensaie o retrocesso

A verificação pertence ao caminho real com tráfego inofensivo: peça um recurso privado que não deve ser público, confirme que endereço o dispositivo apresenta para fora, e repita após um reinício para ter visto a sequência de arranque e não apenas o estado quente.

Depois ensaie a remoção num dispositivo de teste antes de precisar dela em produção. Remover o perfil devolve o dispositivo ao estado anterior, e saber quanto demora e o que o usuário vê faz parte do runbook. O guia de segurança VPN da Apple é a referência do que a plataforma documenta sobre estas políticas, e vale a pena lê-lo antes de escrever uma configuração que afirme mais do que a plataforma.

Mantenha os três fatos do primeiro passo ao lado do conjunto de regras e dos resultados dos testes. Quando a próxima pessoa perguntar por que um telefone conecta numa rede e não noutra, essas notas respondem num minuto em vez de uma reconstrução.