VPN на Mac падключаецца адзін раз, потым тайм-аўт: ачысціце дэман IKE
Mac, які падключаецца адзін раз за загрузку, трымае састарэлую асацыяцыю IKE. Знайдзіце дэман, што валодае UDP 500, перазапусціце яго заданне і праверце акно сервера.
Першае злучэнне пасля перазагрузкі працуе. Кожная спроба пасля яго завісае на этапе падключэння і ўрэшце сканчаецца тайм-аўтам, і адзінае надзейнае лячэнне — яшчэ адна перазагрузка. Гэтая заканамернасць не праблема профілю і не праблема ўліковых даных. Нешта ў фоне ўсё яшчэ трымае стан ад папярэдняй спробы, і наступная спроба сутыкаецца з ім.
На macOS гэтае нешта звычайна дэман IKE.
Заканамернасць: адно злучэнне, потым тайм-аўт
Злучэнне, якое працуе роўна адзін раз за загрузку, паказвае на стан, які перажывае адключэнне, але не перазагрузку. Профілі перажываюць і тое, і тое, таму профіль не з'яўляецца зменнай. Уліковыя даныя таксама перажываюць і тое, і тое, калі сервер не блакуе ўліковы запіс. Што змяняецца пры перазагрузцы — гэта набор працуючых дэманаў і сокетаў, якія яны трымаюць.
Гэта звужае расследаванне яшчэ да таго, як вы адкрыеце хоць адзін журнал. Пытанне становіцца такім: які працэс валодае портам IKE і што ён думае, што робіць.
Два дэманы, адзін порт
Сістэма запускае racoon калі злучэнне размаўляе па IKE версіі 1. Бягучыя выпускі таксама прыносяць iked для IKEv2 і навейшага стэка IPsec. Абодва могуць займаць UDP 500 і UDP 4500, і абодва могуць трымаць паўадкрытую асацыяцыю бяспекі пасля таго, як спроба злучэння скасавана на запыце пароля або перапыненая зменай сеткі.
Калі гэта адбываецца, наступная спроба не пачынаецца з чыстага стану. Яна спрабуе весці перамовы, пакуль старая асацыяцыя ўсё яшчэ займае стан партнёра, і абмен застойваецца замест таго, каб скончыцца яснай памылкай. Карыстальнік бачыць індыкатар, потым тайм-аўт.
Знайдзіце ўладальніка, перш чым нешта забіваць, бо адказ вызначае, якую службу вы перазапусціце і які журнал прачытаеце далей.
sudo lsof -i :500 -i :4500
ps -ef | grep -E "racoon|iked"Чытайце вывад як два факты: які працэс трымае порт і ці прысутнічае больш за адзін з іх. Два дэманы IKE, якія спаборнічаюць за адзін сокет, тлумачаць шмат перарывістых паводзін, што выглядаюць як няўстойлівы сервер.
Перазапусціце заданне, а не працэс
На старэйшых сістэмах дастаткова забіць працэс і дазволіць наступнаму злучэнню запусціць яго зноў. У бягучых выпусках дэманам кіруе launchd, і сігнал толькі працэсу можа пакінуць заданне ў стане, дзе яно ні працуе, ні запланавана да запуску. Замест гэтага спыніце і запусціце заданне.
sudo launchctl stop com.apple.racoon
sudo launchctl start com.apple.racoonКалі launchd не мае запісу пра заданне, забойства працэсу па імені ўсё роўна прымусіць новыя перамовы пры наступнай спробе. Тэст аднолькавы ў любым выпадку: ніводзін працэс не павінен трымаць порт, калі вы зноў спрабуеце падключыцца. Пацвердзіце гэта той жа камандай lsof замест таго, каб меркаваць, што перазапуск спрацаваў.
Затым падключыцеся адзін раз і прачытайце журнал кліента з пачатку. Перамовы, якія праходзяць фазу 1, а затым паведамляюць пра памылку перадачы, паўтараюць лакальную праблему сокета; перамовы, адхіленыя партнёрам гэта зусім іншы білет.
Калі адмаўляе менавіта сервер
Не кожнае другое злучэнне церпіць няўдачу лакальна. Сервер можа адмаўляць у новым уваходзе на фіксаванае акно пасля адключэння, і тайм-аўт кліента выглядае ідэнтычна завісламу дэману. Адрозніць лёгка: калі перазапуск дэмана не дапамагае, але іншы ўліковы запіс падключаецца адразу, акно на баку сервера, і Mac ніколі не быў праблемай.
Палітыка падзеленага тунэлю стварае тую ж форму з іншага боку. Сервер, які патрабуе ўвесь трафік у тунэлі, скіне кліента, наладжанага на падзелены тунэль, падчас перамоваў, і кліент паведаміць пра тайм-аўт, а не пра адхіленне палітыкі. Змяненне профілю, каб слаць усё праз тунэль, можа дазволіць падключэнне, але гэта рашэнне палітыкі, якое трэба прымаць з уладальнікам сеткі, а не маўкліва ўжываць рамонт.
Прачытайце журнал партнёра, перш чым зноў змяняць кліента. Адхіленне, неадпаведнасць палітыкі і ціхае скідванне — тры розныя прычыны, якія ўсе выглядаюць як “падключэнне” на экране Mac.
Старыя кліенты і 64-бітнае ядро
Стары кліент Cisco IPSec загружае пашырэнне ядра, збудаванае для 32-бітных сістэм і PowerPC. На Mac, загружаным у 64-бітнае ядро, гэтае пашырэнне не можа загрузіцца, і кліент рана церпіць няўдачу з памылкай 51, бо зусім не дасягае падсістэмы VPN. Ніякая колькасць перазапускаў дэмана не выправіць пашырэнне ядра з няправільнай архітэктурай.
Перазагрузка пашырэння можа працаваць нейкі час, а потым зноў адмовіць пры наступнай загрузцы. Трывалыя рашэнні — запусціць старэйшае ядро там, дзе гэта яшчэ падтрымліваецца, або перайсці на ўбудаваны кліент, што пастаўляецца з сістэмай. Праверце архітэктуру, перш чым праводзіць вечар з кліентам трэцяга боку, які не можа загрузіцца.
- Аднавіце адзін раз, потым праверце, які дэман валодае UDP 500, перш чым кранаць профіль.
- Прачытайце першую няўдачу пасля фазы 1: памылка перадачы паказвае на лакальны сокет.
- Перазапусціце заданне launchd, а не толькі працэс, і пацвердзіце, што порт свабодны.
- Паспрабуйце другі ўліковы запіс, каб аддзяліць акно паўторнай аўтэнтыфікацыі на баку сервера ад збою кліента.
- Запішыце архітэктуру ядра, перш чым вінаваціць кліента.
VPN, які працуе роўна адзін раз, — гэта праблема стану, пакуль не даказана адваротнае. Ачыстка дэмана хутчэйшая за перазагрузку, і яна захоўвае доказы з журналаў, якія перазагрузка выкінула б.