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

Не удалось запустить VPN-подключение IKEv2 к Surfshark через NetworkManager.

флаг us
Morse

Я пытаюсь подключиться к VPN-провайдеру Surfshark через IKEv2 вручную. Вот журналы

 charon-nm[5070]: 05[CFG] получил инициацию для подключения к NetworkManager Surfshark IKE2
 charon-nm[5070]: 05[CFG] с использованием идентификатора шлюза «ru-mos.prod.surfshark.com»
 charon-nm[5070]: 05[IKE] инициирует IKE_SA Surfshark IKE2[1] на 92.38.138.139
 charon-nm[5070]: 05[ENC] генерирует запрос IKE_SA_INIT 0 [SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP)]
 charon-nm[5070]: 05[NET] отправка пакета: с 192.168.2.35[35071] на 92.38.138.139[500] (1096 байт)
 NetworkManager[4583]: <info> [1636055533.4566] vpn-connection[0x56150178a510,6c89b390-d6ee-47d8-a547-346f75797487,"Surfshark IKE2",0]: VPN-плагин: состояние изменено: запуск (3)
 charon-nm[5070]: 15[NET] полученный пакет: с 92.38.138.139[500] на 192.168.2.35[35071] (38 байт)
 charon-nm[5070]: 15[ENC] проанализировано ответ IKE_SA_INIT 0 [ N(INVAL_KE) ]
 charon-nm[5070]: 15[IKE] узел не принял группу DH ECP_256, он запросил ECP_521
 charon-nm[5070]: 15[IKE] инициирует IKE_SA Surfshark IKE2[1] на 92.38.138.139
 charon-nm[5070]: 15[ENC] генерирует запрос IKE_SA_INIT 0 [SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP)]
 charon-nm[5070]: 15[NET] отправка пакета: с 192.168.2.35[35071] на 92.38.138.139[500] (1164 байта)
 charon-nm[5070]: 01[NET] полученный пакет: с 92.38.138.139[500] на 192.168.2.35[35071] (332 байта)
 charon-nm[5070]: 01[ENC] проанализировано ответ IKE_SA_INIT 0 [SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(MULT_AUTH) ]
 charon-nm[5070]: 01[CFG] выбранное предложение: IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/ECP_521
 charon-nm[5070]: 01[IKE] локальный хост находится за NAT, отправка сообщений поддержки активности
 charon-nm[5070]: 01[IKE] отправляет запрос сертификата для «C=VG, O=Surfshark, CN=Surfshark Root CA»
 charon-nm[5070]: 01[IKE] установка CHILD_SA Surfshark IKE2{1}
 charon-nm[5070]: 01[ENC] генерирует запрос IKE_AUTH 1 [IDi N(INIT_CONTACT) CERTREQ SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_6_ADDR) N(MULT_AUTH) N(EAP_ONLY) N (MSG_ID_SYN_SUP)]
 charon-nm[5070]: 01[NET] отправка пакета: с 192.168.2.35[58480] на 92.38.138.139[4500] (438 байт)
 charon-nm[5070]: 07[NET] полученный пакет: с 92.38.138.139[4500] на 192.168.2.35[58480] (1248 байт)
 charon-nm[5070]: 07[ENC] проанализирован ответ IKE_AUTH 1 [EF(1/3)]
 charon-nm[5070]: 07[ENC] получен фрагмент № 1 из 3, ожидание полного сообщения IKE
 charon-nm[5070]: 08[NET] полученный пакет: с 92.38.138.139[4500] на 192.168.2.35[58480] (1248 байт)
 charon-nm[5070]: 08[ENC] проанализирован ответ IKE_AUTH 1 [EF(2/3)]
 charon-nm[5070]: 08[ENC] получен фрагмент № 2 из 3, ожидание полного сообщения IKE
 charon-nm[5070]: 09[NET] полученный пакет: с 92.38.138.139[4500] на 192.168.2.35[58480] (579 байт)
 charon-nm[5070]: 09[ENC] проанализирован ответ IKE_AUTH 1 [EF(3/3)]
 charon-nm[5070]: 09[ENC] получен фрагмент № 3 из 3, повторно собранное фрагментированное сообщение IKE (2949 байт)
 charon-nm[5070]: 09[ENC] проанализированный ответ IKE_AUTH 1 [IDr CERT CERT AUTH EAP/REQ/ID]
 charon-nm[5070]: 09[IKE] получил сертификат конечного объекта "CN=ru-mos.prod.surfshark.com"
 charon-nm[5070]: 09[IKE] получил сертификат издателя "C=VG, O=Surfshark, CN=Surfshark Intermediate CA"
 charon-nm[5070]:09[CFG] с использованием сертификата "CN=ru-mos.prod.surfshark.com"
 charon-nm[5070]: 09[CFG] с использованием ненадежного промежуточного сертификата "C=VG, O=Surfshark, CN=Surfshark Intermediate CA"
 charon-nm[5070]:09[CFG] проверка статуса сертификата "CN=ru-mos.prod.surfshark.com"
 charon-nm[5070]: 09[CFG] статус сертификата недоступен
 charon-nm[5070]: 09[CFG] с использованием доверенного сертификата CA "C=VG, O=Surfshark, CN=Surfshark Root CA"
 charon-nm[5070]: 09[CFG] проверка статуса сертификата "C=VG, O=Surfshark, CN=Surfshark Intermediate CA"
 charon-nm[5070]: 09[CFG] статус сертификата недоступен
 charon-nm[5070]: 09[CFG] достиг самоподписанного корня ca с длиной пути 1
 charon-nm[5070]: 09[IKE] аутентификация ru-mos.prod.surfshark.com с RSA_EMSA_PKCS1_SHA2_256 прошла успешно
 charon-nm[5070]: 09[IKE] сервер запросил EAP_IDENTITY (id 0x00), отправив 'mYidENtitY'
 charon-nm[5070]: 09[ENC] генерирует запрос IKE_AUTH 2 [EAP/RES/ID]
 charon-nm[5070]: 09[NET] отправка пакета: с 192.168.2.35[58480] на 92.38.138.139[4500] (90 байт)
 charon-nm[5070]: 10[NET] полученный пакет: с 92.38.138.139[4500] на 192.168.2.35[58480] (67 байт)
 charon-nm[5070]: 10[ENC] проанализировано ответ IKE_AUTH 2 [EAP/REQ/PEAP]
 charon-nm[5070]: сервер 10[IKE] запросил аутентификацию EAP_PEAP (id 0x01)
 charon-nm[5070]: 10[TLS] Версия EAP_PEAP v0
 charon-nm[5070]: 10[ENC] генерирует запрос IKE_AUTH 3 [EAP/RES/PEAP]
 charon-nm[5070]: 10[NET] отправка пакета: с 192.168.2.35[58480] на 92.38.138.139[4500] (275 байт)
 charon-nm[5070]: 11[NET] полученный пакет: с 92.38.138.139[4500] на 192.168.2.35[58480] (1065 байт)
 charon-nm[5070]: 11[ENC] проанализировал ответ IKE_AUTH 3 [EAP/REQ/PEAP]
 charon-nm[5070]: 11[TLS] согласовал TLS 1.2 с использованием пакета TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
 charon-nm[5070]: 11[ENC] генерирует запрос IKE_AUTH 4 [EAP/RES/PEAP]
 charon-nm[5070]: 11[NET] отправка пакета: с 192.168.2.35[58480] на 92.38.138.139[4500] (67 байт)
 charon-nm[5070]: 12[NET] полученный пакет: с 92.38.138.139[4500] на 192.168.2.35[58480] (1061 байт)
 charon-nm[5070]: 12[ENC] проанализированный ответ IKE_AUTH 4 [EAP/REQ/PEAP]
 charon-nm[5070]: 12[ENC] генерирует запрос IKE_AUTH 5 [EAP/RES/PEAP]
 charon-nm[5070]: 12[NET] отправка пакета: с 192.168.2.35[58480] на 92.38.138.139[4500] (67 байт)
 charon-nm[5070]: 13[NET] полученный пакет: с 92.38.138.139[4500] на 192.168.2.35[58480] (747 байт)
 charon-nm[5070]: 13[ENC] проанализированный ответ IKE_AUTH 5 [EAP/REQ/PEAP]
 charon-nm[5070]: 13[TLS] получил сертификат сервера TLS 'C=FR, ST=Radius, O=Example Inc., CN=Example Server Certificate, [email protected]'
 charon-nm[5070]: 13[TLS] получил промежуточный сертификат TLS 'C=FR, ST=Radius, L=Somewhere, O=Example Inc., [email protected], CN=Example Certificate Authority'
 charon-nm[5070]: 13[CFG] с использованием сертификата "C=FR, ST=Radius, O=Example Inc., CN=Example Server Certificate, [email protected]"
 charon-nm[5070]: 13[CFG] с использованием ненадежного промежуточного сертификата "C=FR, ST=Radius, L=Somewhere, O=Example Inc., [email protected], CN=Example Certificate Authority"
 charon-nm[5070]: сертификат субъекта 13[CFG] недействителен (действителен с 12 апреля 17:41:01 2021 по 11 июня 17:41:01 2021)
 charon-nm[5070]: 13[TLS] открытый ключ TLS не найден для сервера '%any'
 charon-nm [5070]: 13 [TLS] отправляет фатальное предупреждение TLS «сертификат неизвестен»
 charon-nm[5070]: 13[ENC] генерирует запрос IKE_AUTH 6 [EAP/RES/PEAP]
 charon-nm[5070]: 13[NET] отправка пакета: с 192.168.2.35[58480] на 92.38.138.139[4500] (74 байта)
 charon-nm[5070]: 14[NET] полученный пакет: с 92.38.138.139[4500] на 192.168.2.35[58480] (65 байт)
 charon-nm[5070]: 14[ENC] проанализирован ответ IKE_AUTH 6 [EAP/FAIL]
 charon-nm[5070]: 14[IKE] получил EAP_FAILURE, аутентификация EAP не удалась

