Strongswan / Ipsec múltiples conexiones roadwarrior diferentes subredes

Question 1

Solo es posible cambiar conexiones según la identidad/certificado del servidor si:

los clientes envían una identidad remota (IDr) en su solicitud IKE_AUTH, lo que muchos clientes no hacen (en particular Windows); de lo contrario, no hay ninguna identidad que coincida, por lo que se utilizará la primera conexión.

o

si los FQDN se asignan a diferentes direcciones IP, que se pueden configurar como direcciones locales para las conexiones, de modo que se seleccione la conexión correcta desde el principio

Answer

Solo es posible cambiar conexiones según la identidad/certificado del servidor si:

los clientes envían una identidad remota (IDr) en su solicitud IKE_AUTH, lo que muchos clientes no hacen (en particular Windows); de lo contrario, no hay ninguna identidad que coincida, por lo que se utilizará la primera conexión.

o

si los FQDN se asignan a diferentes direcciones IP, que se pueden configurar como direcciones locales para las conexiones, de modo que se seleccione la conexión correcta desde el principio

Question 2

Resulta que no es posible utilizar el certificado ya que no se utilizan para identificar a los usuarios en el servidor.

Así que terminé usando una solución alternativa que se describe enesta respuestalo que ayuda a evaluar el eap_identiy.

Ahora mis clientes usan el mismo certificado, pero según los inicios de sesión puedo decidir qué subred van a usar.

Mi ipsec.conf ahora se ve así:

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

Puede que no sea la solución más elegante, pero funciona en mi caso.

Answer

Resulta que no es posible utilizar el certificado ya que no se utilizan para identificar a los usuarios en el servidor.

Así que terminé usando una solución alternativa que se describe enesta respuestalo que ayuda a evaluar el eap_identiy.

Ahora mis clientes usan el mismo certificado, pero según los inicios de sesión puedo decidir qué subred van a usar.

Mi ipsec.conf ahora se ve así:

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

Puede que no sea la solución más elegante, pero funciona en mi caso.

Question 3

Para múltiples configuraciones de conexión con el mismo método de autenticación, Strongswan puede seleccionar la adecuada según la identidad del cliente.

Usando dos configuraciones de conexión, por ejemplo:

Ambos lados derechos usan pubkey, podemos usar rightcacomo restricción:

    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

En esta configuración, el cliente con certificados emitidos por Develop CAseleccionará la configuración dev-network_ikev2-certdirectamente.
Si el cliente utiliza certificados emitidos por Testing CA, strongswan primero seleccionará configuración dev-network_ikev2-cert, luego salida constraint check failed: peer not authenticated by CA 'C=CN, O=Sample, CN=Develop CA'y seleccionará el siguiente test-network_ikev2-cert.

Ambos lados derechos usan eap-mschapv2, podemos usar eap_identitycomo restricción:

    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

Este es el método utilizado por Flo. Strongswan realizará una lógica de verificación similar a la del uso de pubkey.

Si el cliente usa la identidad *@test.com, strongswan primero seleccionará dev-network_ikev2-eap, luego la buscará constraint check failed: EAP identity '*@dev.com' requiredy seleccionará la siguiente test-network_ikev2-eap.

Espero que esto ayude.

Answer

Para múltiples configuraciones de conexión con el mismo método de autenticación, Strongswan puede seleccionar la adecuada según la identidad del cliente.

Usando dos configuraciones de conexión, por ejemplo:

Ambos lados derechos usan pubkey, podemos usar rightcacomo restricción:

    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

En esta configuración, el cliente con certificados emitidos por Develop CAseleccionará la configuración dev-network_ikev2-certdirectamente.
Si el cliente utiliza certificados emitidos por Testing CA, strongswan primero seleccionará configuración dev-network_ikev2-cert, luego salida constraint check failed: peer not authenticated by CA 'C=CN, O=Sample, CN=Develop CA'y seleccionará el siguiente test-network_ikev2-cert.

Ambos lados derechos usan eap-mschapv2, podemos usar eap_identitycomo restricción:

    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

Este es el método utilizado por Flo. Strongswan realizará una lógica de verificación similar a la del uso de pubkey.

Si el cliente usa la identidad *@test.com, strongswan primero seleccionará dev-network_ikev2-eap, luego la buscará constraint check failed: EAP identity '*@dev.com' requiredy seleccionará la siguiente test-network_ikev2-eap.

Espero que esto ayude.

Strongswan / Ipsec múltiples conexiones roadwarrior diferentes subredes

Respuesta1

Respuesta2

Respuesta3

información relacionada