Ike error zastava как исправить

Ошибка 13801, учетные данные для аутентификации IKE недопустимы

Виртуальная частная сеть (VPN) в основном используется для защиты конфиденциальности пользователей в онлайн-мире и определения их физического местоположения. Хотя в большинстве случаев они работают хорошо, в некоторых случаях пользователь может столкнуться с ошибками, сбоями или другими проблемами с подключением в своей программе VPN. Если ваша VPN не работает, не подключается или заблокирована, вы можете попробовать несколько быстрых решений. Хотя существует множество возможных ошибок, с которыми пользователь может столкнуться при использовании VPN, некоторые из них получают большее признание, чем другие; один из таких кодов ошибки Ошибка VPN 13801.

Ошибка VPN 13801 в Windows 10

Ошибка 13801 выражает сообщение — Учетные данные для аутентификации IKE недопустимы.

Эти ошибки Internet Key Exchange версии 2 (IKEv2) связаны с проблемами с сертификатом проверки подлинности сервера. По сути, сертификат компьютера, необходимый для аутентификации, либо недействителен, либо отсутствует на вашем клиентском компьютере, на сервере или на обоих.

Учетные данные для аутентификации IKE недопустимы

Вот краткое описание возможных причин ошибки 13801:

• Срок действия сертификата компьютера на сервере удаленного доступа истек.
• Доверенный корневой сертификат для проверки сертификата сервера удаленного доступа отсутствует на клиенте.
• Имя VPN-сервера, указанное на клиенте, не соответствует имени субъекта сертификата сервера.
• Сертификат компьютера, используемый для проверки IKEv2 на сервере удаленного доступа, не имеет «проверки подлинности сервера» в качестве EKU (расширенного использования ключа).

Поскольку пользователи не имеют никакого контроля над сервером, мало что можно сделать для решения этой проблемы. И в большинстве случаев пользователю, возможно, придется обратиться в службу поддержки провайдера VPN и попросить их исправить ошибку 13801.

Ошибка VPN 13801 явно ссылается на протоколы, используемые службой VPN, поэтому вам не нужно тратить время на выяснение того, что такое IKEv2 для ошибки 1380 VPN. Найдите правильный сертификат IKEv2 в документации, предоставленной администратором VPN. Есть несколько способов подтвердить эту проблему:

1. Сертификату не присвоены требуемые значения расширенного использования ключа (EKU).
2. Срок действия сертификата компьютера на сервере удаленного доступа истек.
3. Доверенный корень сертификата отсутствует на клиенте.
4. Имя субъекта сертификата не соответствует удаленному компьютеру

Давайте рассмотрим эти варианты подробнее:

Сертификату не присвоены требуемые значения расширенного использования ключа (EKU).

Вы можете проверить это, выполнив следующие действия:

1]На сервере VPN запустите ммс, добавить оснастку ‘сертификаты. ‘

2]Разверните сертификаты-личные-сертификаты, дважды щелкните установленный сертификат

3]Щелкните подробное описание для «улучшенное использование ключа ‘, проверьте, есть ли ‘проверка подлинности сервера‘ ниже

Срок действия сертификата компьютера на сервере удаленного доступа истек.

Если проблема вызвана этой причиной, подключите Администратор ЦС и зарегистрируйте новый сертификат, срок действия которого не истекает.

Доверенный корень сертификата отсутствует на клиенте.

Если клиент и сервер являются членами домена, корневой сертификат будет автоматически установлен в ‘доверенные корневые центры сертификации.’ Проверить наличие сертификата на клиенте можно здесь.

Имя субъекта сертификата не соответствует удаленному компьютеру

Вы можете подтвердить, используя следующие шаги:

1]На клиенте открыть ‘Свойства VPN-подключения‘, щелкните’Общий. ‘

2]В ‘имя хоста или IP-адрес назначения‘вам нужно будет ввести’имя субъекта‘сертификата, используемого сервером VPN вместо IP-адреса сервера VPN.

Примечание: Имя субъекта сертификата сервера обычно настраивается как полное доменное имя VPN-сервера.

