Ошибка 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 стирает эту карту и редко исправляет сбой, который живёт на шлюзе.

Когда код перестаёт меняться, перестаньте менять вещи. Зафиксируйте текущий код, адрес сервера, метод аутентификации и время попытки, затем сравните эту запись с работающим клиентом. Разница между двумя записями обычно меньше списка исправлений, которые люди пробуют по умолчанию.