Ошибка 13806 ike не удалось найти действительный сертификат компьютера windows 7

В данной статье описывается проблема, при algorithmin подписи Windows RT 8.1 Windows 8.1 или Windows Server 2012 R2 с помощью эллиптических кривых цифровой подписи алгоритм ECDSA. Неполадки в 2962409 накопительный пакет обновления или исправление 2961892, описанное в данной статье и необходимых компонентов.

Симптомы

Рассмотрим следующий сценарий:

• У центра сертификации (ЦС), соответствует стандартам Suite B (эллиптических кривых), и центр сертификации выдает сертификаты компьютеров для проверки подлинности протокола IP-безопасность (IPsec), используя в качестве алгоритма подписи ECDSA.

• У вас есть Windows RT 8.1, Windows 8.1 или компьютерах под управлением Windows Server 2012 R2, запросить сертификат IPSec из центра сертификации.

• Настроить Internet Key Exchange версии 2 (IKEv2) VPN на клиентском компьютере.

• Включите параметр Разрешить проверку подлинности сертификата компьютера для IKEv2на сервере.

В этом случае при попытке подключения к серверу с использованием VPN IKEv2 с клиентского компьютера, установить подключение не удастся, и появляется следующее сообщение об ошибке:

Ошибка 13806 — сервер не имеет установленного сертификата, который подходит для использования с IKEv2

Решение

Чтобы устранить эту проблему, установите накопительный пакет обновления 2962409 или установить исправление, описанное в данной статье.

Сведения об обновлении

Дополнительные сведения о том, как получить этот накопительный пакет обновления, щелкните следующий номер статьи базы знаний Майкрософт:

2962409 Windows RT 8.1, Windows 8.1 и Windows Server 2012 R2 накопительный пакет обновления: Июнь 2014 г

Сведения об исправлении

Существует исправление от корпорации Майкрософт. Однако данное исправление предназначено для устранения только проблемы, описанной в этой статье. Применяйте данное исправление только в тех системах, которые имеют данную проблему.

Если исправление доступно для скачивания, имеется раздел «Пакет исправлений доступен для скачивания» в верхней части этой статьи базы знаний. Если этого раздела нет, отправьте запрос в службу технической поддержки для получения исправления.

Примечание. Если наблюдаются другие проблемы или необходимо устранить неполадки, вам может понадобиться создать отдельный запрос на обслуживание. Стандартная оплата за поддержку будет взиматься только за дополнительные вопросы и проблемы, которые не соответствуют требованиям конкретного исправления. Полный список телефонов поддержки и обслуживания клиентов корпорации Майкрософт или создать отдельный запрос на обслуживание посетите следующий веб-узел корпорации Майкрософт:

http://support.microsoft.com/contactus/?ws=supportПримечание. В форме «Пакет исправлений доступен для скачивания» отображаются языки, для которых доступно исправление. Если нужный язык не отображается, значит исправление для данного языка отсутствует.

Предварительные условия

Это исправление необходимо сначала установить обновление 2919355 Windows RT 8.1, Windows 8.1 или Windows Server 2012 R2. Для получения дополнительных сведений щелкните следующий номер статьи базы знаний Майкрософт:

2919355 Windows RT 8.1, Windows 8.1 и Windows Server 2012 R2 накопительный пакет обновления: Июнь 2014 г

Сведения о реестре

Для использования исправления из этого пакета нет необходимости вносить изменения в реестр.

Необходимость перезагрузки

После установки исправления компьютер необходимо перезагрузить.

Сведения о замене исправлений

Это исправление не заменяет ранее выпущенные исправления.

Глобальная версия этого исправления устанавливает файлы с атрибутами, указанными в приведенных ниже таблицах. Дата и время для файлов указаны в формате UTC. Дата и время для файлов на локальном компьютере отображаются в местном времени с вашим текущим смещением летнего времени (DST). Кроме того, при выполнении определенных операций с файлами, даты и время могут изменяться.

Сведения о файле Windows 8.1 и Windows Server 2012 R2 и заметкиВажно. Windows Server 2012 R2 исправления и исправления Windows 8.1 включаются в тех же самых пакетов. Однако исправления на странице запроса исправлений перечислены под обеими операционными системами. Для получения пакета исправлений, который применяется к одной или обеих операционных систем, установите исправления, перечисленные в разделе «Windows 8.1/Windows Server 2012 R2» на странице. Всегда смотрите раздел «Информация в данной статье относится к следующим продуктам» статьи для определения фактических операционных систем, к которым применяется каждое исправление.

• Файлы, относящиеся к определенному продукту, этапу разработки (RTM, SPn) и направлению поддержки (LDR, GDR) можно определить по номерам версий, как показано в следующей таблице.

  Версия	Продукт	Контрольная точка	Направление поддержки
  6.3.960 0.17xxx	Windows 8.1 и Windows Server 2012 R2	RTM	GDR

