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

Strongswan / Ipsec несколько соединений roadwarrior с разными подсетями

флаг ph
Flo

Я пытаюсь настроить VPN-сервер StrongSwan, на котором должно размещаться несколько (Windows 10 — внутренний клиент vpn) соединений roadwarrior, но разных подсетей, в зависимости от сертификата клиента.

root@VPN:/# версия ipsec

Linux strongSwan U5.8.2/K5.4.0-26-общий

В моей настройке есть 2 пары открытого и закрытого ключа, скажем, с использованием разных CN vpn-dev.mycom.com и vpn-liv.mycom.com. Используемый ipsec.conf выглядит примерно так:

подключение vpn-dev
    авто=добавить
    сжать=нет
    тип=туннель
    обмен ключами=ikev2
    фрагментация=да
    форсэнкапс=да
    dpdaction=очистить
    dpddelay=300 с
    ключ = нет
    ikelifetime=25200с
    leftid=vpn-dev.mycom.com
    leftcert=сервер-cert.pem
    leftsendcert=всегда
    левая подсеть=0.0.0.0/0
    справа=%любой
    правый ID=%любой
    правая авторизация = eap-mschapv2
    исходный код=10.100.0.0/16-10.100.254.254/16
    правый DNS=8.8.8.8,8.8.4.4
    rightsendcert=никогда
    rightcert=ca-cert.pem
    eap_identity=%идентификация
    ike=aes128-sha1-modp1024


подключение vpn-liv
    также = vpn-dev
    leftid=vpn-liv.mycom.com
    leftcert=liv-server-cert.pem
    исходный код=10.200.0.0/16-10.200.254.254/16
    rightcert=liv-ca-cert.pem

оба ключа сертификата также хранятся в ipsec.secrets

vpn-dev.mycom.com : RSA "server-key.pem"
vpn-liv.mycom.com : RSA "liv-server-key.pem"

someuser : EAP "somepassword"

Однако, как только я пытаюсь подключиться к экземпляру strongswan, vpn-dev соединение используется, а strongswan не переключается на соединение vpn-liv

вот логи во время попытки:

30 марта 08:47:48 VPN charon: 16[NET] получен пакет: от X.X.X.X[64558] до X.X.X.X[500] (1084 байта)
30 марта 08:47:48 VPN charon: 16[IKE] получил идентификатор поставщика MS NT5 ISAKMPOAKLEY v9
30 марта, 08:47:48 VPN charon: 16[IKE] получил идентификатор поставщика с поддержкой MS-Negotiation Discovery.
30 марта 08:47:48 VPN charon: 16[IKE] X.X.X.X инициирует IKE_SA
30 марта 08:47:48 VPN charon: 16 [CFG] выбранное предложение: IKE: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
30 марта 08:47:48 VPN charon: 16 [IKE] локальный хост находится за NAT, отправка сообщений поддержки
30 марта 08:47:48 VPN charon: 16 [IKE] удаленный хост находится за NAT
30 марта 08:47:48 VPN charon: 16[NET] отправка пакета: от X.X.X.X[500] до X.X.X.X[64558] (328 байт)
30 марта 08:47:48 VPN charon: 06[NET] получен пакет: от X.X.X.X[64596] до X.X.X.X[4500] (576 байт)
30 марта 08:47:48 VPN charon: 10[NET] получен пакет: от X.X.X.X[64596] до X.X.X.X[4500] (576 байт)
30 марта 08:47:48 VPN charon: 05[NET] получен пакет: от X.X.X.X[64596] до X.X.X.X[4500] (576 байт)
30 марта 08:47:48 VPN charon: 14[NET] получен пакет: от X.X.X.X[64596] до X.X.X.X[4500] (368 байт)
30 марта 08:47:48 VPN charon: 14[IKE] получил запрос сертификата для "CN=PRIV VPN LIV CA"
30 марта, 08:47:48 VPN charon: 14[IKE] получил 69 запросов сертификатов для неизвестного ЦС.
30 марта 08:47:48 VPN charon: 14[CFG] ищет конфигурации пиров, соответствующие X.X.X.X[%any]...X.X.X.X[192.168.0.117]

