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

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

Повезани чланци