O seu script inicia a VPN; não a aprovisiona

Escreve um script que executa scutil --nc start com o nome da ligação, funciona no seu Mac e falha em todas as máquinas acabadas de instalar no escritório. O script não está avariado. Pede-se-lhe algo que nunca conseguiu fazer: iniciar uma ligação existente não é a mesma operação que criar uma nova.

O aprovisionamento e o controlo de sessão são dois trabalhos com dois responsáveis, e um fluxo de trabalho que assuma o contrário passará todos os testes na máquina onde foi escrito.

Com o que fala realmente o comando de início

Um comando de controlo de sessão dirige-se a uma configuração que já existe e já está aprovada. Pede ao sistema que levante essa ligação com nome, usando as definições do servidor, as referências de identidade e a política guardadas anteriormente. Se essas nunca foram instaladas, não há nada para iniciar.

É por isso que a falha aparece em hardware novo e não no portátil do administrador. O portátil foi aprovisionado há meses por uma pessoa que entretanto se esqueceu. Pense no comando de início como uma campainha que alguém cabou no trimestre passado. Carregar nela não é o mesmo que instalar a cablagem.

Três responsáveis de uma configuração de VPN

Um perfil gerido pela organização vem da gestão de dispositivos. O perfil transporta os endereços do servidor, a disposição da autenticação e a política exigida pela organização, e o administrador de VPN é a pessoa que as fornece. Um script não deve reconstruir essas definições a partir de um nome apresentado que encontrou numa lista.

Uma configuração de VPN pessoal nativa é criada através da Network Extension API da Apple, que cobre os protocolos IPsec e IKEv2 integrados. É uma interface de aplicação com um passo de gravação e uma aprovação do utilizador, não um comando de shell que crie silenciosamente qualquer tipo de túnel que um fornecedor entregue.

Um cliente de terceiros é um terceiro caso com o seu próprio formato de importação, a sua própria ferramenta de gestão e muitas vezes o seu próprio auxiliar privilegiado. A sua sessão pertence ao processo desse fornecedor. Encontrar um serviço de sistema com um nome semelhante não é prova de que um comando de sistema controla o túnel, e assumi-lo produz scripts que parecem funcionar até o fornecedor atualizar o cliente.

O aprovisionamento nativo tem uma gravação e uma aprovação

O modelo da Apple é carregar, alterar, gravar. Uma aplicação carrega as preferências existentes antes da sua primeira gravação após o arranque, altera a configuração e depois grava-a. A gravação comunica um erro quando não consegue persistir, e ignorar esse resultado transforma uma falha de aprovisionamento numa falha de ligação três passos depois.

A primeira gravação também exige que o utilizador aprove a aplicação. É uma fronteira de segurança deliberada, e significa que a primeira execução num Mac novo é interativa mesmo quando cada ligação e desligação posterior pode ser automatizada. Planeie a primeira execução como uma tarefa humana com uma pessoa presente. Automatize a segunda execução em diante, e diga-o no runbook para que ninguém prometa o impossível. Um plano de implementação que promete uma primeira execução totalmente sem supervisão promete algo que a plataforma não oferece.

A Apple recomenda também validar a compatibilidade do servidor com um perfil de configuração antes de confiar na API. Fazer essa verificação primeiro separa «o servidor não aceitará este cliente» de «o cliente nunca guardou as definições», que são tíquetes diferentes para equipas diferentes.

O que um comando de início repetível pode assumir

Após o aprovisionamento, um script pode com segurança apontar para a ligação existente através da interface do seu proprietário. Dê-lhe a identidade estável da ligação mais a ação que pretende, e nada mais. Não deve ler um caminho de preferências adivinhado, nem assumir que o nome apresentado no menu é único em todo o sistema.

Para ligações nativas, um pedido de sessão com nome como scutil --nc start é uma operação de controlo. Não instala definições do servidor, não importa credenciais e não realiza a autorização da primeira gravação. Trate-o como o último passo de uma cadeia, nunca como a cadeia inteira.

Mantenha os segredos fora dos argumentos da linha de comandos e fora da saída de diagnóstico comum. Qualquer que seja o mecanismo de identidade escolhido pela implementação, é nele que o comando de início se deve apoiar, e uma palavra-passe colada no histórico da shell é uma constatação em qualquer revisão.

Duas verificações de aceitação

A primeira verificação é o aprovisionamento: pegue num Mac acabado de instalar e prove que a configuração está presente, pertence ao gestor correto e está plenamente aprovada. Faça isto antes de testar a conetividade, porque um teste de ligação numa máquina não aprovisionada não prova nada sobre o script.

A segunda verificação é a sessão: ligue, alcance o recurso autorizado e desligue de forma limpa. Agora cada falha tem um responsável, e esse é o benefício prático de separar os dois trabalhos. Um perfil em falta é um problema de entrega, um erro de gravação é um problema de aprovação, um início de sessão rejeitado é um problema de autenticação, e um tempo limite após um início bem-sucedido é a camada de sessão. Nenhum deles é «o script está avariado».