Mac-VPN forbinder én gang og får derefter timeout: ryd IKE-dæmonen

Den første forbindelse efter en genstart virker. Hvert forsøg derefter hænger i forbindelsesfasen og ender til sidst i en timeout, og den eneste pålidelige kur er endnu en genstart. Det mønster er ikke et profilproblem, og det er ikke et legitimationsproblem. Noget i baggrunden holder stadig tilstanden fra det forrige forsøg, og det næste forsøg kolliderer med det.

På macOS er det noget som regel IKE-dæmonen.

Mønstret: forbinder én gang, derefter timeout

En forbindelse, der virker præcis én gang ved hver opstart, peger på tilstand, der overlever en afbrydelse men ikke en genstart. Profiler overlever begge, så profilen er ikke variablen. Legitimationsoplysninger overlever også begge, medmindre serveren låser kontoen. Det, der ændrer sig ved genstart, er sættet af kørende dæmoner og de sockets, de holder.

Det indsnævrer undersøgelsen, før du åbner en enkelt log. Spørgsmålet bliver, hvilken proces der ejer IKE-porten, og hvad den tror, den laver.

To dæmoner, én port

Systemet kører racoon når en forbindelse taler IKE version 1. Nuværende udgivelser tager også iked for IKEv2 og den nyere IPsec-stak. Begge kan binde UDP 500 og UDP 4500, og begge kan holde en halvåben sikkerhedsassociation, efter at et forbindelsesforsøg er annulleret ved adgangskodefeltet eller afbrudt af en netværksændring.

Når det sker, starter det næste forsøg ikke rent. Det forsøger at forhandle, mens den gamle association stadig optager peerens tilstand, og udvekslingen går i stå i stedet for at fejle med en klar fejl. Brugeren ser en spinner og derefter en timeout.

Find ejeren, før du dræber noget, fordi svaret afgør, hvilken tjeneste du genstarter, og hvilken log du læser næste gang.

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

Læs outputtet som to fakta: hvilken proces der holder porten, og om der er mere end én til stede. To IKE-dæmoner, der konkurrerer om den samme socket, forklarer en masse uregelmæssig adfærd, der ligner en ustabil server.

Genstart jobbet i stedet for processen

På ældre systemer er det nok at dræbe processen og lade den næste forbindelse starte den igen. På nuværende udgivelser styres dæmonen af launchd, og et signal til processen alene kan efterlade jobbet i en tilstand, hvor det hverken kører eller er planlagt til at starte. Stop og start jobbet i stedet.

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

Hvis launchd ikke har en registrering af jobbet, tvinger det stadig en frisk forhandling frem ved næste forsøg at dræbe processen ved navn. Testen er den samme uanset hvad: ingen proces bør holde porten, når du prøver at forbinde igen. Bekræft det med den samme kommando lsof i stedet for at antage, at genstarten virkede.

Forbind derefter én gang og læs klientloggen fra begyndelsen. En forhandling, der kommer forbi fase 1 og derefter rapporterer en transmissionsfejl, gentager det lokale socketproblem; en forhandling, som peeren afviser er en helt anden billet.

Når det er serveren, der afviser

Ikke hver anden forbindelse fejler lokalt. En server kan afvise et nyt login i et fast vindue efter en afbrydelse, og klientens timeout ser identisk ud med en fastlåst dæmon. Adskillelsen er billig: hvis genstart af dæmonen ikke hjælper, men en anden konto forbinder med det samme, er vinduet serverside, og Mac'en var aldrig problemet.

Politik for delt tunnel giver samme form fra den anden side. En server, der kræver al trafik i tunnelen, dropper en klient, der er konfigureret til delt tunnel, under forhandlingen, og klienten rapporterer en timeout i stedet for en politikafvisning. At ændre profilen til at sende alt gennem tunnelen kan få den til at forbinde, men det er en politikbeslutning, der skal tages med netværksejeren, ikke en reparation, der stille anvendes.

Læs peerens log, før du ændrer klienten igen. En afvisning, et politikmismatch og et tavst drop er tre forskellige årsager, der alle ser ud som “forbinder” på Mac'ens skærm.

Ældre klienter og 64-bit kernen

Den gamle Cisco IPSec-klient indlæser en kerneudvidelse bygget til 32-bit og PowerPC-systemer. På en Mac startet i 64-bit kernen kan den udvidelse ikke indlæses, og klienten fejler tidligt med fejl 51, fordi den slet ikke kan nå VPN-undersystemet. Ingen mængde genstart af dæmonen retter en kerneudvidelse med den forkerte arkitektur.

Genindlæsning af udvidelsen kan virke et stykke tid og derefter fejle igen ved næste opstart. De holdbare svar er at køre den ældre kerne, hvor det stadig understøttes, eller at skifte til den indbyggede klient, der følger med systemet. Tjek arkitekturen, før du bruger en aften på en tredjepartsklient, der ikke kan indlæses.

• Genskab én gang, og tjek derefter, hvilken dæmon der ejer UDP 500, før du rører profilen.
• Læs den første fejl efter fase 1: en transmissionsfejl peger på den lokale socket.
• Genstart launchd-jobbet, ikke kun processen, og bekræft, at porten er fri.
• Prøv en anden konto for at skelne et serverside-genautentificeringsvindue fra en klientfejl.
• Notér kernearkitekturen, før du giver klienten skylden.

Et VPN, der virker præcis én gang, er et tilstandsproblem, indtil det modsatte er bevist. At rydde dæmonen er hurtigere end at genstarte, og det bevarer de logbeviser, en genstart ville have smidt væk.