• Файлы MANIFEST (.manifest) и MUM (.mum), устанавливаемые для каждой среды, указаны отдельно в разделе «Сведения о дополнительных файлах». MUM, MANIFEST и связанные файлы каталога безопасности (.cat) очень важны для поддержания состояния обновленных компонентов. Файлы каталога безопасности, для которых не перечислены атрибуты, подписаны цифровой подписью корпорации Майкрософт.

Для всех поддерживаемых 32-разрядных версий Windows 8.1

Имя файла	Версия файла	Размер файла	Дата	Время	Платформа
Vpnike.dll	6.3.9600.17111	323,072	30-Apr-2014	03:15	x86

Для всех поддерживаемых 64-разрядных версий Windows 8.1 и Windows Server 2012 R2

Имя файла	Версия файла	Размер файла	Дата	Время	Платформа
Vpnike.dll	6.3.9600.17111	403,968	30-Apr-2014	03:42	x64

Для Windows RT 8.1

Имя файла	Версия файла	Размер файла	Дата	Время	Платформа
Vpnike.dll	6.3.9600.17111	271,360	30-Apr-2014	02:39	Неприменимо

Статус

Корпорация Майкрософт подтверждает, что это проблема продуктов Майкрософт, перечисленных в разделе «Относится к».

Дополнительные сведения

Для получения дополнительных сведений о терминологии обновлений программного обеспечения щелкните следующий номер статьи базы знаний Майкрософт:

Описание 824684 Стандартные термины, используемые при описании обновлений программных продуктов Майкрософт.

Сведения о дополнительных файлах

Hello,

I’m trying to setup a VPN connection using the following settings:

• VPN Type: IKEv2
• Authentication: use machine certificate
• DHGroup: ECP256 or ECP384

When I try to connect this VPN, I get the following error: 

Connecting to vpn.contoso.org.
Verifying username and password…IKE failed to find valid machine certificate. Contact your Network Security Administrator about installing a valid certificate in the appropriate Certificate Store.

When I change the configuration to DHGroup ‘Group14’, the connection succeeds.

The error only occurs when using one of the ECPxxx DHGroups.

Below is the command output, which shows the working scenario + config update + failing scenario:

PS C:> Set-VpnConnectionIPsecConfiguration -ConnectionName vpn.contoso.org -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -DHGroup group14 -AuthenticationTransformConstants sha256 -CipherTransformConstants AES256 -PfsGroup PFS2048 -force -passthru

AuthenticationTransformConstants : SHA256128
CipherTransformConstants         : AES256
DHGroup                          : Group14
IntegrityCheckMethod             : SHA256
PfsGroup                         : PFS2048
EncryptionMethod                 : AES256

PS C:> rasdial vpn.contoso.org
Connecting to vpn.contoso.org...
Verifying username and password...
Registering your computer on the network...
Successfully connected to vpn.contoso.org.
Command completed successfully.

PS C:> rasdial vpn.contoso.org /disconnect
Command completed successfully.

PS C:> Set-VpnConnectionIPsecConfiguration -ConnectionName vpn.contoso.org -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -DHGroup ecp256 -AuthenticationTransformConstants sha256 -CipherTransformConstants AES256 -PfsGroup PFS2048 -force -passthru

AuthenticationTransformConstants : SHA256128
CipherTransformConstants         : AES256
DHGroup                          : ECP256
IntegrityCheckMethod             : SHA256
PfsGroup                         : PFS2048
EncryptionMethod                 : AES256

PS C:> rasdial vpn.contoso.org
Connecting to vpn.contoso.org...
Verifying username and password...IKE failed to find valid machine certificate. Contact your Network Security Administrator about installing a valid certificate in the appropriate Certificate Store.

The VPN server is configured to accept any of the following DHGroups: Group14, ECP256, ECP384.

When I attempt to connect using a different DHGroup, I get a completely different error:

PS C:> Set-VpnConnectionIPsecConfiguration -ConnectionName vpn.contoso.org -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -DHGroup group2 -AuthenticationTransformConstants sha256 -CipherTransformConstants AES256 -PfsGroup PFS2048 -force -passthru

AuthenticationTransformConstants : SHA256128
CipherTransformConstants         : AES256
DHGroup                          : Group2
IntegrityCheckMethod             : SHA256
PfsGroup                         : PFS2048
EncryptionMethod                 : AES256

PS C:> rasdial contoso.org
Connecting to vpn.contoso.org...
Verifying username and password...Policy match error

When I try to connect in with Group14, but have no certificate installed, I also get the ‘IKE failed to find valid machine certificate’ error.

