strongSwan IKEv2 + Windows 7 Agile VPN: что вызывает ошибку 13801


8

У меня есть экземпляр AWS, который я хочу стать сервером VPN. Он подключит клиентов Windows 7 к частной сети в облаке Amazon.

  • Я установил Ubuntu 12.04 и strongswan-ikev2пакет.
  • ipsec version отчеты Linux strongSwan U4.5.2/K3.2.0-52-virtual
  • Обратите внимание, что и клиент, и сервер находятся за NAT (клиент, потому что он находится в локальной офисной сети, и сервер, потому что он находится в облаке Amazon). У меня разблокированы UDP-порты 500 и 4500 на приборной панели Amazon и брандмауэре клиента.
  • Это /etc/ipsec.conf:

    config setup
        plutostart=no
    
    conn %default
        keyexchange=ikev2
        ike=aes256-sha1-modp1024!
        esp=aes256-sha1!
        dpdaction=clear
        dpddelay=300s
        rekey=no
    
    conn win7vpn
        left=%any
        leftsubnet=<amazon VPC CIDR block>
        leftauth=pubkey
        leftcert=openssl-cert.pem
        leftid=<vpn server public dns name>
        right=%any
        rightsourceip=<amazon private IP address, which elastic ip is forwarded to>
        rightauth=eap-mschapv2
        rightsendcert=never
        eap_identity=%any
        auto=add
    
  • Это /etc/ipsec.secrets:

    : RSA openssl-key.rsa
    TESTDOMAIN\testuser : EAP "testpassword"
    
  • Я добавил сертификат CA, который подписал сертификат хоста сервера, в хранилище сертификатов локального компьютера (не пользователя), чтобы Windows могла аутентифицировать сервер.

Затем я пытаюсь подключиться к серверу, используя клиент Windows 7, как указано здесь , за одним исключением - я использую DNS-имя, а не IP-адрес. Я ввожу имя пользователя, домен и пароль в мой файл ipsec.secrets, и он пытается подключиться.

Когда это происходит, я получаю логи strongSwan, которые выглядят так. Я использовал их немного для цензуры и ясности; CLIENTPUB / CLIENTPRIV - это общедоступные и частные IP-адреса клиента, а AMAZONPRIV - это частный IP-адрес сервера (это то, что общедоступный IP-адрес сервера - Amazon называет это «Эластичный IP-адрес» - переадресация).

