VPN на Mac подключается один раз, а затем время ожидания истекает: очистите демон 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, который работает ровно один раз, — это проблема состояния, пока не доказано обратное. Очистка демона быстрее перезагрузки, и она сохраняет доказательства из журналов, которые перезагрузка выбросила бы.