A VPN do Mac liga uma vez e depois expira: limpe o daemon IKE

A primeira conexão depois de um reinício funciona. Cada tentativa seguinte fica presa na fase de conexão e acaba expirando, e o único remédio confiável é outro reinício. Esse padrão não é um problema de perfil nem um problema de credenciais. Algo em segundo plano ainda mantém o estado da tentativa anterior, e a próxima tentativa colide com isso.

No macOS, esse algo costuma ser o daemon IKE.

O padrão: conecta uma vez e depois expira

Uma conexão que funciona exatamente uma vez por arranque aponta para um estado que sobrevive a uma desconexão mas não a um reinício. Os perfis sobrevivem aos dois, então o perfil não é a variável. As credenciais também sobrevivem aos dois, a menos que o servidor bloqueie a conta. O que muda no reinício é o conjunto de daemons em execução e os sockets que eles mantêm.

Isso restringe a investigação antes de abrir um único registro. A pergunta passa a ser qual processo possui a porta IKE e o que ele pensa que está fazendo.

Dois daemons, uma porta

O sistema executa racoon quando uma conexão fala IKE versão 1. As versões atuais também trazem iked para IKEv2 e a pilha IPsec mais recente. Ambos podem ocupar UDP 500 e UDP 4500, e ambos podem manter uma associação de segurança entreaberta depois que uma tentativa de conexão é cancelada no pedido de palavra-passe ou interrompida por uma mudança de rede.

Quando isso acontece, a tentativa seguinte não começa limpa. Tenta negociar enquanto a associação antiga ainda ocupa o estado do par, e a troca trava em vez de falhar com um erro claro. O utilizador vê um indicador giratório e depois um tempo esgotado.

Encontre o proprietário antes de matar qualquer coisa, porque a resposta determina que serviço vai reiniciar e que registro vai ler a seguir.

sudo lsof -i :500 -i :4500
ps -ef | grep -E "racoon|iked"

Leia a saída como dois factos: que processo mantém a porta e se há mais de um presente. Dois daemons IKE a competir pelo mesmo socket explicam muito comportamento intermitente que parece um servidor instável.

Reinicie a tarefa e não o processo

Em sistemas antigos basta matar o processo e deixar a conexão seguinte iniciá-lo de novo. Nas versões atuais o daemon é gerido pelo launchd, e enviar um sinal apenas ao processo pode deixar a tarefa num estado em que nem está em execução nem está agendada para iniciar. Pare e inicie a tarefa.

sudo launchctl stop com.apple.racoon
sudo launchctl start com.apple.racoon

Se o launchd não tiver registro da tarefa, matar o processo pelo nome força na mesma uma nova negociação na tentativa seguinte. O teste é o mesmo nos dois casos: nenhum processo deve manter a porta quando tenta ligar-se de novo. Confirme isso com o mesmo comando lsof em vez de supor que o reinício funcionou.

Depois ligue-se uma vez e leia o registro do cliente desde o início. Uma negociação que passa da fase 1 e depois relata uma falha de transmissão está a repetir o problema local do socket; uma negociação rejeitada pelo par é um bilhete completamente diferente.

Quando é o servidor que recusa

Nem todas as segundas conexões falham localmente. Um servidor pode recusar um novo início de sessão durante uma janela fixa após uma desconexão, e o tempo esgotado do cliente parece idêntico ao de um daemon encravado. O discriminante é barato: se reiniciar o daemon não ajuda mas outra conta liga-se de imediato, a janela é do lado do servidor e o Mac nunca foi o problema.

A política de túnel dividido produz a mesma forma na direção oposta. Um servidor que exige todo o tráfego no túnel descarta um cliente configurado para túnel dividido durante a negociação, e o cliente relata um tempo esgotado em vez de uma rejeição de política. Alterar o perfil para enviar tudo pelo túnel pode fazê-lo ligar, mas é uma decisão de política a tomar com o dono da rede, não uma reparação a aplicar em silêncio.

Leia o registro do par antes de alterar o cliente outra vez. Uma rejeição, uma discrepância de política e um descarte silencioso são três causas diferentes que no ecrã do Mac parecem todas “a ligar”.

Clientes antigos e o núcleo de 64 bits

O antigo cliente Cisco IPSec carrega uma extensão de núcleo criada para sistemas de 32 bits e PowerPC. Num Mac arrancado com o núcleo de 64 bits, essa extensão não pode carregar, e o cliente falha cedo com o erro 51 porque não chega de todo ao subsistema VPN. Nenhuma quantidade de reinícios do daemon repara uma extensão de núcleo com a arquitetura errada.

Recarregar a extensão pode funcionar durante um tempo e depois falhar outra vez no arranque seguinte. As respostas duradouras são executar o núcleo antigo onde ainda é suportado, ou mudar para o cliente integrado que vem com o sistema. Verifique a arquitetura antes de passar uma noite com um cliente de terceiros que não consegue carregar.

• Reproduza uma vez e depois verifique que daemon possui o UDP 500 antes de tocar no perfil.
• Leia a primeira falha depois da fase 1: um erro de transmissão aponta para o socket local.
• Reinicie a tarefa do launchd, não apenas o processo, e confirme que a porta está livre.
• Experimente uma segunda conta para separar uma janela de reautenticação do lado do servidor de uma falha do cliente.
• Anote a arquitetura do núcleo antes de culpar o cliente.

Uma VPN que funciona exatamente uma vez é um problema de estado até prova em contrário. Limpar o daemon é mais rápido do que reiniciar, e preserva as provas do registro que um reinício teria deitado fora.