Sep  4 00:16:17 localhost charon: 14[IKE] CLIENTPUB is initiating an IKE_SA
Sep  4 00:16:17 localhost charon: 14[NET] received packet: from CLIENTPUB[500] to AMAZONPRIV[500]
Sep  4 00:16:17 localhost charon: 14[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
Sep  4 00:16:17 localhost charon: 14[IKE] CLIENTPUB is initiating an IKE_SA
Sep  4 00:16:17 localhost charon: 14[IKE] local host is behind NAT, sending keep alives
Sep  4 00:16:17 localhost charon: 14[IKE] remote host is behind NAT
Sep  4 00:16:17 localhost charon: 14[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(MULT_AUTH) ]
Sep  4 00:16:17 localhost charon: 14[NET] sending packet: from AMAZONPRIV[500] to CLIENTPUB[500]
Sep  4 00:16:17 localhost charon: 15[NET] received packet: from CLIENTPUB[4500] to AMAZONPRIV[4500]
Sep  4 00:16:17 localhost charon: 15[ENC] unknown attribute type INTERNAL_IP4_SERVER
Sep  4 00:16:17 localhost charon: 15[ENC] parsed IKE_AUTH request 1 [ IDi CERTREQ N(MOBIKE_SUP) CP(ADDR DNS NBNS SRV) SA TSi TSr ]
Sep  4 00:16:17 localhost charon: 15[IKE] received cert request for "C=US, ST=TX, O=Test CA, CN=Test CA"
Sep  4 00:16:17 localhost charon: 15[IKE] received 316 cert requests for an unknown ca
Sep  4 00:16:17 localhost charon: 15[CFG] looking for peer configs matching AMAZONPRIV[%any]...CLIENTPUB[CLIENTPRIV]
Sep  4 00:16:17 localhost charon: 15[CFG] selected peer config 'dlpvpn'
Sep  4 00:16:17 localhost charon: 15[IKE] initiating EAP-Identity request
Sep  4 00:16:17 localhost charon: 15[IKE] peer supports MOBIKE
Sep  4 00:16:17 localhost charon: 15[IKE] authentication of 'C=US, ST=TX, O=DLP Test CA, CN=vpn.example.com' (myself) with RSA signature successful
Sep  4 00:16:17 localhost charon: 15[IKE] sending end entity cert "C=US, ST=TX, O=DLP Test CA, CN=vpn.example.com"
Sep  4 00:16:17 localhost charon: 15[ENC] generating IKE_AUTH response 1 [ IDr CERT AUTH EAP/REQ/ID ]
Sep  4 00:16:17 localhost charon: 15[NET] sending packet: from AMAZONPRIV[4500] to CLIENTPUB[4500]

В этот момент в Windows сразу появляется сообщение об ошибке:

Verifying user name and password...
Error 13801: IKE authentication credentials are unacceptable

Через несколько секунд Харон пытается снова, а затем закрывает соединение.

Sep  4 00:16:37 localhost charon: 16[IKE] sending keep alive
Sep  4 00:16:37 localhost charon: 16[NET] sending packet: from AMAZONPRIV[4500] to CLIENTPUB[4500]
Sep  4 00:16:47 localhost charon: 03[JOB] deleting half open IKE_SA after timeout

И это все.

Насколько я могу судить, я следую всем инструкциям на вики-сайте strongSwan.

Что я здесь не так делаю?

Изменить: это определенно проблема с сертификатами. Я отключил расширенные проверки проверки, отредактировав реестр и перезагрузившись, как описано в MSKB926182 (лол, если вы хотели ссылку на это), и теперь я могу подключиться к своему VPN-серверу без ошибок. Я выясню, как создавать сертификаты, которые удовлетворяют требованиям, и добавлю ответ. Спасибо @ecdsa за указатель на страницу сертификата на вики-сайте strongSwan, которая указала мне правильное направление.


Как выглядит вкладка безопасности свойств VPN на клиенте Windows 7? Кроме того, хотя мои настройки не идентичны, IKEv2 работает с сертификатами в хранилище сертификатов текущего пользователя.
0xFE

Соответствует ли ваш сертификат сервера всем требованиям ?
Ecdsa

Если вы решили свою проблему, рассмотрите возможность размещения ответа ниже и отметьте его как решенный.
Майкл Хэмптон

Ответы:


6

Понял это. @ecdsa указал мне верное направление, и я наконец смог решить проблему, следуя этому руководству .

ipsec pki --gen --type rsa --size 4096 --outform pem > vpnca.key.pem
ipsec pki --self --flag serverAuth --in vpnca.key.pem --type rsa --digest sha1 \
    --dn "C=US, O=Example Company, CN=Example VPN CA" --ca > vpnca.crt.der
ipsec pki --gen --type rsa --size 4096 --outform pem > vpn.example.com.key.pem
ipsec pki --pub --in vpn.example.com.key.pem --type rsa > vpn.example.com.csr
ipsec pki --issue --cacert vpnca.crt.der --cakey vpnca.key.pem --digest sha1 \
    --dn "C=US, O=Example Company, CN=vpn.example.com" \
    --san "vpn.example.com" --flag serverAuth --outform pem \
    < vpn.example.com.csr > vpn.example.com.crt.pem 
openssl rsa -in vpn.example.com.key.pem -out vpn.example.com.key.der -outform DER

cp vpnca.crt.der /etc/ipsec.d/cacerts
cp vpn.example.com.crt.pem /etc/ipsec.d/certs
cp vpn.example.com.key.der /etc/ipsec.d/private

Об ошибке

Сообщение об ошибке было «Ошибка 13801: учетные данные аутентификации IKE недопустимы», что звучало так, будто мои учетные данные не работали. Однако это сообщение об аутентификации сервера , которое выполняется (согласно моей конфигурации) SSL-сертификатом сервера. Microsoft опубликовала документацию по устранению неполадок VPN-подключений IKEv2, в которой перечислены возможные причины этой ошибки:

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

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

Чтобы устранить эту проблему, вы можете отключить проверку EKU на своем клиенте Windows (конечно, это должно быть сделано только для тестирования):

  • запуск regedit
  • Перейдите к HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\RasMan\Parameters
  • Добавьте вызываемый DWORD DisableIKENameEkuCheckи установите его значение1
  • Документация Microsoft инструктирует вас перезагрузиться после этого, но мне не нужно было, чтобы это вступило в силу.

Другая возможная причина: IP используется в сертификате, но имя хоста используется на клиенте.
Ларсен

или имя хоста есть в сертификате, но клиент подключается к своему IP-адресу. Решение:ipsec pki --isue ... --san @ipaddress
Bouke

После выполнения этих шагов, в конечном итоге моя проблема заключалась в том, что доверенный корень был установлен не в том месте, он должен находиться в папке «Компьютер \ Доверенные корневые центры сертификации», а не в «Текущий пользователь \ TRCA».
Bouke

2

У меня была идентичная проблема, и я решил ее, обеспечив цепочку сертификатов в файле сертификатов (сертификат конечного объекта, промежуточный CA, корневой CA - в этом порядке). TLS это весело.

После перезапуска strongSwan это перестало работать, но снова начало работать, когда я переместил промежуточный и корневой CA в /etc/ipsec.d/cacerts.


0

После долгих поисков в этой теме моя конфигурация Windows Phone 10 (WP10) работала с IKEv2! Следует упомянуть, что вам нужно ./конфигурировать ваш Strongswan с --enable-eap-identity --enable-eap-mschapv2 --enable-openssl (и, вероятно, --enable-dhcp), чтобы иметь необходимые плагины. И да, вам нужно правильно получить сертификаты (на стороне сервера - клиенту нужно знать только корневой CA сервера).

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.