Mac-VPN ansluter en gång och får sedan timeout: rensa IKE-demonen

Den första anslutningen efter en omstart fungerar. Varje försök därefter hänger i anslutningsfasen och slutar till sist i en timeout, och det enda pålitliga botemedlet är ännu en omstart. Mönstret är inte ett profilproblem och det är inte ett problem med inloggningsuppgifter. Något i bakgrunden håller fortfarande kvar tillståndet från det förra försöket, och nästa försök kolliderar med det.

På macOS är det något oftast IKE-demonen.

Mönstret: ansluter en gång, sedan timeout

En anslutning som fungerar exakt en gång per uppstart pekar på tillstånd som överlever en frånkoppling men inte en omstart. Profiler överlever båda, så profilen är inte variabeln. Inloggningsuppgifter överlever också båda, om inte servern låser kontot. Det som ändras vid omstart är uppsättningen körande demoner och de sockets de håller.

Det snävar in undersökningen innan du öppnar en enda logg. Frågan blir vilken process som äger IKE-porten och vad den tror att den gör.

Två demoner, en port

Systemet kör racoon när en anslutning talar IKE version 1. Nuvarande versioner tar också in iked för IKEv2 och den nyare IPsec-stacken. Båda kan binda UDP 500 och UDP 4500, och båda kan hålla en halvöppen säkerhetsassociation efter att ett anslutningsförsök avbrutits vid lösenordsfrågan eller störts av en nätverksändring.

När det händer börjar nästa försök inte rent. Det försöker förhandla medan den gamla associationen fortfarande upptar motpartens tillstånd, och utbytet stannar i stället för att misslyckas med ett tydligt fel. Användaren ser en snurra och sedan en timeout.

Hitta ägaren innan du dödar något, eftersom svaret avgör vilken tjänst du startar om och vilken logg du läser härnäst.

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

Läs utdata som två fakta: vilken process som håller porten och om det finns mer än en. Två IKE-demoner som konkurrerar om samma socket förklarar mycket oregelbundet beteende som ser ut som en instabil server.

Starta om jobbet i stället för processen

På äldre system räcker det att döda processen och låta nästa anslutning starta den igen. I nuvarande versioner hanteras demonen av launchd, och att bara skicka en signal till processen kan lämna jobbet i ett tillstånd där det varken körs eller är schemalagt att starta. Stoppa och starta jobbet i stället.

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

Om launchd inte har någon post för jobbet tvingar det ändå fram en ny förhandling vid nästa försök att döda processen vid namn. Testet är detsamma i båda fallen: ingen process bör hålla porten när du försöker ansluta igen. Bekräfta det med samma kommando lsof i stället för att anta att omstarten fungerade.

Anslut sedan en gång och läs klientloggen från början. En förhandling som går förbi fas 1 och sedan rapporterar ett överföringsfel upprepar det lokala socketproblemet; en förhandling som motparten avvisar är en helt annan biljett.

När det är servern som avvisar

Inte varje andra anslutning misslyckas lokalt. En server kan avvisa en ny inloggning under ett fast fönster efter en frånkoppling, och klientens timeout ser identisk ut med en hängd demon. Skillnaden är billig: om omstart av demonen inte hjälper men ett annat konto ansluter direkt är fönstret på serversidan och Macen var aldrig problemet.

Policyn för delad tunnel ger samma form från andra hållet. En server som kräver all trafik i tunneln släpper en klient som är konfigurerad för delad tunnel under förhandlingen, och klienten rapporterar en timeout i stället för en policyavvisning. Att ändra profilen så att allt går genom tunneln kan få den att ansluta, men det är ett policybeslut som fattas med nätverksägaren, inte en reparation som tillämpas tyst.

Läs motpartens logg innan du ändrar klienten igen. En avvisning, en policyavvikelse och ett tyst bortfall är tre olika orsaker som alla ser ut som ”ansluter” på Macens skärm.

Äldre klienter och 64-bitarskärnan

Den gamla Cisco IPSec-klienten läser in en kärntillägg byggt för 32-bitars och PowerPC-system. På en Mac som startar i 64-bitarskärnan kan det tillägget inte läsas in, och klienten misslyckas tidigt med fel 51 eftersom den inte alls når VPN-undersystemet. Ingen mängd omstarter av demonen reparerar ett kärntillägg med fel arkitektur.

Att läsa in tillägget igen kan fungera ett tag och sedan misslyckas igen vid nästa uppstart. De hållbara svaren är att köra den äldre kärnan där det fortfarande stöds, eller att byta till den inbyggda klient som följer med systemet. Kontrollera arkitekturen innan du lägger en kväll på en tredjepartsklient som inte kan läsas in.

• Reproducera en gång och kontrollera sedan vilken demon som äger UDP 500 innan du rör profilen.
• Läs det första felet efter fas 1: ett överföringsfel pekar på den lokala socketen.
• Starta om launchd-jobbet, inte bara processen, och bekräfta att porten är ledig.
• Prova ett andra konto för att skilja ett återautentiseringsfönster på serversidan från ett klientfel.
• Anteckna kärnans arkitektur innan du skyller på klienten.

En VPN som fungerar exakt en gång är ett tillståndsproblem tills motsatsen bevisats. Att rensa demonen är snabbare än en omstart, och det bevarar loggbevisen som en omstart skulle ha kastat.