Когда звонить администратору VPN-сервера

Необходимость иметь дело с ошибками VPN может быть чрезвычайно неприятным, а когда вы не можете устранить их самостоятельно, разочарование еще больше. Это именно тот случай с ошибкой VPN 13801, поэтому не теряйте времени и обратитесь к администратору VPN, чтобы убедиться, что на вашем ПК настроен правильный сертификат, который подтвержден удаленным сервером.

Источник

Ike error zastava как исправить

В связи с законом о защите персональных данных, вышестоящая организация решила заменить доступ к своему web-серверу через инет(с аутентификацией по нашему IP-адресу, логину, паролю), на доступ через VPN канал. Для чего прислали ПО VPN клиент Застава, который соединясь с сервером должен давать доступ к внутренней локальной сетке и возможность подключаться на внутренний ip web 172.16. Трафик идет по 443 порту.

Опыт использования Eserva в режиме проброса IP адресов и портов для доступа на несколько серверов есть. прекрасно работает.
В Eserv прописал проброс на IP адрес сервера Заставы по UDP портам 500 и 4500. Соответсвенно в настройках Заставы подменил адрес сервера и портов.
Судя по журналу Заставы мой клиент с сервером ЦУП соединяется.

тест ike-scan через проброс 9209 192.168.10.3 дает положительный результат:

Вот только доступ к внутренней локальной сети 172.16. не создается.

telnet 172.16.2.18 443

Подключение к 172.16.2.18. Не удалось открыть подключение к этому узлу, на порт
443: Сбой подключения

Наугад прописал в настройках
ExternIP: мой внешний IP адрес
BindRoute: 172.16.2.0 255.255.255.0 192.168.10.3 не помогло.

Из вышестоящей организации на мой вопрос ответили, — мол мы в такой конфигурации (через прокси) Заставу не тестировали, получится — поделись опытом. (умельцы блин, до этого делился опытом, как я ее запускал на виртуальной машине)

Задал вопрос разработчикам Заставы, пока тишина.

Может кто наведет на мысль, в каком направлении копать?

Источник

[РЕШЕНО] January 11 12 января 2022 PPTP L2TP IPSEC IKE массово перестал работать Windows 10

WINDOWS 10 многие клиенты перестали подсоединяться по l2tpipsec
при этом судя по логам все умирает на самом начальном этапе на уровне установке соединения IPSEC
Если смотерть лог то ошибка 789
The L2TP connection attempt failed because the security layer encountered a processing error during initial negotiations with the remote computer (Попытка подключения L2TP не удалась, так как уровень безопасности обнаружил ошибку обработки во время первоначальных согласований с удаленным компьютером.)

Если смотреть с сторонны сервера то:
phase1 negotiation failed due to time up xxxxx[500] xxxxxxxxx[500]

и все думал проблема на провайдере но проблема много у кого и провайдеры разные.

РЕШЕНИЕ: обновления от 11 января 2022 года, которые, являются причиной данной проблемы:

Windows 10 — KB5009543
Windows 10 — Kb5008876
Windows 10 LTSC — KB5009557
Windows 11 — KB5009566

Как удалить обновление через повершелл:
wusa /uninstall /kb:5009543
wusa /uninstall /kb:5008876

wusa /uninstall /kb:5009566

Плохое РЕШЕНИЕ — отключить IPSEC шифрование для L2tp :
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesRasManParameters]
«AllowL2TPWeakCrypto»=dword:00000001
«ProhibitIpSec»=dword:00000001

Добрый день, коллеги!
Немного полезной информации. Сотрудница на личном ноуте умудрилась вместо удаления обновления сбросить систему, таким образом закрепив все обновления. Так что или ждать исправление от Microsoft, или иная рекомендация нужна. Ну роме рпереустановки ))
Скорее нужно ковырять реестр, но не понятно, что это обновление с ним сделало.

РЕШЕНИ ДЛЯ ВАС, это плохое решение, котое я описал выше — внести в реестр изменение и отключить IPSEC для L2TP

