L2TP/IPsec не працює, коли службу IKEEXT вимкнено

Немає IKEEXT — немає IPsec: L2TP і IKEv2 зазнають невдачі, тоді як інші типи все ще підключаються. Перевірте службу і потім з'ясуйте, що її вимкнуло, перш ніж редагувати профіль.

Один ноутбук підключається до шлюзу IKEv2, але зазнає невдачі зі шлюзом L2TP/IPsec, і помилка з'являється до того, як надіслано будь-яке ім'я користувача. Профіль зазвичай перший підозрюваний і зазвичай неправильний. Windows виконує обмін ключами IPsec у службі, і поки ця служба вимкнена, вбудований клієнт не має стеку, з яким можна вести переговори. Перевірте службу, перш ніж торкатися хоч одного поля профілю, і потім з'ясуйте, що її вимкнуло.

Служба, що стоїть за збоєм

IKE and AuthIP IPsec Keying Modules, що відображається в списку служб як IKEEXT, виконує обмін ключами і утримує сокети UDP 500 і 4500 у Windows. Вимкніть її, і L2TP/IPsec та IKEv2 обидва втрачають свого переговорника, тоді як PPTP і SSTP можуть продовжувати працювати, бо від неї не залежать. Цей поділ пояснює, чому користувач може повідомити, що один тип VPN працює, а інший мертвий на тій самій машині. Служба є частиною операційної системи, тому жоден параметр профілю не може її замінити.

Звільнення цих двох портів — побічний ефект, що породжує погані поради. Інструмент або повідомлення на форумі помічає, що 500 і 4500 зайняті, зупиняє службу, щоб їх звільнити, і тим самим мовчки видаляє IPsec з вузла. Обидва ефекти — одна дія, тому будь-який посібник, що радить очистити порти, описує обмін, а не ремонт.

Поверніть службу на місце без здогадок

Поставте диспетчеру служб два запитання: який тип запуску і який поточний стан. Перше каже, чи повернеться служба після перезавантаження; друге — чи працює вона зараз. Виконайте обидва запити з командного рядка з підвищеними правами, щоб та сама оболонка могла потім змінити налаштування.

sc qc ikeext
sc query ikeext

Тип запуску Disabled пояснює весь симптом, і рішення — повернути його в Automatic і запустити службу. У консолі «Служби» запис відображається під його відображуваним іменем IKE and AuthIP IPsec Keying Modules, тому пошук IKEEXT у цьому списку нічого не знаходить. Перезавантажтеся, якщо службу було запущено вже після того, як невдале підключення встигло відбутися, бо стек, ініціалізований у такому порядку, може відмовляти способами, що здаються не пов'язаними.

sc config ikeext start= auto
net start ikeext

Що знову її вимикає

Деякі сторонні VPN-пакети постачають власну реалізацію IPsec і вимикають IKEEXT під час встановлення, після чого клієнт Windows перестає працювати. Видалення іншого продукту відновило L2TP/IPsec на машинах, де редагування профілю нічого не давало, і те саме зробило перевстановлення без конфліктного компонента. Службу було вимкнено під час встановлення, а не перемкнуто користувачем.

Групова політика також може закріпити тип запуску; у цьому разі локальна зміна відкочується під час наступного оновлення, і адміністратор, який володіє політикою, має її змінити. Записуйте тип запуску до перезавантаження, після перезавантаження і після оновлень іншого продукту, щоразу з датою. Значення, яке постійно повертається до Disabled, викриває свого власника за схемою, а не за здогадками.

Спочатку прочитайте етап, потім журнал

Коли служба працює, етап збою вирішує, куди дивитися далі. Затримка під час IKE зазвичай означає, що UDP 500 або 4500 так і не досяг сервера, або що сервер перебуває за NAT без відповідного налаштування інкапсуляції. Дійти до запиту облікових даних і зазнати невдачі там — це проблема автентифікації PPP, а не IPsec. Тунель, який піднімається і нічого не досягає, — це збій маршрутизації або розділеного тунелю, і лише перший із цих трьох живе в профілі VPN.

Профілі з сертифікатом додають власний етап. Клієнт повинен довіряти видавцеві, а сертифікат повинен називати сервер, що перевіряється; коли будь-яка з двох умов не виконується, діалог усе одно повідомляє про помилку початкового узгодження, тому саме журнал подій показує справжню причину. Прочитайте запис у журналі до редагування профілю, бо діалог стискає кілька різних збоїв в одну фразу. Прострочений сертифікат дає той самий діалог, що й вимкнена служба, і тому запис у журналі важливий.

Запишіть збійний етап, текст помилки та позначку часу для кожної спроби. Ці три поля відокремлюють проблему доступності від проблеми автентифікації та від проблеми маршрутизації, і вони перетворюють наступну зміну на рішення, а не на здогад.

Чого не може довести локальний ремонт

Відновлення служби виправляє ту половину шляху, що знаходиться на ноутбуці. Працююча служба доводить лише локальну половину: віддалена сторона все ще повинна прийняти вибрану пропозицію, передані облікові дані та адресу джерела, з якої надходить пакет. Ніщо, зроблене на ноутбуці, не компенсує міжмережевий екран, який відкидає UDP 500 до того, як він досягне партнера. Успішний стан служби — це передумова, а не доказ того, що тунель підніметься.

Вимикати IKEEXT заради звільнення портів можна виправдати, лише якщо ви приймаєте, що IPsec-VPN Windows перестануть працювати. Це вирішує конфлікт портів, прибираючи функцію, якій був потрібен порт, і таке рідко буває обміном, який задумав користувач. Перш ніж щось змінити, підтвердьте, що служба присутня, встановлена в Automatic і працює, що другий стек IPsec не встановлено і що попередньо спільний ключ або ланцюжок сертифікатів відповідає шлюзу.

  • IKEEXT присутня, встановлена в Automatic і працює до підключення клієнта.
  • Ніщо інше не утримує UDP 500 або 4500.
  • Від старого клієнта не залишається другого стеку IPsec.
  • Ключ або ланцюжок сертифікатів відповідає конфігурації шлюзу.
  • Збійний етап було записано до редагування профілю.

Схожі статті