It looks like the certificate requirements are different when using one of the ECPxxx DHGroups.

I tried deleting/recreating certificate, with different settings:

• client authentication
• client authentication + server authentication
• all key usages + all EKU’s

but I was unable to establish a connection.

I did found a document explaining certificate requirements for the server-side, but not for the client-side certificate.

Do you have any idea, on how to fix this?

Hello,

I’m trying to setup a VPN connection using the following settings:

• VPN Type: IKEv2
• Authentication: use machine certificate
• DHGroup: ECP256 or ECP384

When I try to connect this VPN, I get the following error: 

Connecting to vpn.contoso.org.
Verifying username and password…IKE failed to find valid machine certificate. Contact your Network Security Administrator about installing a valid certificate in the appropriate Certificate Store.

When I change the configuration to DHGroup ‘Group14’, the connection succeeds.

The error only occurs when using one of the ECPxxx DHGroups.

Below is the command output, which shows the working scenario + config update + failing scenario:

PS C:> Set-VpnConnectionIPsecConfiguration -ConnectionName vpn.contoso.org -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -DHGroup group14 -AuthenticationTransformConstants sha256 -CipherTransformConstants AES256 -PfsGroup PFS2048 -force -passthru

AuthenticationTransformConstants : SHA256128
CipherTransformConstants         : AES256
DHGroup                          : Group14
IntegrityCheckMethod             : SHA256
PfsGroup                         : PFS2048
EncryptionMethod                 : AES256

PS C:> rasdial vpn.contoso.org
Connecting to vpn.contoso.org...
Verifying username and password...
Registering your computer on the network...
Successfully connected to vpn.contoso.org.
Command completed successfully.

PS C:> rasdial vpn.contoso.org /disconnect
Command completed successfully.

PS C:> Set-VpnConnectionIPsecConfiguration -ConnectionName vpn.contoso.org -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -DHGroup ecp256 -AuthenticationTransformConstants sha256 -CipherTransformConstants AES256 -PfsGroup PFS2048 -force -passthru

AuthenticationTransformConstants : SHA256128
CipherTransformConstants         : AES256
DHGroup                          : ECP256
IntegrityCheckMethod             : SHA256
PfsGroup                         : PFS2048
EncryptionMethod                 : AES256

PS C:> rasdial vpn.contoso.org
Connecting to vpn.contoso.org...
Verifying username and password...IKE failed to find valid machine certificate. Contact your Network Security Administrator about installing a valid certificate in the appropriate Certificate Store.

The VPN server is configured to accept any of the following DHGroups: Group14, ECP256, ECP384.

When I attempt to connect using a different DHGroup, I get a completely different error:

PS C:> Set-VpnConnectionIPsecConfiguration -ConnectionName vpn.contoso.org -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -DHGroup group2 -AuthenticationTransformConstants sha256 -CipherTransformConstants AES256 -PfsGroup PFS2048 -force -passthru

AuthenticationTransformConstants : SHA256128
CipherTransformConstants         : AES256
DHGroup                          : Group2
IntegrityCheckMethod             : SHA256
PfsGroup                         : PFS2048
EncryptionMethod                 : AES256

PS C:> rasdial contoso.org
Connecting to vpn.contoso.org...
Verifying username and password...Policy match error

When I try to connect in with Group14, but have no certificate installed, I also get the ‘IKE failed to find valid machine certificate’ error.

It looks like the certificate requirements are different when using one of the ECPxxx DHGroups.

I tried deleting/recreating certificate, with different settings:

• client authentication
• client authentication + server authentication
• all key usages + all EKU’s

but I was unable to establish a connection.

I did found a document explaining certificate requirements for the server-side, but not for the client-side certificate.

Do you have any idea, on how to fix this?

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

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

Ошибка VPN 13801 в Windows 10

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Устранение неполадок Always On VPN

применимо к: Windows server 2022, Windows server 2019, Windows Server 2016, Windows Server 2012 R2, Windows 10

Если Always On установки VPN не удается подключить клиентов к внутренней сети, причиной является недопустимый сертификат VPN, неправильные политики NPS или проблемы с сценариями развертывания клиента или маршрутизацией и удаленным доступом. Первым шагом в устранении неполадок и тестировании VPN-подключения является понимание основных компонентов инфраструктуры VPN Always On.

Устранить проблемы с подключением можно несколькими способами. Для проблем на стороне клиента и общего устранения неполадок приложение регистрируется на клиентских компьютерах. Для проблем, связанных с проверкой подлинности, журнал NPS на сервере NPS может помочь определить источник проблемы.

Коды ошибок

Код ошибки: 800

