înregistrare Logare
Puncte:1
Flo avatar Server

Strongswan / Ipsec conexiuni multiple roadwarrior diferite subrețele

drapel ph
Flo

Încerc să configurez un server VPN StrongSwan care ar trebui să găzduiască mai multe conexiuni roadwarrior (Windows 10 - client vpn intern), dar subrețele diferite, în funcție de certificatul clienților.

root@VPN:/# versiune ipsec

Linux strongSwan U5.8.2/K5.4.0-26-generic

Configurația mea are 2 perechi de chei publice și private, folosind un CN diferit să spunem vpn-dev.mycom.com și vpn-liv.mycom.com. Folositul ipsec.conf arata cam asa:

conn vpn-dev
    auto=adăugați
    compresa=nu
    tip=tunel
    keyexchange=ikev2
    fragmentare=da
    forcecaps=da
    dpdaction=clear
    dpddelay=300s
    rekey=nu
    ikelifetime=25200s
    leftid=vpn-dev.mycom.com
    leftcert=server-cert.pem
    leftsendcert=intotdeauna
    leftsubnet=0.0.0.0/0
    dreapta=%oricare
    rightid=%orice
    rightauth=eap-mschapv2
    rightsourceip=10.100.0.0/16-10.100.254.254/16
    dreapta=8.8.8.8,8.8.4.4
    rightsendcert=niciodată
    rightcert=ca-cert.pem
    eap_identity=%identitate
    ike=aes128-sha1-modp1024


conn vpn-liv
    de asemenea=vpn-dev
    leftid=vpn-liv.mycom.com
    leftcert=liv-server-cert.pem
    rightsourceip=10.200.0.0/16-10.200.254.254/16
    rightcert=liv-ca-cert.pem

ambele chei de certificat sunt, de asemenea, stocate în ipsec.secrete

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

someuser: EAP „somepassword”

Cu toate acestea, de îndată ce încerc să mă conectez la instanța strongswan, vpn-dev conexiunea este folosită și strongswan nu trece la conn vpn-liv

iată jurnalele în timpul unei încercări:

30 mar 08:47:48 VPN charon: 16[NET] pachet primit: de la X.X.X.X[64558] la X.X.X.X[500] (1084 de octeți)
30 mar 08:47:48 VPN charon: 16[IKE] a primit ID-ul de furnizor MS NT5 ISAKMPOAKLEY v9
30 martie 08:47:48 VPN charon: 16[IKE] a primit ID-ul furnizorului MS-Negotiation Discovery Capable
30 mar 08:47:48 VPN charon: 16[IKE] X.X.X.X inițiază un IKE_SA
30 mar 08:47:48 VPN charon: 16[CFG] propunere selectată: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
30 mar 08:47:48 VPN charon: gazda locală 16[IKE] este în spatele NAT, trimițând keep alives
30 mar 08:47:48 VPN charon: gazda la distanță 16[IKE] este în spatele NAT
30 mar 08:47:48 VPN charon: 16[NET] trimitere pachet: de la X.X.X.X[500] la X.X.X.X[64558] (328 de octeți)
30 mar 08:47:48 VPN charon: 06[NET] pachet primit: de la X.X.X.X[64596] la X.X.X.X[4500] (576 de octeți)
30 mar 08:47:48 VPN charon: 10[NET] pachet primit: de la X.X.X.X[64596] la X.X.X.X[4500] (576 de octeți)
30 mar 08:47:48 VPN charon: 05[NET] pachet primit: de la X.X.X.X[64596] la X.X.X.X[4500] (576 de octeți)
30 mar 08:47:48 VPN charon: 14[NET] pachet primit: de la X.X.X.X[64596] la X.X.X.X[4500] (368 de octeți)
30 mar 08:47:48 VPN charon: 14[IKE] a primit o cerere de certificare pentru „CN=PRIV VPN LIV CA”
30 mar 08:47:48 VPN charon: 14[IKE] a primit 69 de solicitări de certificare pentru un ca necunoscut
30 mar 08:47:48 VPN charon: 14[CFG] caută configurații peer care se potrivesc cu X.X.X.X[%any]...X.X.X.X[192.168.0.117]

30 mar 08:47:48 VPN charon: 14[CFG] a selectat peer config 'vpn-dev' # << aici nu a selectat vpn-live, chiar dacă cheia privată furnizată anterior se potrivește doar cu vpn-live

30 martie 08:47:48 VPN charon: 14[IKE] inițiază metoda EAP_IDENTITY (id 0x00)
30 mar 08:47:48 VPN charon: 14[IKE] peer acceptă MOBIKE
30 mar 08:47:48 VPN charon: 14[IKE] autentificare a „vpn-dev.mycom.com” (eu) cu semnătura RSA de succes
30 martie 08:47:48 VPN charon: 14[IKE] care trimite certificatul de entitate finală „CN=vpn-dev.mycom.com”
30 mar 08:47:49 VPN charon: 14[IKE] trimiterea cererii de certificare pentru „CN=PRIV VPN DEV CA”
30 mar 08:47:49 VPN charon: 14[IKE] trimiterea unei cereri de certificare pentru „CN=PRIV VPN LIV CA”
30 mar 08:47:49 VPN charon: 14[NET] trimitere pachet: de la X.X.X.X[500] la X.X.X.X[64548] (364 de octeți)
30 mar 08:47:49 VPN charon: 06[NET] pachet primit: de la X.X.X.X[64618] la X.X.X.X[4500] (92 de octeți)
30 mar 08:47:49 VPN charon: 06[IKE] primit (28) notificare de eroare