30 марта 08:47:48 VPN charon: 14[CFG] выбрал одноранговую конфигурацию 'vpn-dev' # << здесь он не выбрал vpn-live, даже если ранее предоставленный закрытый ключ соответствует только vpn-live

30 марта 08:47:48 VPN charon: 14[IKE] инициирует метод EAP_IDENTITY (id 0x00)
30 марта 08:47:48 VPN charon: 14 [IKE] одноранговых узлов поддерживает MOBIKE
30 марта 08:47:48 VPN charon: 14 [IKE] аутентификация «vpn-dev.mycom.com» (я) с подписью RSA успешна
30 марта 08:47:48 VPN charon: 14[IKE] отправляет сертификат конечного объекта "CN=vpn-dev.mycom.com"
30 марта 08:47:49 VPN charon: 14 [IKE] отправляет запрос сертификата для «CN = PRIV VPN DEV CA»
30 марта 08:47:49 VPN charon: 14[IKE] отправляет запрос сертификата для "CN=PRIV VPN LIV CA"
30 марта 08:47:49 VPN charon: 14[NET] отправка пакета: от X.X.X.X[500] до X.X.X.X[64548] (364 байта)
30 марта 08:47:49 VPN charon: 06[NET] получен пакет: от X.X.X.X[64618] до X.X.X.X[4500] (92 байта)
30 марта 08:47:49 VPN charon: 06[IKE] получил (28) сообщение об ошибке

цель состоит в том, чтобы разместить 2 конечные точки vpn на одном компьютере, но предоставить разные диапазоны IP-адресов в зависимости от логина/используемого сертификата.

Локальная конфигурация выполняется с помощью (powershell)

Import-Certificate -FilePath liv-ca-cert.pem -CertStoreLocation 'Cert:\LocalMachine\Root'
Add-VpnConnection -Name 'LIV VPN' -ServerAddress 'vpn-live.mycom.com' -AuthenticationMethod Eap -IdleDisconnectSeconds 43200

я что-то пропустил? моя установка неправильно настроена? или это просто невозможно с внутренним vpn-клиентом strongswan и Windows 10?

172
0 + 0
Рейтинг:0
Flo avatar Server
флаг ph
Flo

Оказывается, использовать сертификат невозможно, так как он не используется для идентификации пользователей на сервере.

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

Теперь мои клиенты используют один и тот же сертификат, но на основе логинов я могу решить, какую подсеть они будут использовать.

Мой ipsec.conf теперь выглядит примерно так:

conn eap-shared
   тип=туннель
   ike=aes128-sha1-modp1024
   правая авторизация = eap-mschapv2
   leftcert=сервер-cert.pem

conn eap-init
   также=eap-shared
   # эта конфигурация используется для обмена EAP-идентификацией и
   # аутентификация клиента и сервера
   eap_identity=%идентификация
   # следующее используется для принудительного переключения соединения после
   # аутентификация завершена
   rightgroups=это кажется неуместным
   авто=добавить

conn eap-liv
   также=eap-shared
   eap_identity=*@liv-some-domain.com
   исходный код=10.200.0.0/16-10.200.254.254/16
   авто=добавить

conn eap-dev
   также=eap-shared
   eap_identity=*@dev-some-domain.com
   исходный код=10.100.0.0/16-10.100.254.254/16
   авто=добавить

может быть не самым элегантным решением, но работает в моем случае.

0 + 0
Рейтинг:0
avatar Server
флаг es
Lin

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

