Я столкнулся с проблемами при настройке VPN-соединения (IKEv1) с помощью iPhone (клиент Cisco VPN по умолчанию) и сервера Strongswan 4.5.0.
Сервер Strongswan работает на Ubuntu Linux, который подключен к какой-то точке доступа Wi-Fi. Это руководство, которое использовалось. Я создал сертификат CA, сервера и клиента с единственной разницей, упомянутой ниже.
«При создании сертификата сервера по ссылке CN = vpn.strongswan.org вместо этого я изменил имя CN на CN = 192.168.43.212».
После создания сертификатов следующие (clientCert.p12 и caCert.pem) отправляются на мобильный телефон по почте и устанавливаются на iphone. После установки замечаю, что доверенные также считаются сертификаты.
Ниже приведены IP-адреса, назначенные различным интерфейсам.
IP-адрес интерфейса wlan0 сервера Linux, на котором запущен сервер: 192.168.43.212 IP-адрес интерфейса eth0 Iphone: 192.168.43.72. iphone также подключен к той же точке доступа Wi-Fi.
Ниже приведен снимок клиентских конфигураций.
Указанные выше имя пользователя и пароль синхронизированы с файлом ipsec.secrets. Я использую следующую конфигурацию ipsec.conf:
# basic configuration
config setup
plutodebug=all
# crlcheckinterval=600
# strictcrlpolicy=yes
# cachecrls=yes
nat_traversal=yes
# charonstart=yes
plutostart=yes
# Add connections here.
# Sample VPN connections
conn ios1
keyexchange=ikev1
authby=xauthrsasig
xauth=server
left=%defaultroute
leftsubnet=0.0.0.0/0
leftfirewall=yes
leftcert=serverCert.pem
right=192.168.43.72
rightsubnet=10.0.0.0/24
rightsourceip=10.0.0.2
rightcert=clientCert.pem
pfs=no
auto=add
С приведенными выше конфигурациями, когда я включаю VPN на iphone, появляется сообщение
Не удалось проверить сертификат сервера.
Я запустил Wireshark на сервере Linux и заметил, что первоначально между клиентом и сервером происходит обмен сообщениями ISAKMP, который проходит успешно, но до авторизации клиент отправляет некоторое информационное сообщение и вскоре после этого клиент показывает ошибку в виде всплывающего окна.
Не удалось проверить сертификат сервера.
Журналы захвата на сервере Strongswan и в журналах серверов ниже наблюдаются ошибки:
Из auth.log
Apr 25 20:16:08 Linux pluto[4025]: | ISAKMP version: ISAKMP Version 1.0
Apr 25 20:16:08 Linux pluto[4025]: | exchange type: ISAKMP_XCHG_INFO
Apr 25 20:16:08 Linux pluto[4025]: | flags: ISAKMP_FLAG_ENCRYPTION
Apr 25 20:16:08 Linux pluto[4025]: | message ID: 9d 1a ea 4d
Apr 25 20:16:08 Linux pluto[4025]: | length: 76
Apr 25 20:16:08 Linux pluto[4025]: | ICOOKIE: f6 b7 06 b2 b1 84 5b 93
Apr 25 20:16:08 Linux pluto[4025]: | RCOOKIE: 86 92 a0 c2 a6 2f ac be
Apr 25 20:16:08 Linux pluto[4025]: | peer: c0 a8 2b 48
Apr 25 20:16:08 Linux pluto[4025]: | state hash entry 8
Apr 25 20:16:08 Linux pluto[4025]: | state object not found
Apr 25 20:16:08 Linux pluto[4025]: **packet from 192.168.43.72:500: Informational Exchange is for an unknown (expired?) SA**
Apr 25 20:16:08 Linux pluto[4025]: | next event EVENT_RETRANSMIT in 8 seconds for #8
Apr 25 20:16:16 Linux pluto[4025]: |
Apr 25 20:16:16 Linux pluto[4025]: | *time to handle event
Apr 25 20:16:16 Linux pluto[4025]: | event after this is EVENT_RETRANSMIT in 2 seconds
Apr 25 20:16:16 Linux pluto[4025]: | handling event EVENT_RETRANSMIT for 192.168.43.72 "ios1" #8
Apr 25 20:16:16 Linux pluto[4025]: | sending 76 bytes for EVENT_RETRANSMIT through wlan0 to 192.168.43.72:500:
Apr 25 20:16:16 Linux pluto[4025]: | a6 a5 86 41 4b fb ff 99 c9 18 34 61 01 7b f1 d9
Apr 25 20:16:16 Linux pluto[4025]: | 08 10 06 01 e9 1c ea 60 00 00 00 4c ba 7d c8 08
Apr 25 20:16:16 Linux pluto[4025]: | 13 47 95 18 19 31 45 30 2e 22 f9 4d 85 2c 27 bc
Apr 25 20:16:16 Linux pluto[4025]: | 9e 9b e1 ae 1e 35 51 6f ab 80 f5 73 3c 15 8d 20
Apr 25 20:16:16 Linux pluto[4025]: | 4b 46 47 86 50 24 3f 13 15 7d d5 17
Apr 25 20:16:16 Linux pluto[4025]: | inserting event EVENT_RETRANSMIT, timeout in 40 seconds for #8
Apr 25 20:16:16 Linux pluto[4025]: | next event EVENT_RETRANSMIT in 2 seconds for #10
Apr 25 20:16:16 Linux pluto[4025]: | rejected packet:
Apr 25 20:16:16 Linux pluto[4025]: |
Apr 25 20:16:16 Linux pluto[4025]: | control:
Apr 25 20:16:16 Linux pluto[4025]: | 30 00 00 00 00 00 00 00 00 00 00 00 0b 00 00 00
Apr 25 20:16:16 Linux pluto[4025]: | 6f 00 00 00 02 03 03 00 00 00 00 00 00 00 00 00
Apr 25 20:16:16 Linux pluto[4025]: | 02 00 00 00 c0 a8 2b 48 00 00 00 00 00 00 00 00
Apr 25 20:16:16 Linux pluto[4025]: | name:
Apr 25 20:16:16 Linux pluto[4025]: | 02 00 01 f4 c0 a8 2b 48 00 00 00 00 00 00 00 00
Apr 25 20:16:16 Linux pluto[4025]: **ERROR: asynchronous network error report on wlan0 for message to 192.168.43.72 port 500, complainant 192.168.43.72: Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)]**
Кто-нибудь, пожалуйста, сообщите об этой ошибке и о том, как решить эту проблему.
В соответствии с Документация Apple IP-адрес или DNS-имя шлюза должны содержаться в сертификате как subjectAltName. Используйте следующее при создании сертификата с помощью OpenSSL.
subjectAltName = IP:192.168.43.212
Требуется ли это на самом деле, может зависеть от версии iOS на вашем устройстве. В iOS 5.1 идентификация шлюза вроде бы не проверяется.
Приведенное выше утверждение верно только для гибридной аутентификации. Если клиент аутентифицирован с помощью сертификата, подлинность шлюза действительно проверяется.
РЕДАКТИРОВАТЬ
Некоторые эксперименты показывают, что достаточно добавить IP-адрес как общее имя (CN) к отличительному имени (DN) сертификата, но только если в сертификате нет subjectAltNames. Если вы это сделаете, вам также необходимо добавить IP-адрес как subjectAltName.
Также, ссылаясь на ваше заявление здесь:
«При создании сертификата сервера по ссылке CN = vpn.strongswan.org вместо этого я изменил имя CN на CN = 192.168.43.212».
У вас действительно есть. (точка) в конце вашего CN? Если да, удалите его.