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

Коды ошибок

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

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

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

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

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

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

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

Код ошибки

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

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

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

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

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

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

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

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

Читать также:  Почему OS X не доверяет SSL-сертификату GitHub?

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

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

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

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

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

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

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

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

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

0x80070040

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

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

0x800B0109

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

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

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

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

PPTP VPN Windows-Cisco 2921. Ошибка 778

Мозги кипят, нужна помощь коллективного разума. Имеем маршрутизатор Cisco 2921 в связке с IAS на Windows 2003. При попытке коннекта с помощью родного Windows-клиента, при использовании MS-CHAP v.2 получаю ошибку 778: it was not possible to verify the identity of server (невозможно проверить идентичность сервера). Если использовать РАР — все работает без проблем. Но это не есть правильно. На ХР — та же самая картина.

Читать также:  Компьютер не видит рутокен с сертификатом сбербанка

service timestamps debug datetime msec

service timestamps log datetime msec

logging buffered 51200 warnings

aaa authentication ppp default group radius local

aaa session-id common

multilink bundle-name authenticated

async-bootp dns-server 192.168.192.XX

! Default PPTP VPDN group

l2tp tunnel timeout no-session 15

ip address 192.168.207.1 255.255.255.0

description $ETH-LAN$$ETH-SW-LAUNCH$$INTF-INFO-GE 0/0$

ip address 192.168.192.XXX 255.255.255.0

ip address 192.168.192.XX 255.255.255.0 secondary

pppoe enable group global

ip unnumbered Loopback0

autodetect encapsulation ppp

peer default ip address pool PPP

ppp encrypt mppe auto required

ppp authentication ms-chap-v2

ip address negotiated

ppp authentication pap callin

ip local pool PPP 192.168.207.200 192.168.207.250

ip forward-protocol nd

ip nat inside source list NAT_ACL interface Dialer1 overload

ip nat inside source static tcp 192.168.192.XX 25 82.XXX.XXX.XXX 25 extendable

ip nat inside source static tcp 192.168.192.XX 1352 82.XXX.XXX.XXX 1352 extendable

ip route 0.0.0.0 0.0.0.0 Dialer1

ip access-list extended NAT_ACL

deny ip 192.168.192.0 0.0.0.255 192.168.YYY.0 0.0.0.255

permit tcp 192.168.192.0 0.0.0.255 any eq www

permit tcp 192.168.192.0 0.0.0.255 any eq 443

permit tcp 192.168.192.0 0.0.0.255 any eq 1352

permit tcp host 192.168.192.XX any eq smtp

permit tcp 192.168.192.0 0.0.0.255 any eq 22

permit tcp host 192.168.192.XX any eq domain

permit udp host 192.168.192.XX any eq domain

radius-server host 192.168.192.XX auth-port 1645 acct-port 1646

radius-server key IASKEY

scheduler allocate 20000 1000

Oct 21 14:47:51.755: ppp98 PPP: Phase is ESTABLISHING

Oct 21 14:47:51.755: ppp98 PPP: Using vpn set call direction

Oct 21 14:47:51.755: ppp98 PPP: Treating connection as a callin

Oct 21 14:47:53.759: ppp98 LCP: MRU 1464 (0x010405B8)

Oct 21 14:47:53.759: ppp98 LCP: AuthProto MS-CHAP-V2 (0x0305C22381)

Oct 21 14:47:53.759: ppp98 LCP: MagicNumber 0xF018D237 (0x0506F018D237)

Oct 21 14:47:54.351: ppp98 LCP: MRU 1400 (0x01040578)

Oct 21 14:47:54.351: ppp98 LCP: MagicNumber 0x2F7C5F7E (0x05062F7C5F7E)

Oct 21 14:47:54.351: ppp98 LCP: PFC (0x0702)

Oct 21 14:47:54.351: ppp98 LCP: ACFC (0x0802)

Oct 21 14:47:54.351: ppp98 LCP: MRU 1464 (0x010405B8)

Oct 21 14:47:54.751: ppp98 LCP: MRU 1464 (0x010405B8)

Oct 21 14:47:54.751: ppp98 LCP: AuthProto MS-CHAP-V2 (0x0305C22381)

Oct 21 14:47:54.751: ppp98 LCP: MagicNumber 0xF018D237 (0x0506F018D237)

Oct 21 14:47:54.915: ppp98 LCP: MRU 1400 (0x01040578)

Oct 21 14:47:54.915: ppp98 LCP: MagicNumber 0x2F7C5F7E (0x05062F7C5F7E)

Читать также:  Что можно купить в Подмосковье за сто тысяч рублей

Oct 21 14:47:54.915: ppp98 LCP: PFC (0x0702)

Oct 21 14:47:54.915: ppp98 LCP: ACFC (0x0802)

Oct 21 14:47:54.915: ppp98 LCP: MRU 1464 (0x010405B8)

Oct 21 14:47:55.275: ppp98 LCP: MRU 1464 (0x010405B8)

Oct 21 14:47:55.275: ppp98 LCP: MagicNumber 0x2F7C5F7E (0x05062F7C5F7E)

Oct 21 14:47:55.275: ppp98 LCP: PFC (0x0702)

Oct 21 14:47:55.275: ppp98 LCP: ACFC (0x0802)

Oct 21 14:47:55.295: ppp98 PPP: Phase is AUTHENTICATING, by this end

Oct 21 14:47:55.295: ppp98 MS-CHAP-V2: O CHALLENGE id 1 len 28 from «gw.izmv»

Oct 21 14:47:55.295: ppp98 LCP: State is Open

Oct 21 14:47:55.583: ppp98 PPP: Phase is FORWARDING, Attempting Forward

Oct 21 14:47:55.587: ppp98 PPP: Sent MSCHAP_V2 LOGIN Request

Oct 21 14:47:55.591: ppp98 PPP: Received LOGIN Response PASS

Oct 21 14:47:55.591: ppp98 PPP AUTHOR: Author Data NOT Available

Oct 21 14:47:55.591: ppp98 PPP: Phase is FORWARDING, Attempting Forward

Oct 21 14:47:55.595: Vi3: No MS_CHAP_V2 msg data

Oct 21 14:47:55.595: Vi3 PPP: Phase is UP

Oct 21 14:47:55.595: Vi3 IPCP: Address 192.168.207.1 (0x0306C0A8CF01)

Oct 21 14:47:55.595: Vi3 CCP: MS-PPC supported bits 0x01000060 (0x120601000060)

Oct 21 14:47:55.599: %LINK-3-UPDOWN: Interface Virtual-Access3, changed state to up

Oct 21 14:47:55.603: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access3, changed state to up

Oct 21 14:47:56.027: Vi3 LCP: (0x2F7C5F7E003CCD740000030A)

Oct 21 14:47:56.027: Vi3 PPP DISC: Required MPPE not negotiated

Oct 21 14:47:56.027: Vi3 PPP: Phase is TERMINATING

Oct 21 14:47:56.679: Vi3 PPP: Phase is DOWN

Oct 21 14:47:56.679: %LINK-3-UPDOWN: Interface Virtual-Access3, changed state to down

Oct 21 14:47:56.683: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access3, changed state to down

Устранение неполадок 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 может помочь определить источник проблемы.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *