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, който работи точно веднъж, е проблем със състоянието, докато не се докаже обратното. Изчистването на демона е по-бързо от презареждане и запазва доказателствата от логовете, които презареждането би изхвърлило.

Подобни статии