Strongswan / Ipsec mehrere Roadwarrior-Verbindungen verschiedene Subnetze

Question 1

Es ist nur möglich, Verbindungen basierend auf der Serveridentität/dem Serverzertifikat zu wechseln, wenn entweder

Die Clients senden in ihrer IKE_AUTH-Anforderung eine Remote-Identität (IDr), was viele Clients nicht tun (insbesondere Windows). Andernfalls gibt es keine passende Identität, sodass die erste Verbindung verwendet wird.

oder

wenn die FQDNs unterschiedlichen IP-Adressen zugeordnet sind, die als lokale Adressen für die Verbindungen konfiguriert werden können, sodass frühzeitig die richtige Verbindung ausgewählt wird

Answer

Es ist nur möglich, Verbindungen basierend auf der Serveridentität/dem Serverzertifikat zu wechseln, wenn entweder

Die Clients senden in ihrer IKE_AUTH-Anforderung eine Remote-Identität (IDr), was viele Clients nicht tun (insbesondere Windows). Andernfalls gibt es keine passende Identität, sodass die erste Verbindung verwendet wird.

oder

wenn die FQDNs unterschiedlichen IP-Adressen zugeordnet sind, die als lokale Adressen für die Verbindungen konfiguriert werden können, sodass frühzeitig die richtige Verbindung ausgewählt wird

Question 2

Es stellte sich heraus, dass dies mithilfe des Zertifikats nicht möglich ist, da es nicht zur Identifizierung von Benutzern auf dem Server verwendet wird.

Ich habe also einen Workaround verwendet, der beschrieben wird indiese Antwortwas bei der Auswertung hilft eap_identiy.

Jetzt verwenden meine Clients dasselbe Zertifikat, aber basierend auf den Anmeldungen kann ich entscheiden, welches Subnetz sie verwenden werden.

Meine ipsec.conf sieht jetzt ungefähr so aus:

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

ist vielleicht nicht die eleganteste Lösung, funktioniert aber in meinem Fall.

Answer

Es stellte sich heraus, dass dies mithilfe des Zertifikats nicht möglich ist, da es nicht zur Identifizierung von Benutzern auf dem Server verwendet wird.

Ich habe also einen Workaround verwendet, der beschrieben wird indiese Antwortwas bei der Auswertung hilft eap_identiy.

Jetzt verwenden meine Clients dasselbe Zertifikat, aber basierend auf den Anmeldungen kann ich entscheiden, welches Subnetz sie verwenden werden.

Meine ipsec.conf sieht jetzt ungefähr so aus:

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

ist vielleicht nicht die eleganteste Lösung, funktioniert aber in meinem Fall.

Question 3

Bei mehreren Verbindungskonfigurationen mit derselben Authentifizierungsmethode kann Strongswan basierend auf der Identität des Clients die richtige auswählen.

Verwenden Sie beispielsweise zwei Verbindungskonfigurationen:

rightcaBeide rechten Seiten verwenden den öffentlichen Schlüssel, den wir als Einschränkung verwenden können :

    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 CAIn diesem Setup wählt der Client mit ausgestellten Zertifikaten die Konfiguration dev-network_ikev2-certdirekt aus.
Wenn der Client von ausgestellte Zertifikate verwendet Testing CA, wählt Strongswan zuerst die Konfiguration dev-network_ikev2-cert, dann die Ausgabe constraint check failed: peer not authenticated by CA 'C=CN, O=Sample, CN=Develop CA'und das nächste aus test-network_ikev2-cert.

Beide rechten Seiten verwenden eap-mschapv2, wir können eap_identityals Einschränkung verwenden:

    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

Dies ist die von Flo verwendete Methode. Strongswan führt eine ähnliche Prüflogik aus wie bei Verwendung von Pubkey.

Wenn der Client die Identität in verwendet *@test.com, wählt Strongswan zuerst aus dev-network_ikev2-eap, sucht dann dieses constraint check failed: EAP identity '*@dev.com' requiredund wählt das nächste aus test-network_ikev2-eap.

Hoffe, das hilft.

Answer

Bei mehreren Verbindungskonfigurationen mit derselben Authentifizierungsmethode kann Strongswan basierend auf der Identität des Clients die richtige auswählen.

Verwenden Sie beispielsweise zwei Verbindungskonfigurationen:

rightcaBeide rechten Seiten verwenden den öffentlichen Schlüssel, den wir als Einschränkung verwenden können :

    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 CAIn diesem Setup wählt der Client mit ausgestellten Zertifikaten die Konfiguration dev-network_ikev2-certdirekt aus.
Wenn der Client von ausgestellte Zertifikate verwendet Testing CA, wählt Strongswan zuerst die Konfiguration dev-network_ikev2-cert, dann die Ausgabe constraint check failed: peer not authenticated by CA 'C=CN, O=Sample, CN=Develop CA'und das nächste aus test-network_ikev2-cert.

Beide rechten Seiten verwenden eap-mschapv2, wir können eap_identityals Einschränkung verwenden:

    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

Dies ist die von Flo verwendete Methode. Strongswan führt eine ähnliche Prüflogik aus wie bei Verwendung von Pubkey.

Wenn der Client die Identität in verwendet *@test.com, wählt Strongswan zuerst aus dev-network_ikev2-eap, sucht dann dieses constraint check failed: EAP identity '*@dev.com' requiredund wählt das nächste aus test-network_ikev2-eap.

Hoffe, das hilft.

Strongswan / Ipsec mehrere Roadwarrior-Verbindungen verschiedene Subnetze

Antwort1

Antwort2

Antwort3

verwandte Informationen