A VPN do Mac conéctase unha vez e despois expira: limpe o daemon IKE

A primeira conexión tras un reinicio funciona. Cada intento posterior queda colgado na fase de conexión e acaba expirando, e o único remedio fiable é outro reinicio. Ese patrón non é un problema de perfil nin un problema de credenciais. Algo en segundo plano segue mantendo o estado do intento anterior, e o seguinte intento choca con el.

En macOS, ese algo adoita ser o daemon IKE.

O patrón: conecta unha vez e despois expira

Unha conexión que funciona exactamente unha vez por arranque apunta a un estado que sobrevive a unha desconexión pero non a un reinicio. Os perfís sobreviven a ambas as dúas cousas, así que o perfil non é a variable. As credenciais tamén sobreviven a ambas, salvo que o servidor bloquee a conta. O que cambia no reinicio é o conxunto de daemons en execución e os sockets que manteñen.

Iso estreita a investigación antes de abrir un só rexistro. A pregunta pasa a ser que proceso posúe o porto IKE e que cre que está a facer.

Dous daemons, un porto

O sistema executa racoon cando unha conexión fala IKE versión 1. As versións actuais tamén incorporan iked para IKEv2 e a pila IPsec máis recente. Ambos poden ocupar UDP 500 e UDP 4500, e ambos poden manter unha asociación de seguridade entreaberta despois de que un intento de conexión se cancele no aviso de contrasinal ou se interrompa por un cambio de rede.

Cando iso ocorre, o seguinte intento non comeza limpo. Tenta negociar mentres a asociación antiga aínda ocupa o estado do par, e o intercambio atasca no canto de fallar cun erro claro. O usuario ve un indicador xiratorio e despois un tempo de espera esgotado.

Atope o propietario antes de matar nada, porque a resposta determina que servizo reinicia e que rexistro le despois.

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

Lea a saída como dous feitos: que proceso mantén o porto e se hai máis dun presente. Dous daemons IKE competindo polo mesmo socket explican moito comportamento intermitente que parece un servidor inestable.

Reinicie a tarefa, non o proceso

En sistemas antigos abonda con matar o proceso e deixar que a seguinte conexión o arrinque de novo. Nas versións actuais o daemon xestiónao launchd, e enviar un sinal só ao proceso pode deixar a tarefa nun estado no que nin se executa nin está programada para arrincar. Deteña e arrinque a tarefa.

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

Se launchd non ten rexistro da tarefa, matar o proceso polo nome segue forzando unha negociación nova no seguinte intento. A proba é a mesma en ambos os casos: ningún proceso debería manter o porto cando volva conectar. Confírmeo co mesmo comando lsof no canto de supoñer que o reinicio funcionou.

Despois conecte unha vez e lea o rexistro do cliente desde o principio. Unha negociación que avanza máis aló da fase 1 e logo informa dun fallo de transmisión está repetindo o problema local do socket; unha negociación rexeitada polo par é un billete completamente distinto.

Cando é o servidor o que rexeita

Non toda segunda conexión falla localmente. Un servidor pode rexeitar un inicio de sesión novo durante unha xanela fixa tras unha desconexión, e o tempo de espera do cliente parece idéntico ao dun daemon atascado. O discriminante é barato: se reiniciar o daemon non axuda pero outra conta conecta de inmediato, a xanela é do lado do servidor e o Mac nunca foi o problema.

A política de túnel dividido produce a mesma forma desde a outra dirección. Un servidor que esixe todo o tráfico no túnel descartará un cliente configurado para túnel dividido durante a negociación, e o cliente informa dun tempo de espera esgotado no canto dun rexeitamento de política. Cambiar o perfil para enviar todo polo túnel pode facer que conecte, pero é unha decisión de política que se toma co dono da rede, non unha reparación que se aplique en silencio.

Lea o rexistro do par antes de cambiar o cliente outra vez. Un rexeitamento, unha discrepancia de política e un descarte silencioso son tres causas distintas que na pantalla do Mac parecen todas “conectando”.

Clientes antigos e o núcleo de 64 bits

O cliente Cisco IPSec antigo carga unha extensión de núcleo creada para sistemas de 32 bits e PowerPC. Nun Mac arrincado co núcleo de 64 bits, esa extensión non se pode cargar, e o cliente falla cedo co erro 51 porque non chega ao subsistema de VPN en absoluto. Ningunha cantidade de reinicios do daemon arranxa unha extensión de núcleo coa arquitectura equivocada.

Recargar a extensión pode funcionar un tempo e logo volver fallar no seguinte arranque. As respostas duradeiras son executar o núcleo antigo onde aínda se admite, ou pasarse ao cliente integrado que vén co sistema. Comprobe a arquitectura antes de pasar unha noite cun cliente de terceiros que non se pode cargar.

• Reproduza unha vez e despois comprobe que daemon posúe UDP 500 antes de tocar o perfil.
• Lea o primeiro fallo despois da fase 1: un erro de transmisión apunta ao socket local.
• Reinicie a tarefa de launchd, non só o proceso, e confirme que o porto está libre.
• Probe unha segunda conta para separar unha xanela de reautenticación do lado do servidor dun fallo do cliente.
• Anote a arquitectura do núcleo antes de culpar o cliente.

Unha VPN que funciona exactamente unha vez é un problema de estado ata que se demostre o contrario. Limpar o daemon é máis rápido que reiniciar, e conserva as probas do rexistro que un reinicio tiraría.