Все выглядит нормально, пока при ответе 5 я не получаю какой-то странный сертификат. Я не знаю, как именно работает протокол PEAP и что должно произойти на этом этапе, но соединение работает в Windows, поэтому я предполагаю, что проблема на моей стороне.

280
0 + 0
Рейтинг:1
avatar Server
флаг cn
ecdsa 
charon-nm[5070]: сертификат субъекта 13[CFG] недействителен (действителен с 12 апреля 17:41:01 2021 по 11 июня 17:41:01 2021)

Судя по всему, срок действия сертификата RADIUS-сервера, запросившего EAP-PEAP, истек, но тема со всеми этими «примерами» все равно выглядит странно (если вы ее не изменили). Почему Windows согласится с этим, если она действительно использует EAP-PEAP, я не знаю.

можно попробовать отключить пип-пип плагин и надеюсь, что сервер поддерживает другие методы EAP (например, EAP-MD5 или EAP-MSCHAPv2). Для этого добавьте следующее в Strongswan.conf:

харон-нм {
  плагины {
    пип-пип {
      нагрузка = нет
    }
  }
}
0 + 0
флаг us
Morse
Да, отключение eap-peap сработало. В принципе, любой другой протокол работал. Может ли быть причина, по которой конкретно конфигурация eap-peap нарушена? Я не думаю, что они сделали это специально. Кроме того, есть ли способ отключить плагин только для одного подключения? Было бы неправильно отключать его для всей системы только для одного сервера. Для меня это не имеет значения, так как я не планирую делать другие соединения IKEv2, но все же.
0
Ответить
флаг cn
ecdsa
Этот «пример» выглядит как тестовый сертификат. Так что, возможно, они даже не знают, что он все еще включен или неправильно настроен (возможно, он просто работает с другими клиентами, либо потому, что они игнорируют сертификат, либо не поддерживают EAP-PEAP). Это первый метод, который запрашивает сервер, однако это не значит, что он запрашивает другой, а клиент требует переключиться на него. Другие методы EAP (например, перечисленные выше) не используют сертификаты на сервере RADIUS, поэтому... И нет, методы EAP нельзя отключить для каждого соединения. В конфигах подключения можно выбрать способ, но не через NM.
0
Ответить
флаг Moldova
Admin
Этот вопрос на других языках:

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

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