Описание ошибки. «Удаленное подключение не удалось установить из-за сбоя использованных VPN-туннелей. VPN-сервер может быть недоступен. Если это подключение пытается использовать туннель L2TP/IPsec, параметры безопасности, необходимые для согласования IPsec, могут быть настроены неправильно.

Возможная причина. Эта ошибка возникает, если VPN-туннель имеет тип Авто и попытка подключения завершается неудачно для всех VPN-туннелей.

Возможные решения:

Если вы понимаете, какой туннель использовать для развертывания, задайте тип VPN на стороне VPN-клиента для этого типа туннеля.

При установлении VPN-подключения с определенным типом туннеля подключение по-прежнему будет завершаться сбоем, но это приведет к появлению дополнительной ошибки, относящейся к туннелю (например, «GRE заблокирован для PPTP»).

Эта ошибка также возникает, когда не удается подключиться к VPN-серверу или не удается установить туннельное подключение.

Проверьте следующее.

Порты IKE (UDP-порты 500 и 4500) не блокируются.

Правильные сертификаты для IKE существуют как на клиенте, так и на сервере.

Код ошибки: 809

Описание ошибки. Не удалось установить сетевое подключение между компьютером и VPN-сервером, так как удаленный сервер не отвечает. Это может быть вызвано тем, что одно из сетевых устройств (например, брандмауэры, NAT, маршрутизаторы) между компьютером и удаленным сервером не настроено для разрешения VPN-подключений. Обратитесь к администратору или поставщику услуг, чтобы определить, какое устройство может быть причиной проблемы.

Возможная причина. Эта ошибка вызвана блокированием портов UDP 500 или 4500 на VPN-сервере или брандмауэре.

Возможное решение. Убедитесь, что UDP-порты 500 и 4500 разрешены через все брандмауэры между клиентом и сервером RRAS.

Код ошибки: 812

Описание ошибки. Не удается подключиться к Always On VPN. Подключение не выполнено из-за политики, заданной на вашем RAS/VPN сервере. В частности, метод проверки подлинности, используемый сервером для проверки имени пользователя и пароля, может не соответствовать методу проверки подлинности, настроенному в профиле подключения. Обратитесь к администратору сервера RAS и сообщите ему об этой ошибке.

Возможные причины:

Типичная причина этой ошибки заключается в том, что NPS указал условие проверки подлинности, которое клиент не может удовлетворить. Например, NPS может указать использование сертификата для защиты подключения PEAP, но клиент пытается использовать EAP-MSCHAPv2.

Журнал событий 20276 регистрируется в средстве просмотра событий, если параметр протокола проверки подлинности VPN-сервера на основе RRAS не соответствует компьютеру VPN-клиента.

Возможное решение. Убедитесь, что конфигурация клиента соответствует условиям, указанным на сервере NPS.

Код ошибки: 13806

Описание ошибки. IKE не удалось найти действительный сертификат компьютера. Обратитесь к администратору безопасности сети, чтобы установить действительный сертификат в соответствующем хранилище сертификатов.

Возможная причина. Эта ошибка обычно возникает, когда на VPN-сервере отсутствует сертификат компьютера или сертификат корневого компьютера.

Возможное решение. Убедитесь, что сертификаты, указанные в этом развертывании, установлены как на клиентском компьютере, так и на VPN-сервере.

Код ошибки: 13801

Описание ошибки. Учетные данные проверки подлинности IKE недопустимы.

Возможные причины. Эта ошибка обычно возникает в одном из следующих случаев.

Сертификат компьютера, используемый для проверки IKEv2 на сервере RAS, не имеет проверки подлинности сервера в разделе » Расширенное использование ключа«.

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

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

Имя VPN-сервера, используемое на клиентском компьютере, не соответствует SubjectName сертификата сервера.

Возможное решение. Убедитесь, что сертификат сервера включает проверку подлинности сервера в разделе Расширенное использование ключа. Убедитесь, что сертификат сервера все еще действителен. Убедитесь, что используемый центр сертификации указан в списке Доверенные корневые центры сертификации на сервере RRAS. Убедитесь, что VPN-клиент подключается с помощью полного доменного имени VPN-сервера, представленного в сертификате VPN-сервера.

Код ошибки: 0x80070040

Описание ошибки. В сертификате сервера не используется Проверка подлинности сервера в качестве одной из записей использования сертификатов.

Возможная причина. Эта ошибка может возникать, если на сервере удаленного доступа не установлен сертификат проверки подлинности сервера.

Код ошибки: 0x800B0109

Как правило, компьютер VPN-клиента присоединяется к домену на основе Active Directory. Если для входа на VPN-сервер используются учетные данные домена, сертификат автоматически устанавливается в хранилище Доверенные корневые центры сертификации. Однако если компьютер не присоединен к домену или используется другая цепочка сертификатов, может возникнуть эта проблема.

