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, який працює рівно один раз, — це проблема стану, доки не доведено протилежне. Очищення демона швидше за перезавантаження, і воно зберігає докази з журналів, які перезавантаження викинуло б.