Ang VPN ng Mac ay kumokonekta nang isang beses at pagkatapos ay nag-time out: linisin ang IKE daemon

Gumagana ang unang koneksyon pagkatapos ng reboot. Bawat pagtatangka pagkatapos nito ay bumabitin sa yugto ng pagkonekta at sa huli ay nag-time out, at ang tanging maaasahang lunas ay isa pang reboot. Ang pattern na iyon ay hindi problema sa profile at hindi problema sa kredensyal. May isang bagay sa background na hawak pa rin ang estado mula sa nakaraang pagtatangka, at bumabangga rito ang susunod na pagtatangka.

Sa macOS, ang bagay na iyon ay karaniwang ang IKE daemon.

Ang pattern: isang koneksyon, pagkatapos ay timeout

Ang koneksyon na gumagana nang eksaktong isang beses kada boot ay tumuturo sa estadong nakakaligtas sa disconnect ngunit hindi sa reboot. Nakakaligtas ang mga profile sa dalawa, kaya ang profile ay hindi ang variable. Nakakaligtas din ang mga kredensyal sa dalawa, maliban kung i-lock ng server ang account. Ang nagbabago sa reboot ay ang set ng mga tumatakbong daemon at ang mga socket na hawak nila.

Pinapaliit nito ang imbestigasyon bago ka magbukas ng kahit isang log. Ang tanong ay kung aling proseso ang may-ari ng IKE port at ano ang inaakala nitong ginagawa nito.

Dalawang daemon, isang port

Pinapatakbo ng system racoon kapag ang isang koneksyon ay nagsasalita ng IKE bersyon 1. Ang mga kasalukuyang release ay nagdadala rin iked para sa IKEv2 at sa mas bagong IPsec stack. Pareho silang makakakuha ng UDP 500 at UDP 4500, at pareho silang makakapagpanatili ng kalahating bukas na security association pagkatapos kanselahin ang pagtatangka ng koneksyon sa password prompt o maantala ng pagbabago ng network.

Kapag nangyari iyon, hindi malinis na nagsisimula ang susunod na pagtatangka. Sinusubukan nitong makipagnegosasyon habang inookupa pa ng lumang association ang estado ng peer, at natigil ang palitan sa halip na mabigo nang may malinaw na error. Nakikita ng user ang umiikot na indicator, pagkatapos ay timeout.

Hanapin ang may-ari bago pumatay ng kahit ano, dahil ang sagot ang magtatakda kung aling serbisyo ang i-restart mo at aling log ang babasahin mo sa susunod.

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

Basahin ang output bilang dalawang katotohanan: aling proseso ang may hawak ng port, at kung may higit sa isa. Dalawang IKE daemon na nag-aagawan sa parehong socket ang nagpapaliwanag ng maraming pasulpot-sulpot na pag-uugali na mukhang hindi matatag na server.

I-restart ang trabaho, hindi ang proseso

Sa mas lumang sistema, sapat na patayin ang proseso at hayaan ang susunod na koneksyon na simulan itong muli. Sa mga kasalukuyang release, ang daemon ay pinamamahalaan ng launchd, at ang pagpapadala ng signal sa proseso lamang ay maaaring mag-iwan ng trabaho sa estadong hindi ito tumatakbo at hindi rin naka-iskedyul na magsimula. Itigil at simulan ang trabaho sa halip.

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

Kung walang tala ang launchd tungkol sa trabaho, pipilitin pa rin ng pagpatay sa proseso ayon sa pangalan ang isang bagong negosasyon sa susunod na pagtatangka. Pareho ang pagsubok sa dalawang kaso: walang proseso ang dapat may hawak ng port kapag sinusubukan mong kumonekta muli. Kumpirmahin iyon gamit ang parehong command lsof sa halip na ipagpalagay na gumana ang restart.

Pagkatapos ay kumonekta nang isang beses at basahin ang log ng client mula sa simula. Ang negosasyong lumalampas sa yugto 1 at pagkatapos ay nag-uulat ng transmit failure ay inuulit ang lokal na problema sa socket; isang negosasyong tinanggihan ng peer ay ganap na ibang ticket.

Kapag ang server ang tumatanggi

Hindi lahat ng pangalawang koneksyon ay nabibigo nang lokal. Maaaring tanggihan ng server ang isang bagong login sa loob ng isang takdang window pagkatapos ng disconnect, at ang timeout ng client ay mukhang kapareho ng isang stuck na daemon. Mura ang pagkakaiba: kung hindi tumutulong ang pag-restart ng daemon ngunit agad na kumokonekta ang ibang account, nasa panig ng server ang window at hindi kailanman naging problema ang Mac.

Ang patakaran ng split tunnel ay gumagawa ng parehong hugis mula sa kabilang direksyon. Itatapon ng server na nangangailangan ng lahat ng trapiko sa tunnel ang isang client na naka-configure para sa split tunnel habang nagaganap ang negosasyon, at ang client ay mag-uulat ng timeout sa halip na pagtanggi ng patakaran. Ang pagbabago ng profile para ipadala ang lahat sa tunnel ay maaaring makapagkonekta, ngunit iyon ay isang desisyon sa patakaran na gagawin kasama ng may-ari ng network, hindi isang pagkukumpuni na tahimik na ilalapat.

Basahin ang log ng peer bago baguhin muli ang client. Ang pagtanggi, hindi pagkakatugma ng patakaran at tahimik na pagtatapon ay tatlong magkaibang dahilan na lahat ay mukhang “kumokonekta” sa screen ng Mac.

Mas lumang client at ang 64-bit na kernel

Ang lumang Cisco IPSec client ay naglo-load ng kernel extension na ginawa para sa 32-bit at PowerPC na sistema. Sa Mac na nag-boot sa 64-bit na kernel, hindi mai-load ang extension na iyon, at maagang nabibigo ang client na may error 51 dahil hindi nito naaabot ang VPN subsystem. Walang dami ng pag-restart ng daemon ang makakagawa ng kernel extension na may maling arkitektura.

Ang muling pag-load ng extension ay maaaring gumana nang ilang sandali at pagkatapos ay mabigo muli sa susunod na boot. Ang matatag na sagot ay patakbuhin ang mas lumang kernel kung saan sinusuportahan pa ito, o lumipat sa built-in na client na kasama ng system. Suriin ang arkitektura bago magsayang ng isang gabi sa isang third-party client na hindi mai-load.

• I-reproduce nang isang beses, pagkatapos ay tingnan kung aling daemon ang may-ari ng UDP 500 bago hawakan ang profile.
• Basahin ang unang kabiguan pagkatapos ng yugto 1: itinuturo ng transmit error ang lokal na socket.
• I-restart ang launchd job, hindi lang ang proseso, at kumpirmahin na malaya ang port.
• Subukan ang pangalawang account upang ihiwalay ang window ng reauthentication sa panig ng server mula sa depekto ng client.
• Itala ang arkitektura ng kernel bago sisihin ang client.

Ang VPN na gumagana nang eksaktong isang beses ay problema sa estado hanggang mapatunayang salungat. Ang paglilinis ng daemon ay mas mabilis kaysa sa reboot, at pinapanatili nito ang ebidensya sa log na itatapon ng reboot.