Например, используя две конфигурации подключения:

  1. Обе правые стороны, используя pubkey, мы можем использовать правка как ограничение:
    conn dev-network_ikev2-cert
        rightauth=pubkey
        rightca="C=CN, O=Образец, CN=Разработка ЦС"
        исходный код=10.100.0.0/16
        правый DNS = 8.8.8.8
    
    conn test-network_ikev2-cert
        rightauth=pubkey
        rightca="C=CN, O=Образец, CN=Тестовый ЦС"
        исходный код=10.200.0.0/16
        правый DNS = 8.8.8.8

  • В этой настройке клиент с сертификатами, выданными Разработать ЦС выберет конфиг dev-network_ikev2-cert напрямую.

  • Если клиент использует сертификаты, выданные Тестирование центра сертификации, strongswan сначала выберет конфигурацию dev-network_ikev2-cert, затем вывод проверка ограничения не удалась: одноранговый узел не аутентифицирован CA 'C = CN, O = Sample, CN = Develop CA', и выберите следующий тестовая сеть_ikev2-сертификат.

  1. Обе правые части используют eap-mschapv2, мы можем использовать eap_identity как ограничение:
    conn dev-network_ikev2-eap
        правая авторизация = eap-mschapv2
        eap_identity=*@dev.com
        исходный код=10.100.0.0/16
        правый DNS = 8.8.8.8
    
    conn test-network_ikev2-eap
        правая авторизация = eap-mschapv2
        eap_identity=*@test.com
        исходный код=10.200.0.0/16
        правый DNS = 8.8.8.8

Это метод, используемый Фло. Strongswan будет выполнять ту же логику проверки, что и при использовании pubkey.

  • Если клиент использует удостоверение в *@test.com, strongswan сначала выберет dev-network_ikev2-eap, то найдите, что проверка ограничения не удалась: требуется идентификатор EAP «*@dev.com», и выберите следующий тестовая сеть_ikev2-eap.

Надеюсь, это поможет.

0 + 0
Рейтинг:0
avatar Server
флаг cn
ecdsa

Переключение соединений на основе идентификатора/сертификата сервера возможно только в том случае, если

  • клиенты отправляют удаленное удостоверение (IDr) в своем запросе IKE_AUTH, чего не делают многие клиенты (в частности, Windows), в противном случае удостоверение для сопоставления отсутствует, поэтому будет использоваться первое соединение.

или же

  • если полные доменные имена сопоставляются с разными IP-адресами, которые можно настроить как локальные адреса для соединений, чтобы правильное соединение выбиралось на ранней стадии.
0 + 0
Flo avatar
флаг ph
Flo
это верно лишь отчасти [как я узнал здесь] (https://serverfault.com/questions/908098/strongswan-clients-access-rights). Используя обходной путь «rightgroups», вы можете использовать свойство «eap_identity» для идентификации пользователей.
0
Ответить
флаг cn
ecdsa
Возможно, вы захотите еще раз прочитать свой вопрос;) Это явно касалось выбора конфигурации на основе идентификатора/сертификата сервера, а не идентификатора клиента. (Кроме того, если вы не заметили, я написал другой ответ :)
0
Ответить
Flo avatar
флаг ph
Flo
извините, что произошло недоразумение, я говорил о сертификатах, используемых клиентами, как я сказал «в зависимости от логина/используемого сертификата» - также конфигурации могут указывать на «rightcert».
0
Ответить
флаг cn
ecdsa
Клиенты не используют никаких сертификатов для аутентификации, будь то ваша старая или новая конфигурация. Этот параметр `rightcert` в любом случае нарушил бы вашу конфигурацию, поскольку ни один из клиентов никогда не будет аутентифицироваться с помощью фактического сертификата CA. Если вы хотите, чтобы клиенты аутентифицировались с помощью сертификата, выданного определенным (промежуточным) ЦС, правильной настройкой будет «rightca», но тогда «rightauth» также должен быть установлен на «pubkey» или «eap-tls» и не `eap-mschapv2`. И клиентам, очевидно, потребуются отдельные сертификаты/ключи и соответствующие конфигурации.
0
Ответить
Flo avatar
флаг ph
Flo
это ясно для меня сейчас, но я не имел в виду. Спасибо, в любом случае.
0
Ответить
флаг Moldova
Admin
Этот вопрос на других языках:

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

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