После установки KB5009543 подключения IP Security (IPSEC), содержащие ID поставщика, могут привести к сбойу. Кроме того, могут затронуть VPN-подключения с использованием протокола тоннелей уровня 2 (L2TP) или ключа ip security Internet Exchange (IPSEC IKE).

Обходное решение. Чтобы устранить проблему для некоторых VPN, можно отключить Vendor ID в параметрах на стороне сервера. Примечание. Не все VPN-серверы могут отключить ID поставщика от использования.

Дальнейшие действия. В настоящее время мы исследуем проблему и предоставим обновление в предстоящем выпуске.

Затронутые платформы:
Клиент: Windows 11, версия 21H2; Windows 10 версии 21H2; Windows 10 версии 21H1; Windows 10 версии 20H2; Windows 10 версии 1909; Windows 10, версия 1809; Windows 10 Корпоративная LTSC 2019; Windows 10 Корпоративная LTSC 2016; Windows 10 версии 1607; Windows 10 Корпоративная 2015 с долгосрочным обслуживанием
Сервер: Windows Server 2022; Windows Server, версия 20H2; Windows Server 2019; Windows Server 2016

Эти обновления не ломают PPTP. На машинах, где у нас сломался L2TP + IPSec, PPTP поднялся без проблем, так и «лечим» удаленных клиентов: пускаем к нам по PPTP, подключаемся к клиенту, удаляем обновление, убиваем PPTP.

К тому же по факту обновление ломает не L2TP, а IPSec, сразу после первой фазы на виндовом клиенте получаем ошибку 789, типа, не договорились о параметрах безопасности.

При этом L2TP с принудительно отключенным IPSec подключается.

Microsoft — признали проблему и написали обходное решение(об этом я писал выше):
Workaround: To mitigate the issue for some VPNs, you can disable Vendor ID within the server-side settings. Note: Not all VPN servers have the option to disable Vendor ID from being used. (по их словам решение отключить Vendor ID)

Можно ли отключит vendor-id для mikrotik ipsec, как рекомендует Microsoft
Ответ MIKROTIK об отключение vendor id:

Disabling Vendor ID sending on responder side is not a viable option in my opinion as NAT-T detection depends on Vendor ID’s. So disabling Vendor ID option on server side would not allow clients behind NAT to connect, which are most of Windows users anyway.
https://datatracker.ietf.org/doc/html/rfc3947#section-3.1

Итог, решение с отключение vendor id : отключение Vendor ID, как рекомендованный Microsoft обходной путь для их неработающего обновления, по существу сломает VPN для всех пользователей за NAT.

Решением по прежнему как я написал в первом ответе является удаление обновлений.

Источник

[РЕШЕНО] January 11 12 января 2022 PPTP L2TP IPSEC IKE массово перестал работать Windows 10

WINDOWS 10 многие клиенты перестали подсоединяться по l2tpipsec
при этом судя по логам все умирает на самом начальном этапе на уровне установке соединения IPSEC
Если смотерть лог то ошибка 789
The L2TP connection attempt failed because the security layer encountered a processing error during initial negotiations with the remote computer (Попытка подключения L2TP не удалась, так как уровень безопасности обнаружил ошибку обработки во время первоначальных согласований с удаленным компьютером.)

Если смотреть с сторонны сервера то:
phase1 negotiation failed due to time up xxxxx[500] xxxxxxxxx[500]

и все думал проблема на провайдере но проблема много у кого и провайдеры разные.

РЕШЕНИЕ: обновления от 11 января 2022 года, которые, являются причиной данной проблемы:

Windows 10 — KB5009543
Windows 10 — Kb5008876
Windows 10 LTSC — KB5009557
Windows 11 — KB5009566

Как удалить обновление через повершелл:
wusa /uninstall /kb:5009543
wusa /uninstall /kb:5008876

wusa /uninstall /kb:5009566

Плохое РЕШЕНИЕ — отключить IPSEC шифрование для L2tp :
[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesRasManParameters]
«AllowL2TPWeakCrypto»=dword:00000001
«ProhibitIpSec»=dword:00000001

