El VPN del Mac es connecta un cop i després expira: netegeu el dimoni IKE

La primera connexió després d’una arrencada funciona. Cada intent posterior es penja a l’etapa de connexió i finalment expira, i l’únic remei fiable és una altra arrencada. Aquest patró no és un problema de perfil ni un problema de credencials. Alguna cosa en segon pla encara manté l’estat de l’intent anterior, i l’intent següent hi xoca.

A macOS, aquesta cosa sol ser el dimoni IKE.

El patró: connecta un cop i després expira

Una connexió que funciona exactament un cop per arrencada assenyala un estat que sobreviu a una desconnexió però no a una arrencada. Els perfils sobreviuen a les dues coses, així que el perfil no és la variable. Les credencials també sobreviuen a totes dues, tret que el servidor bloqui el compte. El que canvia a l’arrencada és el conjunt de dimonis en execució i els sockets que mantenen.

Això estreta la investigació abans que obriu ni un sol registre. La pregunta passa a ser quin procés posseeix el port IKE i què creu que està fent.

Dos dimonis, un port

El sistema executa racoon quan una connexió parla IKE versió 1. Les versions actuals també introdueixen iked per a IKEv2 i la pila IPsec més nova. Tots dos poden ocupar l’UDP 500 i l’UDP 4500, i tots dos poden mantenir una associació de seguretat mig oberta després que un intent de connexió es cancel·li al diàleg de contrasenya o s’interrompi per un canvi de xarxa.

Quan això passa, l’intent següent no comença net. Intenta negociar mentre l’associació antiga encara ocupa l’estat del parell, i l’intercanvi s’encalla en lloc de fallar amb un error clar. L’usuari veu un indicador giratori i després un temps d’espera esgotat.

Trobeu el propietari abans de matar res, perquè la resposta determina quin servei reinicieu i quin registre llegiu després.

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

Llegiu la sortida com dos fets: quin procés té el port i si n’hi ha més d’un. Dos dimonis IKE que competeixen pel mateix socket expliquen molts comportaments intermitents que semblen un servidor inestable.

Reinicleu la feina, no el procés

En sistemes antics, n’hi ha prou de matar el procés i deixar que la connexió següent el torni a engegar. En les versions actuals el dimoni el gestiona launchd, i enviar un senyal només al procés pot deixar la feina en un estat en què ni s’executa ni està programada per engegar. Atureu i engegueu la feina.

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

Si launchd no té cap registre de la feina, matar el procés pel nom encara força una negociació nova en el proper intent. La prova és la mateixa en tots dos casos: cap procés hauria de tenir el port quan torneu a connectar. Confirmeu-ho amb la mateixa ordre lsof en lloc de suposar que el reinici ha funcionat.

A continuació connecteu un cop i llegiu el registre del client des del principi. Una negociació que passa de la fase 1 i després informa d’un error de transmissió està repetint el problema local del socket; una negociació rebutjada pel parell és un bitllet completament diferent.

Quan és el servidor qui rebutja

No tota segona connexió falla localment. Un servidor pot rebutjar un inici de sessió nou durant una finestra fixa després d’una desconnexió, i el temps d’espera del client sembla idèntic al d’un dimoni encallat. El discriminant és barat: si reiniciar el dimoni no ajuda però un altre compte es connecta immediatament, la finestra és del costat del servidor i el Mac mai no va ser el problema.

La política de túnel dividit produeix la mateixa forma des de l’altra direcció. Un servidor que exigeix tot el trànsit al túnel descartarà un client configurat per a túnel dividit durant la negociació, i el client informa d’un temps d’espera esgotat en lloc d’un rebuig de política. Canviar el perfil per enviar-ho tot pel túnel pot fer que es connecti, però és una decisió de política que cal prendre amb l’amo de la xarxa, no una reparació per aplicar en silenci.

Llegiu el registre del parell abans de tornar a canviar el client. Un rebuig, una discrepància de política i un descart silenciós són tres causes diferents que a la pantalla del Mac semblen totes “connectant”.

Clients antics i el nucli de 64 bits

El client Cisco IPSec antic carrega una extensió de nucli creada per a sistemes de 32 bits i PowerPC. En un Mac arrencat amb el nucli de 64 bits, aquesta extensió no es pot carregar, i el client falla aviat amb l’error 51 perquè no arriba al subsistema del VPN. Cap quantitat de reinicis del dimoni arregla una extensió de nucli d’arquitectura equivocada.

Recarregar l’extensió pot funcionar un temps i després tornar a fallar a la propera arrencada. Les respostes duradores són executar el nucli antic on encara és compatible, o passar al client integrat que ve amb el sistema. Comproveu l’arquitectura abans de passar una vetllada amb un client de tercers que no es pot carregar.

• Reproduïu-ho un cop i després comproveu quin dimoni té l’UDP 500 abans de tocar el perfil.
• Llegiu la primera fallada després de la fase 1: un error de transmissió assenyala el socket local.
• Reinicleu la feina de launchd, no només el procés, i confirmeu que el port és lliure.
• Proveu un segon compte per separar una finestra de reautenticació del costat del servidor d’una fallada del client.
• Anoteu l’arquitectura del nucli abans de culpar el client.

Un VPN que funciona exactament un cop és un problema d’estat fins que es demostri el contrari. Netejar el dimoni és més ràpid que reiniciar, i conserva les proves del registre que un reinici hauria llençat.