La VPN del Mac si connette una volta e poi va in timeout: ripulite il demone IKE

La prima connessione dopo un riavvio funziona. Ogni tentativo successivo si blocca nella fase di connessione e alla fine va in timeout, e l’unico rimedio affidabile è un altro riavvio. Questo schema non è un problema di profilo e non è un problema di credenziali. Qualcosa in background tiene ancora lo stato del tentativo precedente, e il tentativo successivo lo colpisce.

Su macOS, quel qualcosa è di solito il demone IKE.

Lo schema: una connessione, poi il timeout

Una connessione che funziona esattamente una volta per avvio indica uno stato che sopravvive a una disconnessione ma non a un riavvio. I profili sopravvivono a entrambi, quindi il profilo non è la variabile. Anche le credenziali sopravvivono a entrambi, a meno che il server non blocchi l’account. Ciò che cambia al riavvio è l’insieme dei demoni in esecuzione e i socket che tengono.

Questo restringe l’indagine prima ancora di aprire un singolo log. La domanda diventa quale processo possiede la porta IKE e cosa crede di stare facendo.

Due demoni, una porta

Il sistema esegue racoon quando una connessione parla IKE versione 1. Le versioni attuali introducono anche iked per IKEv2 e lo stack IPsec più recente. Entrambi possono occupare UDP 500 e UDP 4500, ed entrambi possono mantenere un’associazione di sicurezza semiaperta dopo che un tentativo di connessione viene annullato alla richiesta della password o interrotto da un cambio di rete.

Quando succede, il tentativo successivo non parte pulito. Prova a negoziare mentre la vecchia associazione occupa ancora lo stato del peer, e lo scambio si blocca invece di fallire con un errore chiaro. L’utente vede un indicatore rotante, poi un timeout.

Trovate il proprietario prima di uccidere qualsiasi cosa, perché la risposta determina quale servizio riavviate e quale log leggete dopo.

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

Leggete l’output come due fatti: quale processo tiene la porta e se ce n’è più di uno. Due demoni IKE che competono per lo stesso socket spiegano molto comportamento intermittente che sembra un server instabile.

Riavviate il job, non il processo

Sui sistemi più vecchi basta uccidere il processo e lasciare che la connessione successiva lo riavvii. Nelle versioni attuali il demone è gestito da launchd, e inviare un segnale solo al processo può lasciare il job in uno stato in cui non è in esecuzione né programmato per partire. Fermate e avviate invece il job.

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

Se launchd non ha un record del job, uccidere il processo per nome forza comunque una nuova negoziazione al tentativo successivo. Il test è lo stesso in entrambi i casi: nessun processo dovrebbe tenere la porta quando provate a connettervi di nuovo. Confermatelo con lo stesso comando lsof invece di dare per scontato che il riavvio abbia funzionato.

Poi connettetevi una volta e leggete il log del client dall’inizio. Una negoziazione che supera la fase 1 e poi segnala un errore di trasmissione sta ripetendo il problema locale del socket; una negoziazione rifiutata dal peer è un biglietto del tutto diverso.

Quando è il server a rifiutare

Non ogni seconda connessione fallisce localmente. Un server può rifiutare un nuovo accesso per una finestra fissa dopo una disconnessione, e il timeout del client sembra identico a quello di un demone bloccato. Il discriminante costa poco: se riavviare il demone non aiuta ma un altro account si connette subito, la finestra è lato server e il Mac non è mai stato il problema.

La politica di tunnel diviso produce la stessa forma dall’altra direzione. Un server che richiede tutto il traffico nel tunnel scarterà un client configurato per il tunnel diviso durante la negoziazione, e il client segnala un timeout invece di un rifiuto di politica. Cambiare il profilo per mandare tutto nel tunnel può farlo connettere, ma è una decisione di politica da prendere con il proprietario della rete, non una riparazione da applicare in silenzio.

Leggete il log del peer prima di cambiare di nuovo il client. Un rifiuto, una discrepanza di politica e uno scarto silenzioso sono tre cause diverse che sullo schermo del Mac sembrano tutte “connessione in corso”.

Client più vecchi e kernel a 64 bit

Il vecchio client Cisco IPSec carica un’estensione del kernel costruita per sistemi a 32 bit e PowerPC. Su un Mac avviato con il kernel a 64 bit, quell’estensione non può essere caricata, e il client fallisce presto con l’errore 51 perché non raggiunge affatto il sottosistema VPN. Nessuna quantità di riavvii del demone ripara un’estensione del kernel con l’architettura sbagliata.

Ricaricare l’estensione può funzionare per un po’ e poi fallire di nuovo all’avvio successivo. Le risposte durature sono eseguire il kernel più vecchio dove è ancora supportato, o passare al client integrato fornito con il sistema. Controllate l’architettura prima di dedicare una serata a un client di terze parti che non si carica.

• Riproducete una volta, poi controllate quale demone possiede UDP 500 prima di toccare il profilo.
• Leggete il primo fallimento dopo la fase 1: un errore di trasmissione punta al socket locale.
• Riavviate il job launchd, non solo il processo, e confermate che la porta è libera.
• Provate un secondo account per separare una finestra di riautenticazione lato server da un guasto del client.
• Annotate l’architettura del kernel prima di dare la colpa al client.

Una VPN che funziona esattamente una volta è un problema di stato finché non si dimostra il contrario. Ripulire il demone è più rapido di un riavvio e conserva le prove del log che un riavvio avrebbe buttato via.