VPN no iPad sem pedidos de senha: certificados ou login salvo
Uma senha salva e um certificado do dispositivo removem o pedido de maneiras diferentes. Compare os dois e decida separadamente o que abre o túnel.
«Pare de me pedir uma senha» na verdade agrupa três requisitos em uma única reclamação, e uma implantação em iPad responde a eles em lugares diferentes. O pedido vem da autenticação, o momento vem da ativação e a cobertura vem da aplicação das regras. Escolha a credencial que remove o pedido e depois decida separadamente o que determina quando o túnel abre. Misturar as duas decisões é o que deixa uma senha salva em um perfil que ainda espera um toque.
| Saved or shared secret | Device certificate | |
|---|---|---|
| What the user sees | no prompt while the credential stays valid | no prompt, no password to rotate |
| What the admin manages | the secret in the profile and its distribution | enrollment, expiry and revocation per device |
| Typical failure | gateway demands a second factor | expired or revoked certificate |
Dois problemas em uma só reclamação
Uma configuração IKEv2 nativa no iPad pode referenciar uma senha ou um certificado, e a chave AuthenticationMethod decide qual deles se aplica, enquanto PayloadCertificateUUID nomeia a credencial que fornece a identidade. Qual deles o gateway vai aceitar é uma questão de política do servidor, não uma preferência do cliente. Por isso, a primeira coisa a estabelecer é o que o serviço VPN permite, porque um iPad não consegue negociar até um método que o outro lado recusa.
Só depois faz sentido falar de quando o túnel é ativado, que é um conjunto completamente diferente de chaves do perfil.
Opção um: uma credencial que o iPad pode reutilizar
Uma senha de conta armazenada ou um segredo compartilhado satisfazem um gateway que autentica o usuário ou o grupo e removem o pedido enquanto o segredo continuar válido. A fraqueza está no ciclo de vida: o segredo fica no perfil, vários dispositivos podem compartilhá-lo e trocá-lo exige mexer em todos os perfis que o contêm. Se o serviço também exigir um fator de uso único ou uma aprovação interativa, nenhuma configuração local transforma essa política em um login sem supervisão.
Uma senha salva por um aplicativo também não fica automaticamente disponível para outra implementação de VPN, e é por isso que a mesma conta pode deixar de pedir em um cliente e pedir sempre em outro.
Opção dois: um certificado do dispositivo com a própria chave
Um certificado remove o pedido de forma mais forte, porque o iPad prova a posse de uma chave privada em vez de repetir um segredo. Isso exige que o certificado final e sua chave cheguem pelo caminho de inscrição aprovado, e que o gateway aceite a autenticação por certificado nessa conexão. Importar apenas um certificado de AC dá ao dispositivo material de confiança e nada mais, o que é uma falha comum e silenciosa.
A contrapartida é trabalho de ciclo de vida. Cada iPad recebe a própria identidade, para que um dispositivo perdido possa ser revogado sem reemitir todo o parque, e as datas de validade passam a ser eventos operacionais reais. Um certificado que expira em silêncio parece exatamente uma queda de VPN na manhã em que acontece.
Escolha pelo que o gateway aceita, não pela preferência
Faça duas perguntas ao administrador de VPN: quais métodos de autenticação o serviço aceita para este tipo de cliente e se algum deles exige entrada interativa. Se a resposta for apenas certificado, planeje a inscrição e a renovação. Se for senha mais um segundo fator, aceite que o pedido é política e pare de tratá-lo como falha do dispositivo. Se ambos forem aceitos, o certificado ganha no ciclo de vida para um parque supervisionado e a senha ganha no esforço de instalação para poucos dispositivos.
Registre o método escolhido no registro de implantação, ao lado do identificador do perfil, porque caso contrário a próxima pessoa a mexer no perfil escolherá o outro.
Depois, separe ativação de autenticação
O VPN On Demand abre o túnel quando uma condição configurada corresponde, seja um domínio DNS, um tipo de interface ou uma rede associada, e a Apple o documenta como algo que não exige interação do usuário. Encaixa bem em recursos privados que só devem ficar acessíveis quando algo os pede. Não é o mesmo que o Always On gerenciado, que mantém a cobertura aplicada e traz seus próprios requisitos de supervisão e de perfil.
Uma credencial funcionando não serve para nenhum dos dois casos. Muitos iPads têm um certificado perfeitamente válido e continuam esperando um toque manual porque nenhuma regra sob demanda jamais disparou.
Entregue o requisito em um formato sobre o qual um administrador possa agir: este iPad deve alcançar estes recursos sem entrada recorrente do usuário, com este tipo de credencial e segundo estas regras de ativação e de falha. Se o serviço atual não cumprir essas condições, os pedidos repetidos são a política funcionando como foi projetada.