Добрый день, коллеги!
Немного полезной информации. Сотрудница на личном ноуте умудрилась вместо удаления обновления сбросить систему, таким образом закрепив все обновления. Так что или ждать исправление от Microsoft, или иная рекомендация нужна. Ну роме рпереустановки ))
Скорее нужно ковырять реестр, но не понятно, что это обновление с ним сделало.

РЕШЕНИ ДЛЯ ВАС, это плохое решение, котое я описал выше — внести в реестр изменение и отключить IPSEC для L2TP

После установки KB5009543 подключения IP Security (IPSEC), содержащие ID поставщика, могут привести к сбойу. Кроме того, могут затронуть VPN-подключения с использованием протокола тоннелей уровня 2 (L2TP) или ключа ip security Internet Exchange (IPSEC IKE).

Обходное решение. Чтобы устранить проблему для некоторых VPN, можно отключить Vendor ID в параметрах на стороне сервера. Примечание. Не все VPN-серверы могут отключить ID поставщика от использования.

Дальнейшие действия. В настоящее время мы исследуем проблему и предоставим обновление в предстоящем выпуске.

Затронутые платформы:
Клиент: Windows 11, версия 21H2; Windows 10 версии 21H2; Windows 10 версии 21H1; Windows 10 версии 20H2; Windows 10 версии 1909; Windows 10, версия 1809; Windows 10 Корпоративная LTSC 2019; Windows 10 Корпоративная LTSC 2016; Windows 10 версии 1607; Windows 10 Корпоративная 2015 с долгосрочным обслуживанием
Сервер: Windows Server 2022; Windows Server, версия 20H2; Windows Server 2019; Windows Server 2016

Эти обновления не ломают PPTP. На машинах, где у нас сломался L2TP + IPSec, PPTP поднялся без проблем, так и «лечим» удаленных клиентов: пускаем к нам по PPTP, подключаемся к клиенту, удаляем обновление, убиваем PPTP.

К тому же по факту обновление ломает не L2TP, а IPSec, сразу после первой фазы на виндовом клиенте получаем ошибку 789, типа, не договорились о параметрах безопасности.

При этом L2TP с принудительно отключенным IPSec подключается.

Microsoft — признали проблему и написали обходное решение(об этом я писал выше):
Workaround: To mitigate the issue for some VPNs, you can disable Vendor ID within the server-side settings. Note: Not all VPN servers have the option to disable Vendor ID from being used. (по их словам решение отключить Vendor ID)

Можно ли отключит vendor-id для mikrotik ipsec, как рекомендует Microsoft
Ответ MIKROTIK об отключение vendor id:

Disabling Vendor ID sending on responder side is not a viable option in my opinion as NAT-T detection depends on Vendor ID’s. So disabling Vendor ID option on server side would not allow clients behind NAT to connect, which are most of Windows users anyway.
https://datatracker.ietf.org/doc/html/rfc3947#section-3.1

Итог, решение с отключение vendor id : отключение Vendor ID, как рекомендованный Microsoft обходной путь для их неработающего обновления, по существу сломает VPN для всех пользователей за NAT.

Решением по прежнему как я написал в первом ответе является удаление обновлений.

Источник

Зарегистрирован: 29.06.2011
Пользователь #: 132,104
Сообщения: 10906

Источник

IPsec VPN через Strongswan: ошибка авторизации

Пробую поднять IPsec IKEv2 VPN, на обоих концах Strongswan, авторизация через сертификаты X.509. При подключении приходит отлуп с AUTH_FAILED на IKE_AUTH request 1. Со стороны сервера CA сертификат подгружается нормально, в логах нет явных сообщений про неизвестные сертификаты.

Как это всё пофиксить? IPsec настраиваю второй раз, мб что-то простое пропустил.

Ниже 1.2.3.4 – внешний IP сервера, 5.6.7.8 – внешний IP клиента, 192.168.0.2 – внутренний IP клиента, 192.168.0.100 – внутренний IP сервера.

edit: добавил лог с сервера

Хм, а так можно было оказывается.

Покажите лог с сервера.

Хм, а так можно было оказывается.

