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

Question 1

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

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

или

если полные доменные имена сопоставлены с разными IP-адресами, которые можно настроить как локальные адреса для подключений, чтобы правильное подключение выбиралось на ранней стадии

Answer

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

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

или

если полные доменные имена сопоставлены с разными IP-адресами, которые можно настроить как локальные адреса для подключений, чтобы правильное подключение выбиралось на ранней стадии

Question 2

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

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

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

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

conn eap-shared
   type=tunnel
   ike=aes128-sha1-modp1024
   rightauth=eap-mschapv2
   leftcert=server-cert.pem

conn eap-init
   also=eap-shared
   # this config is used to do the EAP-Identity exchange and the
   # authentication of client and server
   eap_identity=%identity
   # the following is used to force a connection switch after
   # the authentication completed
   rightgroups=thisseemsirrelevant
   auto=add

conn eap-liv
   also=eap-shared
   eap_identity=*@liv-some-domain.com
   rightsourceip=10.200.0.0/16-10.200.254.254/16
   auto=add

conn eap-dev
   also=eap-shared
   eap_identity=*@dev-some-domain.com
   rightsourceip=10.100.0.0/16-10.100.254.254/16
   auto=add

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

Answer

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

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

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

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

conn eap-shared
   type=tunnel
   ike=aes128-sha1-modp1024
   rightauth=eap-mschapv2
   leftcert=server-cert.pem

conn eap-init
   also=eap-shared
   # this config is used to do the EAP-Identity exchange and the
   # authentication of client and server
   eap_identity=%identity
   # the following is used to force a connection switch after
   # the authentication completed
   rightgroups=thisseemsirrelevant
   auto=add

conn eap-liv
   also=eap-shared
   eap_identity=*@liv-some-domain.com
   rightsourceip=10.200.0.0/16-10.200.254.254/16
   auto=add

conn eap-dev
   also=eap-shared
   eap_identity=*@dev-some-domain.com
   rightsourceip=10.100.0.0/16-10.100.254.254/16
   auto=add

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

Question 3

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

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

Обе правые стороны, используя открытый ключ, мы можем использовать rightcaв качестве ограничения:

    conn dev-network_ikev2-cert
        rightauth=pubkey
        rightca="C=CN, O=Sample, CN=Develop CA"
        rightsourceip=10.100.0.0/16
        rightdns=8.8.8.8
    
    conn test-network_ikev2-cert
        rightauth=pubkey
        rightca="C=CN, O=Sample, CN=Testing CA"
        rightsourceip=10.200.0.0/16
        rightdns=8.8.8.8

В этой настройке клиент с сертификатами, выпущенными , Develop CAбудет выбирать конфигурацию dev-network_ikev2-certнапрямую.
Если клиент использует сертификаты, выданные Testing CA, strongswan сначала выберет конфигурацию dev-network_ikev2-cert, затем вывод constraint check failed: peer not authenticated by CA 'C=CN, O=Sample, CN=Develop CA'и выберет следующий test-network_ikev2-cert.

Обе правые стороны, использующие eap-mschapv2, мы можем использовать eap_identityв качестве ограничения:

    conn dev-network_ikev2-eap
        rightauth=eap-mschapv2
        eap_identity=*@dev.com
        rightsourceip=10.100.0.0/16
        rightdns=8.8.8.8
    
    conn test-network_ikev2-eap
        rightauth=eap-mschapv2
        eap_identity=*@test.com
        rightsourceip=10.200.0.0/16
        rightdns=8.8.8.8

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

Если клиент использует идентификатор в *@test.com, strongswan сначала выберет dev-network_ikev2-eap, затем найдет его constraint check failed: EAP identity '*@dev.com' requiredи выберет следующий test-network_ikev2-eap.

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

Answer

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

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

Обе правые стороны, используя открытый ключ, мы можем использовать rightcaв качестве ограничения:

    conn dev-network_ikev2-cert
        rightauth=pubkey
        rightca="C=CN, O=Sample, CN=Develop CA"
        rightsourceip=10.100.0.0/16
        rightdns=8.8.8.8
    
    conn test-network_ikev2-cert
        rightauth=pubkey
        rightca="C=CN, O=Sample, CN=Testing CA"
        rightsourceip=10.200.0.0/16
        rightdns=8.8.8.8

В этой настройке клиент с сертификатами, выпущенными , Develop CAбудет выбирать конфигурацию dev-network_ikev2-certнапрямую.
Если клиент использует сертификаты, выданные Testing CA, strongswan сначала выберет конфигурацию dev-network_ikev2-cert, затем вывод constraint check failed: peer not authenticated by CA 'C=CN, O=Sample, CN=Develop CA'и выберет следующий test-network_ikev2-cert.

Обе правые стороны, использующие eap-mschapv2, мы можем использовать eap_identityв качестве ограничения:

    conn dev-network_ikev2-eap
        rightauth=eap-mschapv2
        eap_identity=*@dev.com
        rightsourceip=10.100.0.0/16
        rightdns=8.8.8.8
    
    conn test-network_ikev2-eap
        rightauth=eap-mschapv2
        eap_identity=*@test.com
        rightsourceip=10.200.0.0/16
        rightdns=8.8.8.8

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

Если клиент использует идентификатор в *@test.com, strongswan сначала выберет dev-network_ikev2-eap, затем найдет его constraint check failed: EAP identity '*@dev.com' requiredи выберет следующий test-network_ikev2-eap.

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

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

решение1

решение2

решение3

Связанный контент