La VPN del Mac conecta una vez y luego expira: limpie el demonio IKE

La primera conexión tras un reinicio funciona. Cada intento posterior se cuelga en la fase de conexión y acaba expirando, y el único remedio fiable es otro reinicio. Ese patrón no es un problema de perfil ni un problema de credenciales. Algo en segundo plano sigue reteniendo el estado del intento anterior, y el siguiente intento choca con ello.

En macOS, ese algo suele ser el demonio IKE.

El patrón: conecta una vez y luego expira

Una conexión que funciona exactamente una vez por arranque apunta a un estado que sobrevive a una desconexión pero no a un reinicio. Los perfiles sobreviven a ambas cosas, así que el perfil no es la variable. Las credenciales también sobreviven a ambas, salvo que el servidor bloquee la cuenta. Lo que cambia en el reinicio es el conjunto de demonios en ejecución y los sockets que retienen.

Eso estrecha la investigación antes de abrir un solo registro. La pregunta pasa a ser qué proceso posee el puerto IKE y qué cree que está haciendo.

Dos demonios, un puerto

El sistema ejecuta racoon cuando una conexión habla IKE versión 1. Las versiones actuales también incorporan iked para IKEv2 y la pila IPsec más reciente. Ambos pueden ocupar UDP 500 y UDP 4500, y ambos pueden mantener una asociación de seguridad entreabierta después de que un intento de conexión se cancele en el aviso de contraseña o se interrumpa por un cambio de red.

Cuando eso ocurre, el siguiente intento no empieza limpio. Intenta negociar mientras la asociación antigua aún ocupa el estado del par, y el intercambio se atasca en lugar de fallar con un error claro. El usuario ve un indicador giratorio y luego un tiempo de espera agotado.

Encuentre al propietario antes de matar nada, porque la respuesta determina qué servicio reinicia y qué registro lee después.

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

Lea la salida como dos hechos: qué proceso retiene el puerto y si hay más de uno presente. Dos demonios IKE compitiendo por el mismo socket explican mucho comportamiento intermitente que parece un servidor inestable.

Reinicie la tarea, no el proceso

En sistemas antiguos basta con matar el proceso y dejar que la siguiente conexión lo arranque de nuevo. En las versiones actuales el demonio lo gestiona launchd, y enviar una señal solo al proceso puede dejar la tarea en un estado en el que ni se ejecuta ni está programada para arrancar. Detenga y arranque la tarea.

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

Si launchd no tiene registro de la tarea, matar el proceso por su nombre sigue forzando una negociación nueva en el siguiente intento. La prueba es la misma en ambos casos: ningún proceso debería retener el puerto cuando vuelva a conectar. Confírmelo con el mismo comando lsof en lugar de suponer que el reinicio funcionó.

Luego conecte una vez y lea el registro del cliente desde el principio. Una negociación que avanza más allá de la fase 1 y luego informa de un fallo de transmisión está repitiendo el problema local del socket; una negociación rechazada por el par es un billete completamente distinto.

Cuando es el servidor el que rechaza

No toda segunda conexión falla localmente. Un servidor puede rechazar un inicio de sesión nuevo durante una ventana fija tras una desconexión, y el tiempo de espera del cliente parece idéntico al de un demonio atascado. El discriminante es barato: si reiniciar el demonio no ayuda pero otra cuenta conecta de inmediato, la ventana es del lado del servidor y el Mac nunca fue el problema.

La política de túnel dividido produce la misma forma desde la otra dirección. Un servidor que exige todo el tráfico en el túnel descartará un cliente configurado para túnel dividido durante la negociación, y el cliente informa de un tiempo de espera agotado en lugar de un rechazo de política. Cambiar el perfil para enviarlo todo por el túnel puede hacer que conecte, pero es una decisión de política que se toma con el dueño de la red, no una reparación que se aplica en silencio.

Lea el registro del par antes de cambiar el cliente otra vez. Un rechazo, una discrepancia de política y un descarte silencioso son tres causas distintas que en la pantalla del Mac parecen todas “conectando”.

Clientes antiguos y el núcleo de 64 bits

El cliente Cisco IPSec heredado carga una extensión de núcleo creada para sistemas de 32 bits y PowerPC. En un Mac arrancado con el núcleo de 64 bits, esa extensión no puede cargarse, y el cliente falla pronto con el error 51 porque no llega al subsistema de VPN en absoluto. Ninguna cantidad de reinicios del demonio arregla una extensión de núcleo con la arquitectura equivocada.

Recargar la extensión puede funcionar un tiempo y luego volver a fallar en el siguiente arranque. Las respuestas duraderas son ejecutar el núcleo antiguo donde aún se admite, o pasarse al cliente integrado que viene con el sistema. Compruebe la arquitectura antes de pasar una noche con un cliente de terceros que no puede cargarse.

• Reproduzca una vez y luego compruebe qué demonio posee UDP 500 antes de tocar el perfil.
• Lea el primer fallo después de la fase 1: un error de transmisión apunta al socket local.
• Reinicie la tarea de launchd, no solo el proceso, y confirme que el puerto está libre.
• Pruebe una segunda cuenta para separar una ventana de reautenticación del lado del servidor de un fallo del cliente.
• Anote la arquitectura del núcleo antes de culpar al cliente.

Una VPN que funciona exactamente una vez es un problema de estado hasta que se demuestre lo contrario. Limpiar el demonio es más rápido que reiniciar, y conserva las pruebas del registro que un reinicio habría tirado.