Описание ошибки. Цепочка сертификатов обработана, но была прервана в корневом сертификате, которому не доверяет поставщик доверия.

Возможная причина. Эта ошибка может возникать, если соответствующий доверенный корневой сертификат ЦС не установлен в хранилище доверенных корневых центров сертификации на клиентском компьютере.

Возможное решение. Убедитесь, что корневой сертификат установлен на клиентском компьютере в хранилище доверенных корневых центров сертификации.

Журналы

Журналы приложений

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

Найдите события из источника Расклиент. Все сообщения об ошибках возвращают код ошибки в конце сообщения. Ниже описаны некоторые из наиболее распространенных кодов ошибок, но полный список доступен в кодах ошибок маршрутизации и удаленного доступа.

Журналы NPS

NPS создает и сохраняет журналы учета NPS. По умолчанию они хранятся в файлах% SYSTEMROOT% system32 в файле с именем в XXXX.txt, где XXXX — это Дата создания файла.

По умолчанию эти журналы находятся в формате значений с разделителями-запятыми, но не содержат строки заголовка. Строка заголовка:

если вставить эту строку заголовка в качестве первой строки файла журнала, а затем импортировать файл в Microsoft Excel, столбцы будут помечены правильно.

Журналы NPS могут быть полезны при диагностике проблем, связанных с политиками. Дополнительные сведения о журналах NPS см. в разделе Интерпретация файлов журнала в формате базы данных NPS.

Проблемы в работе скрипта VPN_Profile.ps1

Наиболее распространенные проблемы, возникающие при ручном запуске Profile.ps1 сценария VPN_ включают:

Используется ли средство удаленного подключения? Не следует использовать RDP или другой метод удаленного подключения, так как он перепутать с обнаружением входа пользователя.

Является ли пользователь администратором этого локального компьютера? Убедитесь, что при выполнении сценария VPN_Profile.ps1, у которого у пользователя есть права администратора.

Включены ли дополнительные функции безопасности PowerShell? Убедитесь, что политика выполнения PowerShell не блокирует скрипт. Перед выполнением скрипта можно отключить ограниченный языковой режим, если он включен. Вы можете активировать ограниченный языковой режим после успешного завершения сценария.

Проблемы с подключением клиента Always On VPN

Небольшая неудачная настройка может привести к сбою клиентского подключения, что может быть трудно обнаружить причину. Перед установкой соединения Always On VPN-клиент проходит несколько шагов. При устранении неполадок с подключением клиентов пройдите процесс исключения следующим образом:

Подключен ли шаблон к внешнему компьютеру? При сканировании вхатисмип должен отображаться общедоступный IP-адрес, который не принадлежит вам.

Можно ли разрешить имя сервера удаленного доступа или VPN-адреса в адрес? В окне «Сетевые подключения» панели управления > > откройте свойства профиля VPN. Значение на вкладке Общие должно быть открыто разрешимым с помощью DNS.

Можно ли получить доступ к VPN-серверу из внешней сети? Попробуйте открыть внешний интерфейс с помощью протокола ICMP и проверить связь с именем удаленного клиента. После успешной проверки связи можно удалить правило Allow ICMP.

Правильно ли настроены внутренние и внешние сетевые адаптеры на VPN-сервере? Они находятся в разных подсетях? Подключение внешнего сетевого адаптера к правильному интерфейсу в брандмауэре?

Открыты ли порты UDP 500 и 4500 от клиента к внешнему интерфейсу VPN-сервера? Проверьте брандмауэр клиента, брандмауэр сервера и все аппаратные брандмауэры. IPSEC использует UDP-порт 500, поэтому убедитесь, что ИПЕК отключены или не заблокированы в любом месте.

Вы подключаетесь, но у вас нет доступа к Интернету или локальной сети? Проверьте пулы IP-адресов серверов DHCP и VPN на наличие проблем с конфигурацией.

Вы подключаетесь и имеете действительный внутренний IP-адрес, но не имеете доступа к локальным ресурсам? Убедитесь, что клиенты узнают, как получить эти ресурсы. Для маршрутизации запросов можно использовать VPN-сервер.

Проблемы подключения при использовании условного доступа Azure AD

Ой! вы еще не можете получить доступ к этому

Возможная причина

У пользователя есть допустимый сертификат проверки подлинности клиента в хранилище личных сертификатов, который не был выдан Azure AD.

Возможное решение. Для экранирования этого цикла выполните следующие действия.

Убедитесь, что разделы, и содержат правильное имя и идентификатор объекта.

Чтобы определить наличие допустимых сертификатов в хранилище сертификатов пользователя, выполните команду certutil :

Если в личном хранилище пользователя существует допустимый сертификат проверки подлинности клиента, соединение не будет выполнено (как должно) после выбора пользователем X и существования разделов, и и содержащих правильные данные.

