Регистрация Войти
Рейтинг:2
avatar Server

Пользователи iPhone не подключаются к StrongSwan VPN, а пользователи Android и Windows 10 подключаются?

флаг us
Lasse Michael Mølgaard

У меня есть StrongSwan VPN, который по какой-то неизвестной мне причине не может подключить пользователей iOS к моему VPN-серверу.

Несколько быстрых заметок:

  • Мой сервер StrongSwan является прикрытием для VPN-клиентов, которые подключаются к моей сети. я использовал WireGuard для моей внутренней маршрутизации между сайтами.

  • Все пользователи StrongSwan VPN проходят проверку на соответствие FreeRadius сервер.

  • Клиентам StrongSwan назначается IP-адрес на 192.168.201.0/24 подсеть, в то время как магистральная сеть WireGuard работает на 192.168.200.0/24 подсеть.

  • Всем клиентам также выдается общедоступный IPv6-адрес, принадлежащий подсети /48, назначенной мне.

Я запускаю StrongSwan на Ubuntu 20.04, и мой файл конфигурации находится в /etc/swanctl/config/ папка и включается по умолчанию из-за того, что имя файла заканчивается на .conf.

Содержание следующее:

# Настройки VPN-сервера по умолчанию для всех подключений
подключения по умолчанию {
    local_addrs = PUBLIC_IPV4, PUBLIC_IPV6

    местный {
      авторизация = публичный ключ
      сертификаты = vpn-ecdsa.cer
      идентификатор = vpn.example.com
    }

    версия = 2
    send_certreq = нет
    send_cert = всегда
    уникальный = никогда
    фрагментация = да
    инкап = да
    dpd_delay = 60 с

    rekey_time = 0 с
}

# Метод входа по умолчанию
eap-по умолчанию {
  удаленный {
   авторизация = eap-радиус
   идентификатор =% любой
   eap_id = % любой
  }
}

связи
{
  # Общая конфигурация Android, расширенная ниже.
  #
  # Работает с VPN-клиентом StrongSwan для Android
  conn-unix : conn-defaults, eap-defaults {
    дети {
      сеть {
        local_ts = 0.0.0.0/0, ::/0
      }

      net-unix: дочерние значения по умолчанию {
      }

      esp_proposals = aes128gcm128-x25519
    }

    предложения = aes128-sha256-x25519
  }

  # Все клиенты Windows соответствуют этому правилу проверки имени пользователя 
  # делается с помощью 'eap_start = yes' в strongswan.conf. 
  #
  # Работает со встроенным VPN-клиентом Windows 10.
  conn-windows: conn-defaults, eap-defaults {
    дети {
      сеть {
        local_ts = 0.0.0.0/0, ::/0
      }

      esp_proposals = aes256-sha256-prfsha256-modp1024
    }

    предложения = aes256-sha256-prfsha256-modp1024
    пулы = IkeVPN-сайт-ipv4, IkeVPN-сайт-ipv6

  }

  # Очень похожая конфигурация для клиентов Windows 
  # конфигурация, за исключением того, что iOS использует 2048-битные ключи, 
  # в то время как Windows использует 1024-битные ключи.
  #
  # НЕ работает в текущем состоянии.
  conn-ios : conn-defaults, eap-defaults {
    дети {
      сеть {
        local_ts = 0.0.0.0/0, ::/0
      }

      esp_proposals = aes256-sha2_256
      пулы = IkeVPN-сайт-ipv4, IkeVPN-сайт-ipv6

    }

    предложения = aes256-sha256-prfsha256-modp2048
  }

  # Пользователи Android сопоставляются с этим соединением как есть 
  # запуск приложения StrongSwan VPN-клиент. Имя пользователя передается в
  # поле 'id' для VPN-сервера StrongSwan.
  conn-unix-сайт : connection.conn-unix {
    удаленный {
      идентификатор = *@site.example.com
    }
    пулы = IkeVPN-сайт-ipv4, IkeVPN-сайт-ipv6
  }
}

бассейны
{
   IkeVPN-сайт-ipv4 {
      адрес = 192.168.201.0/24
      DNS = 192.168.200.1
   }

   IkeVPN-сайт-ipv6 {
      адрес = 2001:db8:кафе::/97
      DNS = 2001:db8::1
   }
}

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

https://wiki.strongswan.org/projects/strongswan/wiki/Strongswanconf#Referencing-other-Sections

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

Если вы не знакомы с этой настройкой, следующая конфигурация для conn-ios это следует считать эквивалентным:

conn-ios {
   # Получено из conn-default
   local_addrs = PUBLIC_IPV4, PUBLIC_IPV6

   местный {
      авторизация = публичный ключ
      сертификаты = vpn-ecdsa.cer
      идентификатор = vpn.example.com
   }

   версия = 2
   send_certreq = нет
   send_cert = всегда
   уникальный = никогда
   фрагментация = да
   инкап = да
   dpd_delay = 60 с

   rekey_time = 0 с

   # Получено из eap-defaults
   удаленный {
      авторизация = eap-радиус
      идентификатор =% любой
      eap_id = % любой
   }

   # Получено из исходного профиля conn-ios выше.
   дети {
      сеть {
         local_ts = 0.0.0.0/0, ::/0
      }

      esp_proposals = aes256-sha2_256
      пулы = IkeVPN-сайт-ipv4, IkeVPN-сайт-ipv6
   }

   предложения = aes256-sha256-prfsha256-modp2048
}

Сертификат сервера, указанный в подключение по умолчанию Раздел представляет собой сертификат ECDSA, полученный от Let's Encrypt с использованием Acme.sh.

Значения шифрования для предложенияи esp_proposals в конфигурации iOS берется из подсказки в: https://wiki.strongswan.org/projects/strongswan/wiki/AppleClients.

При тестировании всех комбинаций Android или Windows пользователи подключаются без проблем, но когда кто-то пытается войти с помощью iPhone, соединение останавливается.

Вывод из журнала при попытке подключения iPhone выглядит следующим образом:

10[IKE] CLIENT_IPV4 инициирует IKE_SA
10[CFG] received proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1536, IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:3DES_CBC /HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
10 настроенных предложений [CFG]: IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/CURVE_25519
10[IKE] Соответствующее предложение не найдено, пробуем альтернативную конфигурацию
10[CFG] received proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1536, IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:3DES_CBC /HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
10 настроенных предложений [CFG]: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024
10[IKE] Соответствующее предложение не найдено, пробуем альтернативную конфигурацию
10[CFG] выбрал предложение: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
10[IKE] удаленный хост находится за NAT
10[ENC] генерирует ответ IKE_SA_INIT 0 [SA KE Нет N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(CHDLESS_SUP) N(MULT_AUTH) ]
10[NET] отправка пакета: от PUBLIC_IPV4[500] до CLIENT_IPV4[6452] (456 байт)
06[NET] полученный пакет: от CLIENT_IPV4[13549] до PUBLIC_IPV4[4500] (512 байт)
06[ENC] неизвестный тип атрибута INTERNAL_DNS_DOMAIN
06[ENC] проанализированный запрос IKE_AUTH 1 [IDi N(INIT_CONTACT) IDr CPRQ(MASK ADDR DHCP DNS ADDR6 DHCP6 DNS6 DOMAIN) N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) SA TSi TSr N(MOBIKE_SUP) ]
06[CFG] ищет одноранговые конфигурации, соответствующие PUBLIC_IPV4[vpn.example.com]...CLIENT_IPV4[PRIVATE_CLASS_A_ADDRESS]
06[CFG] выбрана одноранговая конфигурация 'conn-ios'
06[IKE] инициирует метод EAP_IDENTITY (id 0x00)
06[IKE] получил ESP_TFC_PADDING_NOT_SUPPORTED, не используя заполнение ESPv3 TFC
06 [IKE] одноранговый узел поддерживает MOBIKE
06[IKE] аутентификация 'vpn.example.com' (я) с подписью ECDSA-256 успешна
06[IKE] отправляет сертификат конечного объекта "CN=vpn.example.com"
06[IKE] отправляет сертификат издателя "C=US, O=Let's Encrypt, CN=R3"
06[ENC] генерация ответа IKE_AUTH 1 [IDr CERT CERT AUTH EAP/REQ/ID]
06[ENC] разделение сообщения IKE (2816 байт) на 3 фрагмента
06[ENC] генерация ответа IKE_AUTH 1 [EF(1/3)]
06[ENC] генерация ответа IKE_AUTH 1 [EF(2/3)]
06[ENC] генерация ответа IKE_AUTH 1 [EF(3/3)]
06[NET] отправка пакета: от PUBLIC_IPV4[4500] до CLIENT_IPV4[13549] (1236 байт)
06[NET] отправка пакета: от PUBLIC_IPV4[4500] до CLIENT_IPV4[13549] (1236 байт)
06[NET] отправка пакета: от PUBLIC_IPV4[4500] до CLIENT_IPV4[13549] (500 байт)
11[ЗАДАНИЕ] удаление полуоткрытого IKE_SA с CLIENT_IPV4 после тайм-аута

Пользователи iPhone подключаются с помощью встроенного VPN-клиента со следующими настройками:

  • Тип IKEv2

  • Описание: VPN-сервер.

  • Сервер: vpn.example.com

  • Удаленный идентификатор: vpn.example.com

  • Местный идентификатор: ПУСТО

  • Аутентификация по имени пользователя и паролю.

  • Имя пользователя: [email protected]

  • Пароль: ItIsASecret

Кто-нибудь знает, почему соединение останавливается для пользователей iOS, когда он загружает conn-ios профиль?

ОБНОВИТЬ А у нас старт! :-)

По совету @ecdsa я переключил сертификат на 2048-битный сертификат RSA.

Мой сервер Radius вызывается. Аутентификация пользователя прошла успешно, и клиент получает IP-адрес. Я счастлив. :-)

