Коды ошибок
Описание ошибки. «Удаленное подключение не удалось установить из-за сбоя использованных 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 не удалось найти действительный сертификат компьютера. Обратитесь к администратору безопасности сети, чтобы установить действительный сертификат в соответствующем хранилище сертификатов.
Возможная причина. Эта ошибка обычно возникает, когда на 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 может помочь определить источник проблемы.