Першае злучэнне пасля перазагрузкі працуе. Кожная спроба пасля яго завісае на этапе падключэння і ўрэшце сканчаецца тайм-аўтам, і адзінае надзейнае лячэнне — яшчэ адна перазагрузка. Гэтая заканамернасць не праблема профілю і не праблема ўліковых даных. Нешта ў фоне ўсё яшчэ трымае стан ад папярэдняй спробы, і наступная спроба сутыкаецца з ім.

На 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, які працуе роўна адзін раз, — гэта праблема стану, пакуль не даказана адваротнае. Ачыстка дэмана хутчэйшая за перазагрузку, і яна захоўвае доказы з журналаў, якія перазагрузка выкінула б.

Падобныя артыкулы