Perfil VPN gerido do Mac não se elimina? Verifique estes cinco passos
Antes de eliminar um perfil VPN gerido no Mac, confirme quem é o proprietário, o que o payload impõe e porque a remoção está bloqueada, com cinco verificações ordenadas.
O seu Mac mantém um perfil VPN que se recusa a ser eliminado, ou é eliminado e volta depois de reiniciar. Isto é normalmente uma questão de gestão, não um cliente corrompido. As verificações abaixo vão da propriedade ao payload e às regras de reconexão, e cada uma pode pará-lo antes de passar uma tarde no painel errado. Faça-as por ordem; o passo em que a resposta muda é onde termina a sua parte.
Confirme que o perfil é gerido, não apenas guardado
Abra as Definições do Sistema e procure Perfis ou Gestão de Dispositivos. Consoante a versão do macOS, a lista fica em Privacidade e Segurança (Perfis) ou em Geral (Gestão de Dispositivos). Um perfil que mostra o nome de uma organização, uma descrição curta e nenhum botão menos foi instalado pela organização e não adicionado por si.
Duas verificações no terminal resolvem a propriedade rapidamente. A primeira comunica a inscrição, a segunda lista os perfis do dispositivo:
sudo profiles status -type enrollment
sudo profiles -PSe a inscrição disser sim e a lista de perfis estiver vazia, não conclua que nada está instalado. Nos Mac geridos, alguns payloads entregues por MDM permanecem ocultos da ferramenta profiles ao mesmo tempo que continuam ativos. O painel Gestão de Dispositivos é a vista autorizada do que a organização enviou, e uma lista vazia na linha de comandos num Mac inscrito é uma contradição que não deve resolver adivinhando.
Leia o payload, não o nome apresentado
Um perfil VPN é um contentor, e o nome visível diz pouco sobre o que está lá dentro. Um payload pode transportar o endereço do servidor IKEv2, o identificador remoto, o método de autenticação e um certificado com o seu próprio UUID. Um segundo payload no mesmo perfil pode fornecer o certificado de identidade de que o túnel precisa, e é por isso que um certificado que parece faltar no Keychain pode chegar na mesma através do mesmo perfil.
Despeje os payloads e leia as chaves que importam:
sudo profiles show -type configuration | grep -A3 -E "VPNType|ServerAddress|RemoteAddress|AuthenticationMethod|PayloadUUID"Registe os UUID dos payloads antes de alterar seja o que for. São os identificadores de que um administrador precisa para localizar o objeto exato, e também lhe dizem se o túnel e o certificado vêm da mesma origem ou de duas implementações diferentes.
Observe o que traz o túnel de volta
Se o túnel reiniciar sozinho, o perfil quase certamente contém uma regra a pedido. Uma regra que corresponda a qualquer interface e à ação Connect inicia o túnel quando o Wi-Fi se associa, quando o Mac sai do repouso ou quando uma sonda DNS falha. O cliente não expõe nenhum interruptor que anule o payload.
A lista de serviços e a configuração por serviço vêm do scutil:
scutil --nc list
scutil --nc show "Corporate VPN"Na saída de show, encontre OnDemandRules e leia o valor Action de cada entrada. Connect levanta o túnel, Disconnect derruba-o e Ignore deixa o estado atual como está. Uma primeira regra que corresponde a tudo e tem Connect é a razão habitual para um túnel não ficar em baixo depois de o desligar.
Se a ligação faltar em scutil --nc list, não está instalada como serviço VPN do sistema. Isso aponta para uma extensão de rede pertencente a uma aplicação cliente, onde o perfil talvez só entregue a configuração da aplicação e a aplicação decide quando ligar.
Decida se a remoção é consigo
Dois mecanismos bloqueiam a eliminação. O payload pode definir PayloadRemovalDisallowed, o que torna o perfil não removível na interface, e o Mac pode estar supervisionado de modo a que a remoção do perfil de gestão seja recusada de imediato. Nenhum deles é um erro, e eliminar certificados não relacionados ou o perfil de gestão para forçar a situação deixa-o com um problema muito maior do que aquele com que começou.
| What you see | Likely owner | Next action |
|---|---|---|
| Profile shows an organization name and no minus button | MDM enrollment | Ask the administrator to remove it or change its scope |
| Profile removable, personal IKEv2 settings | You | Remove it from VPN settings and re-add it if you still need it |
| Profile removed, returns after a reboot or check-in | MDM re-push | Request a scope change; deleting it again will not hold |
| Profile removed, tunnel still starts | On Demand rule or app login item | Remove the rule or the login item, then retry |
Para um Mac de trabalho, o caminho correto é o suporte ou a saída pelo administrador. Leve consigo o identificador do perfil. Um ticket que diga apenas «o perfil VPN» não basta para ninguém encontrar o objeto a que se refere.
Reúna provas antes de pedir ajuda
Anote cinco coisas: o identificador do perfil, os UUID dos payloads, a versão e a compilação do macOS segundo sw_vers, o subtipo de VPN e o texto exato da falha com uma marca temporal. Acrescente se o túnel é total ou dividido e se falha ao ligar ou no primeiro acesso a um recurso interno, porque essas duas falhas têm proprietários diferentes.
Para uma falha de extensão de rede, costuma bastar uma consulta de registo estreita:
log show --last 5m --predicate 'process == "nesessionmanager"'Capture as linhas em torno da tentativa em vez da janela inteira, e oculte nomes de servidor e sujeitos de certificado antes de publicar o resultado em qualquer sítio. O guia de implementação da Apple explica para que servem os payloads VPN geridos e as regras a pedido, e é um argumento melhor do que uma captura de ecrã: Visão geral de VPN.
Quando as cinco verificações estão feitas, exatamente uma de três coisas é verdadeira. O perfil não é seu para remover, o payload reconecta o túnel por conceção, ou o cliente tem uma configuração que o perfil nunca controlou. Leve os identificadores e a cronologia a quem detém a inscrição; isso é um ticket que alguém pode tratar. Voltar a premir eliminar não é.