Mac-VPN koplar til éin gong og får deretter tidsavbrot: rydd IKE-demonen

Den første tilkoplinga etter ein omstart fungerer. Kvart forsøk etterpå heng i tilkoplingsfasen og endar til slutt i eit tidsavbrot, og den einaste pålitelege kuren er nok ein omstart. Mønsteret er ikkje eit profilproblem, og det er ikkje eit legitimasjonsproblem. Noko i bakgrunnen held framleis på tilstanden frå førre forsøk, og neste forsøk kolliderer med det.

På macOS er det noko vanlegvis IKE-demonen.

Mønsteret: koplar til éin gong, deretter tidsavbrot

Ei tilkopling som fungerer nøyaktig éin gong per oppstart peikar på tilstand som overlever ein fråkopling, men ikkje ein omstart. Profilar overlever begge, så profilen er ikkje variabelen. Legitimasjon overlever òg begge, med mindre tenaren låser kontoen. Det som endrar seg ved omstart, er settet med køyrande demonar og socketane dei held.

Det snevrar inn undersøkinga før du opnar ein einaste logg. Spørsmålet blir kva prosess som eig IKE-porten, og kva han trur han gjer.

To demonar, éin port

Systemet køyrer racoon når ei tilkopling snakkar IKE versjon 1. Dagens utgåver tek òg inn iked for IKEv2 og den nyare IPsec-stakken. Begge kan binda UDP 500 og UDP 4500, og begge kan halda ei halvopen sikkerheitstilknyting etter at eit tilkoplingsforsøk er avbrote ved passordførespurnaden eller forstyrra av ei nettverksendring.

Når det skjer, startar ikkje neste forsøk reint. Det prøver å forhandla medan den gamle tilknytinga framleis opptek tilstanden til motparten, og utvekslinga stoppar i staden for å feila med ein klar feil. Brukaren ser ein spinner og deretter eit tidsavbrot.

Finn eigaren før du drep noko, fordi svaret avgjer kva teneste du startar på nytt, og kva logg du les neste gong.

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

Les utdataa som to faktum: kva prosess som held porten, og om det er meir enn éin til stades. To IKE-demonar som konkurrerer om same socket forklarer mykje uregelmessig åtferd som ser ut som ein ustabil tenar.

Start jobben på nytt i staden for prosessen

På eldre system er det nok å drepa prosessen og la neste tilkopling starte han igjen. På dagens utgåver blir demonen styrt av launchd, og eit signal til berre prosessen kan etterlate jobben i ein tilstand der han korkje køyrer eller er planlagd å starte. Stopp og start jobben i staden.

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

Viss launchd ikkje har ei registrering av jobben, tvingar det likevel fram ei frisk forhandling ved neste forsøk å drepe prosessen ved namn. Testen er den same uansett: ingen prosess skal halda porten når du prøver å kopla til igjen. Stadfest det med den same kommandoen lsof i staden for å anta at omstarten verka.

Kopla deretter til éin gong og les klientloggen frå byrjinga. Ei forhandling som kjem forbi fase 1 og deretter rapporterer ein overføringsfeil, gientar det lokale socketproblemet; ei forhandling som motparten avviser er ein heilt annan billett.

Når det er tenaren som avviser

Ikkje kvar andre tilkopling feilar lokalt. Ein tenar kan avvise ei ny innlogging i eit fast vindauge etter ein fråkopling, og tidsavbrotet til klienten ser identisk ut med ein fastlåst demon. Skiljet er billeg: viss omstart av demonen ikkje hjelper, men ein annan konto koplar til med ein gong, er vindauget på tenarsida, og Macen var aldri problemet.

Politikk for delt tunnel gir same form frå den andre sida. Ein tenar som krev all trafikk i tunnelen, slepp ein klient som er konfigurert for delt tunnel under forhandlinga, og klienten rapporterer eit tidsavbrot i staden for ei politikkavvising. Å endra profilen til å senda alt gjennom tunnelen kan få han til å kopla til, men det er ei politikkavgjerd som blir teken med nettverkseigaren, ikkje ein reparasjon som blir brukt stille.

Les loggen til motparten før du endrar klienten igjen. Ei avvising, eit politikkavvik og eit stille dropp er tre ulike årsaker som alle ser ut som «koplar til» på Mac-skjermen.

Eldre klientar og 64-bit kjernen

Den gamle Cisco IPSec-klienten lastar inn ei kjerneutviding bygd for 32-bit og PowerPC-system. På ein Mac som startar i 64-bit kjernen kan den utvidinga ikkje lastast, og klienten feilar tidleg med feil 51 fordi han ikkje når VPN-undersystemet i det heile. Ingen mengd omstart av demonen reparerer ei kjerneutviding med feil arkitektur.

Å lasta utvidinga på nytt kan verka ei stund og deretter feila igjen ved neste oppstart. Dei varige svara er å køyra den eldre kjernen der det framleis blir støtta, eller å byta til den innebygde klienten som følgjer med systemet. Sjekk arkitekturen før du brukar ein kveld på ein tredjepartsklient som ikkje kan lastast.

• Reproduser éin gong, og sjekk deretter kva demon som eig UDP 500 før du rører profilen.
• Les den første feilen etter fase 1: ein overføringsfeil peikar på den lokale socketen.
• Start launchd-jobben på nytt, ikkje berre prosessen, og stadfest at porten er ledig.
• Prøv ein annan konto for å skilja eit tenarside-godkjenningsvindauge frå ein klientfeil.
• Noter arkitekturen til kjernen før du gir klienten skulda.

Ein VPN som fungerer nøyaktig éin gong er eit tilstandsproblem til det motsette er prova. Å rydda demonen er raskare enn ein omstart, og det bevarer loggbevisa som ein omstart ville ha kasta.