Mac VPN се поврзува еднаш, потоа истекува времето: исчистете го IKE демонот

Првото поврзување по рестартирање работи. Секој обид потоа виси во фазата на поврзување и на крајот истекува времето, а единствениот сигурен лек е уште едно рестартирање. Овој образец не е проблем со профилот и не е проблем со акредитивите. Нешто во позадина сѐ уште ја држи состојбата од претходниот обид, и следниот обид се судира со тоа.

На 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 што работи точно еднаш е проблем со состојба додека не се докаже спротивното. Чистењето на демонот е побрзо од рестартирање, и ги зачувува доказите од дневникот што рестартирањето би ги фрлило.