Помилка L2TP/IPsec 789, 720 або 691: спершу виправте потрібний етап

Windows 11 повідомляє різний номер для кожного етапу L2TP/IPsec, і цей номер позначає етап, а не оцінює збій. 789 завершується невдачею до того, як існує з'єднання PPP, 720 — під час підйому з'єднання, а 691 — після того, як з'єднання піднялося і облікові дані відхилено. Корисне рішення — не те, яке виправлення популярніше, а те, який етап код доводить, що ви його досягли. Прочитайте це першим, потім змінюйте по одному рівню за спробу, щоб наступний код ще щось вам казав.

Читайте код як етап, а не як список несправностей

З'єднання L2TP перетинає три межі у фіксованому порядку. IKE узгоджує асоціації безпеки через UDP 500, обхід NAT переносить цей трафік на UDP 4500, і лише потім тунель L2TP несе сеанс PPP, який автентифікує користувача та призначає адресу.

Саме цей порядок робить змінний код помилки корисним доказом. Перехід з 789 на 720 означає, що IPsec тепер узгоджує, а збій перемістився до встановлення з'єднання. Перехід з 720 на 691 означає, що з'єднання піднялося і шлюз відхилив ідентичність. Якщо застосувати п'ять виправлень одразу, ви втратите цей сигнал і не зможете сказати, яка зміна спрацювала.

789: виберіть між шляхом і локальною політикою

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

Переконайтеся, що UDP 500 і UDP 4500 доходять до сервера і що попередньо спільний ключ збігається байт у байт, включно з регістром і пробілами в кінці. Якщо сервер за NAT, Windows може також знадобитися задокументоване значення реєстру. Використовуйте 1, коли сервер за NAT, і 2, коли за NAT обидва кінці, потім перезавантажтеся, бо агент політики читає значення під час запуску:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent" /v AssumeUDPEncapsulationContextOnSendRule /t REG_DWORD /d 1 /f

Серйозніший ремонт адаптера належить до іншої гілки. Видалення Wi-Fi-пристрою та міні-портів WAN і потім повторне сканування обладнання виправдане, коли сам локальний стек IPsec пошкоджений і інші типи VPN не працюють так само. Це марна праця, коли не працює лише один сервер L2TP, а всі інші мережеві шляхи працюють.

720: виберіть між цим адаптером і пулом серверів

Помилка 720 повідомляє, що з'єднання з віддаленим комп'ютером не вдалося встановити, і з'являється після успіху IPsec. Тунель дійшов до моменту підняття інтерфейсу або отримання адреси, а потім зупинився. Це робить її питанням локального адаптера або питанням місткості сервера.

Використовуйте радіус ураження для рішення. Відмова однієї машини Windows вказує на несправний міні-порт WAN, зупинену службу Remote Access або пошкоджений профіль з'єднання. Відмова кількох клієнтів одночасно вказує на сервер: вичерпаний пул адрес, зупинену службу RRAS або пул, що більше не відповідає підмережі клієнта. Виправте ту сторону, на яку вказує картина, перш ніж змінювати іншу.

У гілці з одним клієнтом один раз видаліть міні-порти WAN і проскануйте зміни обладнання, потім перезавантажтеся і спробуйте знову. У гілці сервера перевірте пул і стан служби, а не клієнта, бо переінсталяція робочого адаптера не може створити адресу, якої сервер не має.

691: виберіть між обліковими даними і зупиненим помічником

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

Спочатку перевірте поле домену, потім точні символи в паролі. Пароль, що містить пробіл, лапку або спеціальний символ оболонки, може бути зіпсований до того, як дійде до сервера; у Linux pppd повідомляє ту саму відмову, що й E=691 для значення без лапок або відсутнього домену. Введіть секрет заново замість вставлення та видаліть будь-які збережені облікові дані, що можуть містити старе значення.

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

Щоб розділити гілки, перевірте те саме ім'я користувача на іншому робочому профілі VPN або тестовому обліковому записі RADIUS. Якщо це вдається, облікові дані в порядку, а локальний шлях клієнта підозрілий. Якщо це не вдається так само, проблема в обліковому записі або політиці шлюзу.

Змінюйте по одному рівню за спробу

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

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

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