Забыл сразу добавить, отредактировал пост.

Та я как-то привык к ipsec.conf

От оно:
server charon[994]: 15[CFG] no matching peer config found

Не совсем понял, это для клиента указать? А куда тогда адрес сервера вбивать?

Если для клиента, то это вроде дефолт для swanctl-стиля (я так понимаю, что left и right соответствуют connections. .local_addrs и connections. .remote_addrs ). Я практически без изменений брал конфиг с официальной вики (Roadwarrior scenario → swanctl.conf).

Я предполагал, что это в порядке вещей, т.к. айпи клиента неизвестен, так что конфиг пира генерируется. Видимо, это не так. Как тогда быть? Получается, надо каким-то образом на сервере указать, чтобы принимался ID типа CN=client ?

Почти. Ему надо на основании «чего-то» решить, что вот этот кусок конфига относиться к этому клиенту. Но наискосок в мане чего-то аналогичного leftid | rightid в ipsec.conf и keyexchange не обнаружил. 🙁

Это для сервера.

В swanctl.conf можно указать connections. .remote.id , похоже, он работает как rightid для ipsec.conf . Пробовал указывать конкретный id клиента, но увы, всё та же ошибка.

Видимо, попробую переписать серверный конфиг в ipsec.conf-стиле: я как раз думал, что все уже много лет назад пересели на swanctl, а вот оно что.

попробую переписать серверный конфиг в ipsec.conf-стиле

На всякий случай кусок из моего ipsec.conf

я как раз думал, что все уже много лет назад пересели на swanctl

Точно не все 🙂 Я последний раз правил ipsec.conf всего два дня назад 🙂 И пока его не выпилят окончательно, менять конфиги желания ровно ноль. У меня там достаточно секций под разные соединения, пусть не всё уже нужно, но мало ли.

Спасибо! Правда, мне по идее смысла матчить так нет: CA тестовый, поэтому я заполнил только CN и SAN. А для продакшена, конечно, полезно по OU фильтровать.

Кроме того, я переписал почти один в один серверный конфиг:

И, о чудо, авторизация заработала. Видимо, этот swanctl это какая-то сырая (несмотря на заверения в официальных доках) штука.

А для продакшена, конечно, полезно по OU фильтровать.

Для себя любимого тоже полезно. Я в OU фильтрую по разным реализациям клиентов. Например для blackbery одно, для mac os x другое и т.д.

Видимо, этот swanctl это какая-то сырая (несмотря на заверения в официальных доках) штука.

Может и так. А может документацию не дописали. 😉

Я в OU фильтрую по разным реализациям клиентов.

Отличная идея, не думал о таком варианте.

Ага. Сама проблема в том, что это в лебеде вы можете настроить усе что угодно, а готовые реализации клиентов зачастую содержат захардкоженные наборы параметров. macOS одно, офтопик другое и т.д. Вот и приходиться под них подстраиваться.

Как оказалось, я просто невнимательно читал доки, а решение вполне есть. Разгадка в том, что при ipsec.conf-стиле с обоих сторон клиент отправляет ID сервера по дефолту в виде его IP, а сервер принимает всё. В случае с swanctl, сервер ожидает ID в виде DN его сертификата, что в чем-то более логично. swanctl-клиент также отправит ID сервера как DN серверного сертификата, полученного в результате предыдущего запроса.

Таким образом, если хочется оставить swanctl на сервере и ipsec.conf на клиенте (оригинальная задача), то достаточно на клиенте добавить rightid=»CN=1.2.3.4″ ( 1.2.3.4 – IP сервера). Или можно воспользоваться недокументированной особенностью и прописать local.id = %any на сервере. При использовании swanctl с обоих сторон специально прописывать local.id и remote.id не нужно.

Со своей стороны я решил использовать ipsec.conf с обоих сторон, т.к. swanctl выглядит гибче (мне это пока ненужно), но геморнее (например, убунтовый AppArmor по дефолту режет swanctl так, что он не загружает никаких соединений на старте системы, нужно руками делать —load-all ).

anc если вдруг интересно

Источник

Adblock
detector