Моя конфигурация для conn-ios сейчас:

  conn-ios : conn-defaults, eap-defaults {

    # Переопределение значений по умолчанию из 'conn-default'
    местный {
      авторизация = публичный ключ
      сертификаты = vpn-rsa.cer
      идентификатор = vpn.example.com
    }

    дети {
      сеть {
        local_ts = 0.0.0.0/0, ::/0
      }

      esp_proposals = aes256-sha256
    }

    пулы = IkeVPN-сайт-ipv4, IkeVPN-сайт-ipv6
    предложения = aes256-sha256-prfsha256-modp2048
  }

Все остальное как есть из моей первоначальной конфигурации.

1013
1 + 7
флаг cn
ecdsa
Повторной передачи нет, поэтому, скорее всего, клиент не доверяет/не поддерживает сертификат сервера. Вы используете Let's Encrypt, который должны поддерживать большинство клиентов.Поэтому единственное, о чем я могу думать, это то, что у клиента проблема с сертификатом сервера ECDSA. Вы пробовали с сертификатом RSA?
0
Ответить
флаг us
Lasse Michael Mølgaard
Не в сочетании с iPhone, но это должно быть легко проверить. Однако они выводят из журнала, что проверка сертификата прошла успешно. См.: «Аутентификация 'vpn.example.com' (я) с подписью ECDSA-256 прошла успешно».
0
Ответить
флаг us
Lasse Michael Mølgaard
Было бы странно, что Lets Encrypt ECDSA не работает с VPN, поскольку у меня есть iPhone и iPad, использующие один и тот же сертификат при отправке или получении почты, поскольку мой почтовый сервер размещен на том же компьютере, что и VPN.
0
Ответить
флаг cn
ecdsa
Сообщение журнала исходит от сервера, генерирующего подпись (не проверяющую). Это ничего не говорит о том, может ли клиент проверить это или нет (для этого вам потребуется доступ к журналу клиента через Xcode). И почтовый клиент, очевидно, является совершенно другим программным обеспечением, чем VPN-клиент, поэтому вы не можете их сравнивать.
0
Ответить
флаг us
Lasse Michael Mølgaard
Правильно. Моя самая большая проблема с отладкой iPhone заключается в том, что у меня на самом деле нет iPhone, поэтому тестирование было выполнено другом удаленно, который в основном только отвечал «это работает» или «не работает». Думаю, мне придется заняться отладкой через плечо в следующий раз, когда я встречу своего друга.
0
Ответить
флаг cn
ecdsa
Я бы попробовал с сертификатом RSA. Очевидно, что клиенты Apple не поддерживают [RFC 7427] (https://datatracker.ietf.org/doc/html/rfc7427) (иначе вы бы увидели хэш-алгоритм, уведомляющий в сообщениях `IKE_SA_INIT`) и в базе IKEv2 RFC параметры для ECDSA довольно ограничены (конкретные кривые и алгоритмы хеширования). Таким образом, они могут принимать/использовать его только в том случае, если он настроен явно в [конфигурационном профиле] (https://wiki.strongswan.org/projects/strongswan/wiki/AppleIKEv2Profile) (есть параметр `CertificateType`, который можно установить на ` ECDSA256`).
1
Ответить
флаг us
Lasse Michael Mølgaard
@ecdsa: И у нас старт! :-) Не могли бы вы добавить ответ, чтобы получить признание за правильный ответ? :-)
0
Ответить
Рейтинг:0
avatar Server
флаг cn
ecdsa

Судя по логу, клиент не поддерживает RFC 7427 (иначе уведомления хеш-алгоритма будут обмениваться во время IKE_SA_INIT), который определяет гибкую аутентификацию на основе подписи.

Хотя IKEv2 также поддерживает ECDSA без этого расширения, RFC 4754 только добавлена ​​ограниченная поддержка для него (могут использоваться только три кривые NIST, и каждой назначен определенный алгоритм хеширования). Таким образом, клиенты Apple могут принимать/использовать ECDSA только в том случае, если они явно настроены в профиль конфигурации (есть вариант Тип сертификата который может быть установлен, например. ECDSA256).

Если использование профилей конфигурации невозможно, единственной альтернативой является использование Сертификаты сервера RSA, по крайней мере, до тех пор, пока Apple не реализует поддержку RFC 7427 в своем клиенте IKEv2.

0 + 1
флаг us
Lasse Michael Mølgaard
Спасибо. Решение предназначено для школы с более чем 200 пользователями, поэтому я хотел что-то, что можно было бы использовать с минимальной технической поддержкой для конечных пользователей. Следовательно, цель состояла в том, чтобы просто сказать им, к какому серверу подключаться и какое имя пользователя и пароль использовать. Все, что выходит за рамки этого, считается «слишком сложным» для конечных пользователей. :-)
0
Ответить
флаг Moldova
Admin
Этот вопрос на других языках:

Ответить или комментировать

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