Mac-VPN verbindt één keer en loopt dan vast in een time-out: ruim de IKE-daemon op

De eerste verbinding na een herstart werkt. Elke poging daarna blijft hangen in de verbindingsfase en loopt uiteindelijk in een time-out, en de enige betrouwbare oplossing is nog een herstart. Dat patroon is geen profielprobleem en het is geen inloggegevensprobleem. Iets op de achtergrond houdt nog de toestand van de vorige poging vast, en de volgende poging botst ermee.

Op macOS is dat iets meestal de IKE-daemon.

Het patroon: één keer verbinden, dan een time-out

Een verbinding die precies één keer per opstart werkt, wijst op toestand die een verbinding verbreken overleeft maar een herstart niet. Profielen overleven beide, dus het profiel is niet de variabele. Inloggegevens overleven ook beide, tenzij de server het account vergrendelt. Wat bij een herstart verandert, is de set draaiende daemons en de sockets die ze vasthouden.

Dat vernauwt het onderzoek voordat je één log opent. De vraag wordt welk proces de IKE-poort bezit en wat het denkt dat het doet.

Twee daemons, één poort

Het systeem draait racoon wanneer een verbinding IKE versie 1 spreekt. Huidige versies brengen ook iked voor IKEv2 en de nieuwere IPsec-stack. Beide kunnen UDP 500 en UDP 4500 binden, en beide kunnen een halfopen beveiligingsassociatie vasthouden nadat een verbindingspoging bij de wachtwoordprompt is geannuleerd of door een netwerkwijziging is onderbroken.

Wanneer dat gebeurt, begint de volgende poging niet schoon. Hij probeert te onderhandelen terwijl de oude associatie nog de toestand van de peer bezet, en de uitwisseling stokt in plaats van te mislukken met een duidelijke fout. De gebruiker ziet een spinner en dan een time-out.

Zoek de eigenaar voordat je iets doodt, want het antwoord bepaalt welke service je herstart en welk log je daarna leest.

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

Lees de uitvoer als twee feiten: welk proces de poort vasthoudt, en of er meer dan één aanwezig is. Twee IKE-daemons die om dezelfde socket strijden verklaren veel onregelmatig gedrag dat op een onstabiele server lijkt.

Herstart de taak in plaats van het proces

Op oudere systemen is het genoeg het proces te doden en de volgende verbinding het opnieuw te laten starten. Op huidige versies wordt de daemon door launchd beheerd, en alleen het proces een signaal geven kan de taak achterlaten in een toestand waarin hij niet draait en niet gepland is om te starten. Stop en start in plaats daarvan de taak.

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

Als launchd geen registratie van de taak heeft, dwingt het doden van het proces op naam nog steeds een nieuwe onderhandeling af bij de volgende poging. De test is in beide gevallen hetzelfde: geen enkel proces zou de poort moeten vasthouden wanneer je opnieuw probeert te verbinden. Bevestig dat met dezelfde opdracht lsof in plaats van aan te nemen dat de herstart werkte.

Verbind dan één keer en lees het clientlog vanaf het begin. Een onderhandeling die voorbij fase 1 komt en dan een verzendfout meldt, herhaalt het lokale socketprobleem; een onderhandeling die de peer weigert is een heel ander ticket.

Wanneer de server degene is die weigert

Niet elke tweede verbinding mislukt lokaal. Een server kan een nieuwe login een vaste periode na een verbreking weigeren, en de time-out van de client ziet er identiek uit als een vastgelopen daemon. Het onderscheid is goedkoop: als het herstarten van de daemon niet helpt maar een ander account meteen verbindt, zit het venster aan de serverkant en was de Mac nooit het probleem.

Beleid voor een gesplitste tunnel levert dezelfde vorm uit de andere richting. Een server die al het verkeer in de tunnel eist, gooit een client die voor een gesplitste tunnel is geconfigureerd tijdens de onderhandeling weg, en de client meldt een time-out in plaats van een beleidsweigering. Het profiel aanpassen om alles door de tunnel te sturen kan hem laten verbinden, maar dat is een beleidsbeslissing die je met de netwerkeigenaar neemt, geen reparatie die je stilletjes toepast.

Lees het log van de peer voordat je de client opnieuw wijzigt. Een weigering, een beleidsverschil en een stille drop zijn drie verschillende oorzaken die op het scherm van de Mac allemaal op “verbinden” lijken.

Oudere clients en de 64-bits kernel

De oude Cisco IPSec-client laadt een kerneluitbreiding die voor 32-bits en PowerPC-systemen is gebouwd. Op een Mac die in de 64-bits kernel start, kan die uitbreiding niet laden, en de client faalt vroeg met fout 51 omdat hij het VPN-subsysteem helemaal niet bereikt. Geen enkele hoeveelheid herstarts van de daemon repareert een kerneluitbreiding met de verkeerde architectuur.

De uitbreiding opnieuw laden kan even werken en daarna bij de volgende opstart weer falen. De duurzame antwoorden zijn de oudere kernel draaien waar dat nog wordt ondersteund, of overstappen op de ingebouwde client die met het systeem meekomt. Controleer de architectuur voordat je een avond besteedt aan een client van derden die niet kan laden.

• Reproduceer één keer en controleer dan welke daemon UDP 500 bezit voordat je het profiel aanraakt.
• Lees de eerste fout na fase 1: een verzendfout wijst op de lokale socket.
• Herstart de launchd-taak, niet alleen het proces, en bevestig dat de poort vrij is.
• Probeer een tweede account om een herauthenticatievenster aan de serverkant te scheiden van een fout in de client.
• Noteer de kernelarchitectuur voordat je de client de schuld geeft.

Een VPN die precies één keer werkt is een toestandsprobleem tot het tegendeel bewezen is. De daemon opruimen is sneller dan herstarten, en het bewaart het logbewijs dat een herstart zou hebben weggegooid.