Появляется сообщение об ошибке «не удалось найти сертификат, который может использоваться с протоколом расширяемого протокола проверки подлинности».

Не удалось удалить сертификат из колонки VPN-подключения

Описание ошибки. Не удается удалить сертификаты в колонке VPN-подключения.

Возможная причина. Для сертификата задан первичный сертификат.

Возможное решение.

Источник

Настройка VPN-сервера IKEv2 на MikroTik

Доброго времени суток, коллеги. Сегодня пишу заметку по настройке VPN-сервер IKEv2 на MikroTik. По окончании настройки к нему смогут подключиться клиенты с Windows, Android, Apple а также получим рабочий туннель для объединения 2-х офисов по схеме Site 2 Site в ситуации, когда белый IP-адрес лишь у одного микрота (сервера) либо когда он пингуется по DNS-имени. Авторизовываться будем по сертификатам, которые сгенерируем на Site-1.

Я ни в коем случае не претендую на звание ГУРУ. То, что я здесь излагаю является не более, чем записной книжкой и пособием по настройке оборудования. Если это послужит кому-нибудь подспорьем, то добро пожаловать

В создании данной статьи я руководствовался официальной документацией и выступлениями Никиты Тарикина в Малазии, Москве и Индонезии, за которые огромное ему СПАСИБО!

После написания 3-х предыдущих заметок вся настройка будет происходит в терминале с минимумом комментариев и картинок.

1. Настройка VPN-сервера (Site-1)

Настраиваем часовой пояс, NTP-клиента.

Добавляем бридж и вешаем пул адресов на него же

Настройку DNS вам нужно провести самостоятельно в зависимости от вашей специфики, но в итоге нам нужно, чтобы по адресу vpn.dnsname.ru пинговался IP-адрес настраиваемого VPN-сервера 66.66.66.66.

Генерируем корневой сертификат:

Генерируем сертификат VPN-сервера:

Создаём шаблон для дальнейшего создания сертификатов через копирование с шаблона:

Сертификат для схемы Site 2 Site (для микротика Site-2):

Для первого клиента:

Для второго клиента, а остальные по той же схеме:

Далее экспортируем сгенерированные ключи, но обратите внимание, что сертификаты экспортируются в разных форматах (pem и pkcs12). Обязательно установите пароль при экспорте, т.к. при его отсутствии ошибок не будет, но работать VPN тоже не будет. Ни в коем случае не экспортируйте CA-сертификат с паролем, т.к. тогда экспортируется и закрытый ключ.

Скачиваем экспортированные сертификаты и сохраняем в одну папку. Я еще и переименовал скаченные сертификаты для удобства, удалив начало cert_export_.

Чуть настроим FireWall и изменим MSS. Правила размещайте перед запрещающими. Я расположу их в самом начале списка (place-before=0)

Добавим правила NAT и поместим их над правилом основного маскарада:

Настраиваем параметры IPSec. Настройка едина как для конфигурации Client 2 Site, так и для Site 2 Site:

Сразу добавим GRE-туннель, который в дальнейшем позволит нам легко настроить маршрутизацию между офисами:

На этом настройку VPN-сервера можно считать законченной и пора переходить на сторону клиента.

2. Настройка клиента Windows.

Первым на очереди комп с установленной Windows 10 Pro x64 версия 1903.
В винде кликаем правой кнопкой мыши на значок сетевого подключения и выбираем пункт ОТКРЫТЬ ПАРАМЕТРЫ СЕТИ И ИНТЕРНЕТ.

Слева выбираем раздел VPN и справа ДОБАВИТЬ VPN ПОДКЛЮЧЕНИЕ:

Импортируем сертификат:
Расположение хранилища: Локальный компьютер
Пароль на сертификат: который вы выбрали при экспорте сертификата
Далее все по умолчанию

В случае если вам не нужно выходить в интернет через шлюз подключенной через VPN сети, то выбираем вкладку СЕТЬ, двойной левый клик на IP версии 4, в открытом окне ДОПОЛНИТЕЛЬНО и далее во вкладке ПАРАМЕТРЫ IP и снимаем галку ИСПОЛЬЗОВАТЬ ОСНОВНОЙ ШЛЮЗ В УДАЛЕННОЙ СЕТИ.

3. Настройка MikroTik по схеме Site 2 Site (Site-2).

Настраиваем часовой пояс, NTP-клиента.

и импортируем их по порядку. Обратите внимание, что импортировать нужно сначала CRT, а затем KEY.

Настроим FireWall, параметры IPsec, добавим GRE-туннель и добавим маршрут в сеть Site-1:

Если вы всё сделали по инструкции, то на данном этапе туннель должен заработать! Если же это не так, то попробуйте отключить запрещающие правила на FireWall на обоих маршрутизаторах.

Для настройки клиента на устройствах под управлением Android и и продуктов фирмы Apple предлагаю проследовать на сайт официальной документации, дублировать которую просто не вижу смысла.

Нюансы Windows 10

Небольшое дополнение: При подключении с ПК под управлением Windows (в моем случае Windows10 x64 1903) к разным микротам VPN-подключение непонятным образом выбирает CA-сертификат. Решение подсказали на форуме и состоит оно в принудительном указании соответствия сертификата подключению, используя powerShell.

Также случается, что на винде не получается автоматически маршрут к удаленной сети. Эта проблема также решается через powerShell добавлением маршрута после подключения определенного VPN.

Нюансы Windows 7

Настройка VPN-подключения в Windows 7 ничем не отличается от Windows 10 кроме процесса импорта сертификатов в хранилище.
Итак: нажимаете Windows + R и в строке пишем mmc и нажимаем Enter.

В следующем окне нужно выбрать учетной записи компьютера

Перед нами откроется окно и здесь уже нужно импортировать сертификаты.

После импорта настоятельно рекомендую проверить, чтобы клиентский серт был в личном, а СА в доверенных.

Надеюсь, что у вас всё получилось.
Если же нет, то добро пожаловать в раздел КОНТАКТЫ

Источник

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

Настраиваем IKEv2 VPN-сервер на роутерах Mikrotik с аутентификацией по сертификатам

Сейчас, когда многие настраивают VPN для работы удаленных сотрудников, выбор протокола становится как никогда актуальным. С одной стороны стоят поддерживаемые современными ОС протоколы PPTP и L2TP, которые имеют ряд существенных недостатков и ограничений, с другой OpenVPN, который всем хорош, но требует установки стороннего ПО. При этом как-то забывают о быстром и безопасном IKEv2, основанном на IPsec новом протоколе, также поддерживаемом всеми современными ОС.

Почему именно IKEv2? Данный протокол входит в группу протоколов IPsec и обеспечивает высокий уровень безопасности, включая аутентификацию клиента с использованием сертификата, а также проверку подлинности сервера клиентом, что исключает атаки типа «человек посередине». При поддержке аппаратного ускорения IPsec со стороны оборудования показывает хорошую скорость соединения относительно других типов VPN в RouterOS и весьма прост в настройке с клиентской стороны, не требует добавления маршрутов.

К недостаткам можно отнести достаточную сложность настройки серверной части, которая требует выполнения определенных условий и наличия базового объема знаний о работе IPsec. В данной статье мы не будем углубляться в теорию, сделав упор на практическую сторону вопроса, ограничившись краткими пояснениями необходимости тех или иных настроек.

Создание центра сертификации и выпуск сертификатов

Выделенный зеленым блок не является обязательным, но мы советуем его заполнять, дабы в дальнейшем не пришлось угадывать, что это за сертификат и кому и кем он выдан.

Затем перейдем на закладку Key Usage и оставим только crl sign и key cert. sign, затем нажмем Apply, чтобы применить изменения, после чего подпишем сертификат. нажав кнопку Sign, в открывшемся окне укажем CA CRL Host, в качестве которого следует использовать один из IP-адресов роутера.

В терминале эти же действия можно выполнить командой:

Следующим шагом выпустим сертификат сервера. Обратите внимание, что сервер обязательно должен иметь выделенный IP адрес и, желательно, доменное имя. Последнее условие не является обязательным, но предпочтительно, так как позволит отвязаться от использования адреса и в случае изменения IP вам не придется перевыпускать сертификаты и менять настройки клиентских подключений.

Заполнение полей в целом повторяет предыдущий пример, за исключением Common Name и Subject Alt. Name. Здесь мы указываем IP-адрес или FQDN по которому клиенты будут подключаться к серверу. Если вы используете IP-адрес, то тип записи в поле Subject Alt. Name нужно сменить на IP.

Обратите внимание, если вы выпустили сертификат с указанием FQDN, а подключить клиента попытаетесь по IP-адресу, либо наоборот, то такое соединение окажется невозможным.

На закладке Key Usage укажем единственное значение tls server и подпишем наш сертификат закрытым ключом центра сертификации CA.

Эти же действия в терминале:

Теперь можно выпускать клиентские сертификаты, это можно сделать как сразу, так и потом. Никаких особых требований здесь нет, в качестве имени указывайте максимально понятное значение, скажем, ФИО сотрудника или наименование офиса. Потому как понять кому принадлежит сертификат с CN IvanovIA не составит особого труда, в отличие от какого-нибудь безликого client3. Также обратите внимание на опцию Days Valid, не следует выдавать клиентские сертификаты на большой срок.