Scopul este practic de a găzdui 2 puncte finale vpn pe o singură mașină, dar să furnizeze diferite intervale de ip, în funcție de certificatul de conectare/utilizat.

Configurarea locală se face cu (powershell)

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

am pierdut ceva? este configurarea mea greșit? sau pur și simplu nu este posibil acest lucru cu clientul vpn intern strongswan și Windows 10?

172
0 + 0
Puncte:0
avatar Server
drapel cn
ecdsa

Este posibilă schimbarea conexiunilor numai în funcție de identitatea/certificatul serverului, dacă oricare dintre ele

  • clienții trimit o identitate la distanță (IDr) în cererea lor IKE_AUTH, pe care mulți clienți nu o fac (în special Windows), în caz contrar, nu există o identitate care să se potrivească, așa că va fi folosită prima conexiune

sau

  • dacă FQDN-urile se mapează la adrese IP diferite, care pot fi configurate ca adrese locale pentru conexiuni, astfel încât conexiunea corectă să fie selectată mai devreme
0 + 0
Flo avatar
drapel ph
Flo
este doar parțial corect [cum am învățat aici] (https://serverfault.com/questions/908098/strongswan-clients-access-rights). Folosind soluția `rightgroups` puteți folosi proprietatea `eap_identity` pentru a identifica utilizatorii.
0
Răspunde
drapel cn
ecdsa
Poate doriți să citiți din nou propria întrebare ;) Era vorba în mod explicit de selectarea unei configurații bazate pe identitatea/certificatul serverului, nu pe identitatea clientului. (De asemenea, dacă nu ați observat, am scris și celălalt răspuns :)
0
Răspunde
Flo avatar
drapel ph
Flo
Îmi pare rău că a existat o neînțelegere, vorbeam despre certificatele folosite de clienți așa cum am spus cu „în funcție de autentificare / certificatul folosit” - de asemenea, configurațiile ar putea spune cu `rightcert`
0
Răspunde
drapel cn
ecdsa
Clienții nu folosesc niciun certificat pentru a se autentifica, fie cu configurația veche sau nouă. Acea setare `rightcert` ți-ar fi rupt configurația oricum, deoarece niciunul dintre clienții nu se va autentifica vreodată cu certificatul CA real. Dacă doriți ca clienții să se autentifice cu un certificat emis de o anumită CA (intermediară), setarea corectă ar fi fost „rightca”, dar apoi „rightauth” ar trebui să fie setat la „pubkey” sau „eap-tls” și nu `eap-mschapv2`. Și clienții, evident, ar avea nevoie de certificate/chei individuale și configurații adecvate.
0
Răspunde
Flo avatar
drapel ph
Flo
asta îmi este clar acum, dar nu era punctul meu de vedere. multumesc oricum.
0
Răspunde
Puncte:0
Flo avatar Server
drapel ph
Flo

Se pare că nu este posibilă utilizarea certificatului, deoarece acestea nu sunt folosite pentru a identifica utilizatorii de pe server.

Așa că am ajuns să folosesc o soluție care este descrisă în acest raspuns care ajută la evaluarea eap_identiy.

Acum clienții mei folosesc același certificat, dar pe baza autentificărilor pot decide ce subrețea vor folosi.

ipsec.conf-ul meu acum arată cam așa:

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

conn eap-init
   de asemenea=eap-shared
   # această configurație este folosită pentru a face schimbul EAP-Identity și
   # autentificarea clientului și serverului
   eap_identity=%identitate
   # Următoarele sunt folosite pentru a forța un comutator de conexiune după
   # autentificarea finalizată
   rightgroups=aceasta pare irelevant
   auto=adăugați

conn eap-liv
   de asemenea=eap-shared
   eap_identity=*@liv-some-domain.com
   rightsourceip=10.200.0.0/16-10.200.254.254/16
   auto=adăugați

conn eap-dev
   de asemenea=eap-shared
   eap_identity=*@dev-some-domain.com
   rightsourceip=10.100.0.0/16-10.100.254.254/16
   auto=adăugați

s-ar putea să nu fie cea mai elegantă soluție, dar funcționează în cazul meu.

0 + 0
Puncte:0
avatar Server
drapel es
Lin

Pentru mai multe configurații de conectare cu aceeași metodă de autentificare, Strongswan poate selecta pe cea potrivită în funcție de identitatea clientului.

Folosind două configurații de conectare, de exemplu:

  1. Ambele din dreapta folosind pubkey, putem folosi dreaptaca ca constrângere:
    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=Proba, CN=Testing CA"
        rightsourceip=10.200.0.0/16
        rightdns=8.8.8.8

  • În această configurare, client cu certificate emise de Dezvoltați CA va selecta config dev-network_ikev2-cert direct.

  • Dacă clientul utilizează certificate emise de Testarea CA, strongswan va selecta mai întâi config dev-network_ikev2-cert, apoi ieșire Verificarea constrângerii a eșuat: peer nu a fost autentificat de CA „C=CN, O=Sample, CN=Develop CA”și selectați-l pe următorul test-network_ikev2-cert.

  1. Ambele părți din dreapta folosind eap-mschapv2, putem folosi eap_identity ca constrângere:
    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

Aceasta este metoda folosită de Flo. Strongswan va face logica de verificare similară cu utilizarea pubkey.

  • Dacă clientul folosește identitatea în *@test.com, strongswan va selecta mai întâi dev-network_ikev2-eap, apoi găsiți asta Verificarea constrângerii a eșuat: este necesară identitatea EAP „*@dev.com”.și selectați-l pe următorul test-network_ikev2-eap.

Sper că acest lucru va ajuta.

0 + 0
drapel romania
SEF 777
întrebarea această in alte limbi:

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.