Iniciar uma VPN de Mac guardada a partir do terminal com scutil --nc

Tem um serviço VPN guardado em Definições do Sistema e quer que o terminal o inicie. No macOS, o caminho suportado é scutil --nc, mas apenas para serviços pertencentes ao próprio gestor de ligações de rede do sistema. A barra de menus não é a API: os clientes de terceiros costumam ter a sua própria automatização, e um perfil enviado por um serviço de gestão pode recusar um início local. Esta é a lista de verificação que sigo: encontre o serviço exato, leia o estado, inicie-o, espere que o estado mude e depois prove que o tráfego usa realmente o túnel. Pare no primeiro passo que não bate certo, porque cada comando seguinte assume que o anterior foi bem-sucedido.

Encontre o serviço antes de tentar iniciá-lo

Comece pelo inventário em vez do nome de perfil de que se lembra:

scutil --nc help
scutil --nc list

Cada linha associa um estado a um identificador de serviço, um tipo e um nome de apresentação. O identificador é o valor sobre o qual se escrevem scripts, porque os nomes de apresentação se repetem e podem ser editados. O manual scutil da Apple documenta o modo de ligação de rede, enquanto o --nc help instalado é a lista autoritativa de subcomandos nesse Mac; não assuma que uma opção de um guia antigo ainda existe na sua versão de macOS.

Uma lista vazia é um resultado, não um erro. Um serviço criado por um cliente de fornecedor ou por um perfil de gestão pode estar ativo enquanto é invisível aqui, ou visível com um tipo que o controlador nativo não consegue conduzir. Nesse caso, use a ferramenta do fornecedor ou a documentação do perfil. Criar um perfil nativo paralelo só para ter algo para iniciar é um mau negócio.

Leia o estado atual e confirme o seletor

Pergunte ao serviço pelo estado antes de o iniciar, para saber o que um início bem-sucedido deve mudar:

scutil --nc status "Office VPN"

Se dois serviços partilham um nome de apresentação, o nome é ambíguo. Passe o identificador em vez disso; o comando aceita qualquer um dos dois, mas só o identificador garante selecionar um único serviço. Verifique que a palavra de estado é uma que reconhece — normalmente Connected, Disconnected, Connecting ou Disconnecting — antes de a analisar num script. Verifique também se o perfil é gerido, porque uma configuração bloqueada pode aceitar o comando e mesmo assim ignorá-lo ou pedir confirmação.

Esta chamada de estado é barata, por isso use-a como guarda na automatização: inicie só quando o estado é Disconnected, e não trate Connecting como uma falha. Se o serviço já está Connected, salte o início em vez de interromper um túnel a funcionar.

Inicie a ligação e espere que o estado assente

O pedido de início é assíncrono. O comando regressa quando o pedido é aceite, não quando a autenticação termina ou as rotas são instaladas. Execute-o e depois inquiria o estado com uma espera limitada e saia se o serviço voltar a Disconnected:

scutil --nc start "Office VPN"
n=0
while [ "$n" -lt 30 ]; do
  state=$(scutil --nc status "Office VPN" | head -n 1)
  [ "$state" = "Connected" ] && break
  [ "$state" = "Disconnected" ] && { echo "start failed"; exit 1; }
  sleep 2
  n=$((n + 1))
done

Um estado Connecting que nunca se resolve normalmente aponta para credenciais, MFA ou o servidor, não para scutil. O comando não pode fornecer um início de sessão interativo, por isso um perfil que espera um token ou uma chave de hardware fica em Connecting e acaba por recuar. Leia a palavra de estado antes de acrescentar novas tentativas; um ciclo contra um pedido de autenticação não pode ter sucesso.

Não trate o estado de saída da shell como prontidão. O sinal útil é a cadeia de estado, seguida da prova de que o túnel transporta tráfego. Um comando de início que regressa em silêncio ainda pode deixá-lo com uma ligação que nunca se autentica.

Prove que o túnel transporta tráfego, não apenas que diz Connected

Connected descreve a ligação, não a decisão de encaminhamento. Os serviços nativos PPP e IKEv2 criam uma interface ppp ou utun e instalam rotas, enquanto um túnel dividido deixa deliberadamente a rota predefinida intacta. Inspecione as interfaces e ambas as famílias de endereços:

ifconfig -l
netstat -rn -f inet
netstat -rn -f inet6
scutil --dns

Encontre a interface que o serviço criou em vez de adivinhar um número, e depois pergunte à tabela de rotas que interface um destino concreto usa: route -n get 10.0.0.10, substituindo-o por um anfitrião interno. Se indicar a interface física, o túnel está ativo mas não transporta esse fluxo. Verifique as rotas do túnel dividido, a ordem dos resolutores e qualquer regra local de firewall que permita a interface do túnel mas não o processo.

A resolução de nomes é o falso negativo habitual. Os nomes internos podem ser resolvidos pelo resolutor errado enquanto o túnel está perfeitamente saudável, o que parece uma falha de VPN e não é. scutil --dns mostra a ordem que o macOS vai usar; após uma mudança de resolutor, limpe a cache com dscacheutil -flushcache e sudo killall -HUP mDNSResponder.

Mantenha as credenciais e os privilégios fora da linha de comandos

Nunca ponha uma palavra-passe, uma chave pré-partilhada ou um token nos argumentos. Os argumentos são visíveis nas listas de processos e ficam no histórico da shell, e uma transcrição de suporte copiada pode divulgá-los. A própria gestão de credenciais do perfil — quer seja um item do Keychain, um pedido do sistema ou o fluxo de autenticação do cliente — é o lugar para os segredos.

Executar o comando com sudo não torna um início de sessão interativo não supervisionado. Muda o utilizador efetivo, não a disponibilidade de um pedido GUI, de um token de hardware ou do Keychain de início de sessão. Um LaunchAgent pode iniciar um serviço depois de o utilizador iniciar sessão e o Keychain estar desbloqueado; um LaunchDaemon normalmente não alcança essas peças da sessão do utilizador. Se uma organização gere o serviço, as suas regras de ciclo de vida prevalecem sobre qualquer script local.

Pare o serviço e verifique que continuou parado

Pare com o mesmo seletor que usou para iniciar e depois volte a ler o estado em vez de assumir que o túnel desapareceu:

scutil --nc stop "Office VPN"
scutil --nc status "Office VPN"

Uma paragem que regressa a Disconnected ainda deixa uma coisa a verificar: se o perfil está configurado para ligar a pedido, o que o pode trazer de volta sem o seu script. Se outro cliente possui rotas no mesmo Mac, essas rotas podem sobreviver a uma paragem nativa. Volte a verificar a rota antes de concluir que a máquina está fora da VPN.

Para um envoltório que executa à mão, mantenha a ordem fixa: lista, estado, início, inquérito, teste de rota, paragem, verificação. Não analise o nome amigável a partir de uma saída de formato livre quando o identificador está disponível, e não trate a saída do comando de início como prontidão. O gestor de ligações relata o estado; a sua prova é o estado mais uma rota que aponta para o túnel.