Команды для терминала:

Для использования на клиентских устройствах сертификаты следует экспортировать, наиболее удобно использовать для этого формат PKCS12, который в одном файле содержит закрытый ключ клиента, его сертификат и корневой сертификат CA. Для этого выберите сертификат в списке и в меню правой кнопки мыши укажите действие Export. В поле Type укажите PKCS12, а в Export Passphrase следует указать пароль (не менее 8 символов), в противном случае закрытый ключ выгружен не будет.

Это же можно сделать командой:

Скачать экспортированные сертификаты можно из раздела Files.

Настройка IKEv2 VPN-сервера

Здесь мы вступаем в достаточно сложную область настройки IPsec, объем статьи не позволяет подробно останавливаться на назначении каждой настройки, поэтому если вы не уверены в своих действиях, то мы не рекомендуем отклоняться от указанных ниже настроек.

Либо выполните команду в терминале:

Параметры по умолчанию нам не подойдут, поэтому в блоке Encr. Algorithms убираем 3des и добавляем aes-128-cbc, aes-192-cbc, aes-256-cbc.

В терминале достаточно простой команды:

Здесь мы сталкиваемся с одной особенностью: создаваемые через терминал и Winbox предложения содержат различный набор параметров. То, что создается в терминале полностью соответствует приведенным выше на скриншоте требованиям.

Это же действие в терминале:

Если же вам нужно, чтобы клиенты использовали внутренние сервера имен, например, в Active Directory, то флаг System DNS также следует снять и указать адреса требуемых DNS-серверов.

Команда для терминала будет выглядеть так:

На закладке Groups создадим новую группу, никаких настроек здесь нет, просто укажите уникальное имя:

Затем на закладке Policices создадим шаблон политики, которая будет указывать какой именно трафик будет подвергаться обработке IPsec и отправляться в туннель. В поле Src. Address оставляем 0.0.0.0/0, в поле Dst. Address указываем выделенный для VPN-сети диапазон: 10.20.0.0/24, устанавливаем флаг Template и указываем созданную нами ранее группу в поле Group.

На закладке Action в поле Proposal укажите созданный нами ранее набор предложений.

Эти же действия в терминале:

В терминале для получения аналогичного результата выполните:

Команда для терминала:

Для добавления правила в терминале:

Оба правила следует расположить выше, чем запрещающие в каждой из цепочек.

Настройка подключения клиента в Windows

Прежде всего импортируем сертификат, для этого можно просто выполнить двойной клик на файле сертификата, в открывшемся Мастере импорта в качестве Расположения хранилища укажите Локальный компьютер, остальные параметры принимаются по умолчанию.

После чего откроем свойства созданного подключения и перейдем на закладку Безопасность, где установим переключатель Проверка подлинности в положение Использовать сертификаты компьютеров.

Как видим, маршрут к нашей внутренней сети 192.168.111.0/24 был добавлен автоматически и никаких ручных настроек клиента не требуется.

Настройка подключения клиента в Linux

Точно также начнем с сертификата, но в данном случае нам потребуется немного больше действий. Будем считать, что сертификат находится в корневой директории пользователя, для которого мы настраиваем подключение. Все последующие команды также следует выполнять от его имени.

Перейдем в домашнюю директорию и создадим скрытую папку для хранения ключей и сертификатов:

Теперь нам нужно экспортировать из PKCS12 файла корневой сертификат CA, а также ключ и сертификат пользователя. Начнем с корневого сертификата:

Затем экспортируем сертификат клиента:

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

На каждом из этих этапов нам нужно будет вводить парольную фразу, указанную при экспорте сертификата пользователя на роутере.

И наконец уберем пароль с закрытого ключа пользователя:

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

Для того, чтобы иметь возможность создавать VPN-подключения в графическом интерфейсе установим необходимый плагин для Network Manager:

После чего вам станут доступны настройки VPN IKEv2 соединения.

Настройки соединения достаточно просты. В секции Gateway указываем адрес сервера и путь к корневому сертификату CA. В секции Client устанавливаем Authentication: Certificate/private key и указываем пути к сертификату и закрытому ключу клиента. И в секции Option обязательно устанавливаем флаг Request an inner IP address. На этом настройка соединения окончена, можно подключаться.

Если мы после подключения проверим таблицу маршрутизации, то не обнаружим маршрута к офисной сети, но при этом она будет доступна:

Но никакой ошибки здесь нет. Просто Linux в данной ситуации поступает более правильно, вместо маршрута в системе создается соответствующая политика IPsec, которая направляет трафик к внутренней сети в туннель согласно тому, что мы указали в конфигурации клиента (Mode Configs) на роутере.

Дополнительные материалы:

Mikrotik

The Dude

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал:

Источник