Mac-VPN kobler til én gang og får deretter tidsavbrudd: rydd IKE-demonen

Den første tilkoblingen etter en omstart fungerer. Hvert forsøk etterpå henger i tilkoblingsfasen og ender til slutt i en tidsavbrudd, og den eneste pålitelige kuren er nok en omstart. Mønsteret er ikke et profilproblem, og det er ikke et legitimasjonsproblem. Noe i bakgrunnen holder fortsatt på tilstanden fra forrige forsøk, og neste forsøk kolliderer med det.

På macOS er det noe vanligvis IKE-demonen.

Mønsteret: kobler til én gang, deretter tidsavbrudd

En tilkobling som fungerer nøyaktig én gang per oppstart peker på tilstand som overlever en frakobling, men ikke en omstart. Profiler overlever begge, så profilen er ikke variabelen. Legitimasjon overlever også begge, med mindre serveren låser kontoen. Det som endres ved omstart, er settet med kjørende demoner og socketene de holder.

Det snevrer inn undersøkelsen før du åpner en eneste logg. Spørsmålet blir hvilken prosess som eier IKE-porten, og hva den tror den gjør.

To demoner, én port

Systemet kjører racoon når en tilkobling snakker IKE versjon 1. Dagens utgivelser tar også inn iked for IKEv2 og den nyere IPsec-stakken. Begge kan binde UDP 500 og UDP 4500, og begge kan holde en halvåpen sikkerhetstilknytning etter at et tilkoblingsforsøk er avbrutt ved passordforespørselen eller forstyrret av en nettverksendring.

Når det skjer, starter ikke neste forsøk rent. Det prøver å forhandle mens den gamle tilknytningen fortsatt opptar tilstanden til motparten, og utvekslingen stopper i stedet for å feile med en klar feil. Brukeren ser en spinner og deretter en tidsavbrudd.

Finn eieren før du dreper noe, fordi svaret avgjør hvilken tjeneste du starter på nytt, og hvilken logg du leser neste gang.

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

Les utdataene som to fakta: hvilken prosess som holder porten, og om det er mer enn én til stede. To IKE-demoner som konkurrerer om samme socket forklarer mye uregelmessig oppførsel som ser ut som en ustabil server.

Start jobben på nytt i stedet for prosessen

På eldre systemer er det nok å drepe prosessen og la neste tilkobling starte den igjen. På dagens utgivelser styres demonen av launchd, og et signal til bare prosessen kan etterlate jobben i en tilstand der den verken kjører eller er planlagt å starte. Stopp og start jobben i stedet.

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

Hvis launchd ikke har en registrering av jobben, tvinger det likevel frem en frisk forhandling ved neste forsøk å drepe prosessen ved navn. Testen er den samme uansett: ingen prosess skal holde porten når du prøver å koble til igjen. Bekreft det med den samme kommandoen lsof i stedet for å anta at omstarten virket.

Koble deretter til én gang og les klientloggen fra begynnelsen. En forhandling som kommer forbi fase 1 og deretter rapporterer en overføringsfeil, gjentar det lokale socketproblemet; en forhandling som motparten avviser er en helt annen billett.

Når det er serveren som avviser

Ikke hver andre tilkobling feiler lokalt. En server kan avvise en ny innlogging i et fast vindu etter en frakobling, og klientens tidsavbrudd ser identisk ut med en fastlåst demon. Skillet er billig: hvis omstart av demonen ikke hjelper, men en annen konto kobler til med en gang, er vinduet på serversiden, og Macen var aldri problemet.

Politikk for delt tunnel gir samme form fra den andre siden. En server som krever all trafikk i tunnelen, slipper en klient som er konfigurert for delt tunnel under forhandlingen, og klienten rapporterer en tidsavbrudd i stedet for en politikkavvisning. Å endre profilen til å sende alt gjennom tunnelen kan få den til å koble til, men det er en politikkbeslutning som tas med nettverkseieren, ikke en reparasjon som brukes stille.

Les motpartens logg før du endrer klienten igjen. En avvisning, et politikkavvik og et stille dropp er tre forskjellige årsaker som alle ser ut som «kobler til» på Mac-skjermen.

Eldre klienter og 64-bit kjernen

Den gamle Cisco IPSec-klienten laster inn en kjerneutvidelse bygget for 32-bit og PowerPC-systemer. På en Mac som starter i 64-bit kjernen kan den utvidelsen ikke lastes, og klienten feiler tidlig med feil 51 fordi den ikke når VPN-undersystemet i det hele tatt. Ingen mengde omstart av demonen reparerer en kjerneutvidelse med feil arkitektur.

Å laste utvidelsen på nytt kan virke en stund og deretter feile igjen ved neste oppstart. De varige svarene er å kjøre den eldre kjernen der det fortsatt støttes, eller å bytte til den innebygde klienten som følger med systemet. Sjekk arkitekturen før du bruker en kveld på en tredjepartsklient som ikke kan lastes.

• Reproduser én gang, og sjekk deretter hvilken demon som eier UDP 500 før du rører profilen.
• Les den første feilen etter fase 1: en overføringsfeil peker på den lokale socketen.
• Start launchd-jobben på nytt, ikke bare prosessen, og bekreft at porten er ledig.
• Prøv en annen konto for å skille et serverside-godkjenningsvindu fra en klientfeil.
• Noter kjerneversjonens arkitektur før du gir klienten skylden.

En VPN som fungerer nøyaktig én gang er et tilstandsproblem til det motsatte er bevist. Å rydde demonen er raskere enn en omstart, og det bevarer loggbevisene som en omstart ville ha kastet.