înregistrare Logare
Puncte:2
avatar Server

Utilizatorii de iPhone nu se conectează la StrongSwan VPN, în timp ce utilizatorii de Android și Windows 10 se conectează?

drapel us
Lasse Michael Mølgaard

Am un VPN StrongSwan care, dintr-un motiv necunoscut pentru mine, nu poate conecta utilizatorii iOS la serverul meu VPN.

Câteva note rapide:

  • Serverul meu StrongSwan este frontal pentru clienții VPN care se conectează la rețeaua mea. obisnuiam WireGuard pentru rutarea mea backend de la site la site.

  • Toți utilizatorii VPN StrongSwan sunt validați împotriva unui FreeRadius Server.

  • Clienților StrongSwan li se atribuie un IP pe 192.168.201.0/24 subrețea, în timp ce rețeaua principală WireGuard rulează pe 192.168.200.0/24 subrețea.

  • Tuturor clienților li se înmânează și o adresă IPv6 publică aparținând unei subrețele /48 care mi-a fost atribuită.

Rulez StrongSwan pe Ubuntu 20.04 și fișierul meu de configurare se află în /etc/swanctl/config/ folder și este inclus în mod implicit, deoarece numele fișierului se termină pe .conf.

Conținutul este după cum urmează:

# Setările implicite ale serverului VPN pentru toate conexiunile
conn-defaults {
    adrese_locale = PUBLIC_IPV4, PUBLIC_IPV6

    local {
      auth = pubkey
      certs = vpn-ecdsa.cer
      id = vpn.example.com
    }

    versiunea = 2
    send_certreq = nr
    send_cert = întotdeauna
    unic = niciodată
    fragmentare = da
    encap = da
    dpd_delay = 60s

    rekey_time = 0s
}

# Metoda de conectare implicită
eap-defaults {
  la distanta {
   auth = eap-radius
   id = %oricare
   eap_id = %any
  }
}

conexiuni
{
  # Configurație Android generică care este extinsă mai jos.
  #
  # Funcționează cu clientul VPN StrongSwan pentru Android
  conn-unix: conn-defaults, eap-defaults {
    copii {
      net {
        local_ts = 0.0.0.0/0, ::/0
      }

      net-unix: child-defaults {
      }

      esp_proposals = aes128gcm128-x25519
    }

    propuneri = aes128-sha256-x25519
  }

  # Toți clienții Windows se potrivesc cu această regulă ca validare a numelui de utilizator 
  # este făcut de „eap_start = yes” în strongswan.conf. 
  #
  # Funcționează cu clientul VPN încorporat Windows 10.
  conn-windows : conn-defaults, eap-defaults {
    copii {
      net {
        local_ts = 0.0.0.0/0, ::/0
      }

      esp_proposals = aes256-sha256-prfsha256-modp1024
    }

    propuneri = aes256-sha256-prfsha256-modp1024
    pool-uri = IkeVPN-site-ipv4, IkeVPN-site-ipv6

  }

  # O configurație foarte asemănătoare cu clienții Windows 
  # configurație, cu excepția că iOS utilizează chei de 2048 de biți, 
  # în timp ce Windows folosește chei de 1024 de biți.
  #
  # NU funcționează în starea sa actuală.
  conn-ios : conn-defaults, eap-defaults {
    copii {
      net {
        local_ts = 0.0.0.0/0, ::/0
      }

      esp_proposals = aes256-sha2_256
      pool-uri = IkeVPN-site-ipv4, IkeVPN-site-ipv6

    }

    propuneri = aes256-sha256-prfsha256-modp2048
  }

  # Utilizatorii Android sunt comparați cu această conexiune așa cum sunt 
  # rulează aplicația client VPN StrongSwan. Numele de utilizator este transmis în
  # Câmpul „id” către serverul StrongSwan VPN.
  conn-unix-site : connections.conn-unix {
    la distanta {
      id = *@site.example.com
    }
    pool-uri = IkeVPN-site-ipv4, IkeVPN-site-ipv6
  }
}

piscine
{
   IkeVPN-site-ipv4 {
      adrese = 192.168.201.0/24
      dns = 192.168.200.1
   }

   IkeVPN-site-ipv6 {
      addrs = 2001:db8:cafe::/97
      dns = 2001:db8::1
   }
}

Configurația mea este creată folosind structura dată de pe următoarea pagină web:

https://wiki.strongswan.org/projects/strongswan/wiki/Strongswanconf#Referencing-other-Sections

Motivul pentru care îl folosesc se datorează faptului că evit să repetam aceleași setări de configurare pe toate profilurile mele de conexiune.

Dacă nu sunteți familiarizat cu această configurare, următoarea configurație pentru conn-ios aceasta ar trebui considerată echivalentă:

conn-ios {
   # Obținut de la conn-default
   adrese_locale = PUBLIC_IPV4, PUBLIC_IPV6

   local {
      auth = pubkey
      certs = vpn-ecdsa.cer
      id = vpn.example.com
   }

   versiunea = 2
   send_certreq = nr
   send_cert = întotdeauna
   unic = niciodată
   fragmentare = da
   encap = da
   dpd_delay = 60s

   rekey_time = 0s

   # Obținut din eap-defaults
   la distanta {
      auth = eap-radius
      id = %oricare
      eap_id = %any
   }

   # Obținut din profilul conn-ios original de mai sus.
   copii {
      net {
         local_ts = 0.0.0.0/0, ::/0
      }

      esp_proposals = aes256-sha2_256
      pool-uri = IkeVPN-site-ipv4, IkeVPN-site-ipv6
   }

   propuneri = aes256-sha256-prfsha256-modp2048
}

Certificatul de server listat în conn-implicit secțiunea este un certificat ECDSA obținut de la Let's Encrypt folosind Acme.sh.

Valorile de criptare pentru propuneriși esp_propuneri în configurația iOS este preluată din indicația din: https://wiki.strongswan.org/projects/strongswan/wiki/AppleClients.

Când testează toate combinațiile de Android sau Windows, utilizatorii se conectează fără probleme, dar când cineva încearcă să se autentifice folosind iPhone, conexiunea se blochează.

Ieșirea din jurnal atunci când un iPhone încearcă să se conecteze este după cum urmează:

10[IKE] CLIENT_IPV4 inițiază un IKE_SA
10[CFG] received proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1536, IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:3DES_CBC /HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
10 [CFG] propuneri configurate: IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/CURVE_25519
10[IKE] nu s-a găsit nicio propunere care se potrivește, încercând configurație alternativă
10[CFG] received proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1536, IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:3DES_CBC /HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
10 [CFG] propuneri configurate: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024
10[IKE] nu s-a găsit nicio propunere care se potrivește, încercând configurație alternativă
10[CFG] propunere selectată: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
Gazda la distanță 10[IKE] se află în spatele NAT
10[ENC] generează răspuns IKE_SA_INIT 0 [ SA KE Nu N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(CHDLESS_SUP) N(MULT_AUTH) ]
10[NET] trimite pachet: de la PUBLIC_IPV4[500] la CLIENT_IPV4[6452] (456 de octeți)
06[NET] primit pachet: de la CLIENT_IPV4[13549] la PUBLIC_IPV4[4500] (512 octeți)
06[ENC] tip de atribut necunoscut INTERNAL_DNS_DOMAIN
06[ENC] a analizat cererea IKE_AUTH 1 [ IDi N(INIT_CONTACT) IDr CPRQ(ADDR MASK DHCP DNS ADDR6 DHCP6 DNS6 DOMAIN) N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) SA TSi TSr N(MOBIKE_SUP)
06[CFG] caută configurații peer care se potrivesc cu PUBLIC_IPV4[vpn.example.com]...CLIENT_IPV4[PRIVATE_CLASS_A_ADDRESS]
06[CFG] config peer selectat „conn-ios”
06[IKE] inițiază metoda EAP_IDENTITY (id 0x00)
06[IKE] a primit ESP_TFC_PADDING_NOT_SUPPORTED, nu folosește umplutura TFC ESPv3
06[IKE] peer acceptă MOBIKE
06[IKE] autentificarea „vpn.example.com” (eu) cu semnătura ECDSA-256 reușită
06[IKE] care trimite certificatul de entitate finală „CN=vpn.example.com”
06[IKE] se trimite certificatul emitentului „C=US, O=Let's Encrypt, CN=R3”
06[ENC] generează răspunsul IKE_AUTH 1 [ IDr CERT CERT AUTH EAP/REQ/ID ]
06[ENC] împărțirea mesajului IKE (2816 octeți) în 3 fragmente
06[ENC] generează răspunsul IKE_AUTH 1 [ EF(1/3) ]
06[ENC] generează răspunsul IKE_AUTH 1 [ EF(2/3) ]
06[ENC] generează răspunsul IKE_AUTH 1 [ EF(3/3) ]
06[NET] trimite pachet: de la PUBLIC_IPV4[4500] la CLIENT_IPV4[13549] (1236 de octeți)
06[NET] trimite pachet: de la PUBLIC_IPV4[4500] la CLIENT_IPV4[13549] (1236 de octeți)
06[NET] trimite pachet: de la PUBLIC_IPV4[4500] la CLIENT_IPV4[13549] (500 de octeți)
11[JOB] ștergerea IKE_SA pe jumătate deschisă cu CLIENT_IPV4 după expirarea timpului

Utilizatorii de iPhone se conectează utilizând clientul VPN încorporat utilizând următoarele setări:

  • Tastați IKEv2

  • Descriere: server VPN

  • Server: vpn.example.com

  • ID de la distanță: vpn.example.com

  • ID local: BLANK

  • Autentificare nume de utilizator și parolă.

  • Nume de utilizator: [email protected]

  • Parola: ItIsASecret

Știe cineva de ce conexiunea se blochează pentru utilizatorii iOS când a încărcat conn-ios profil?

ACTUALIZAȚI Și avem decolare! :-)

Conform sfatului de la @ecdsa, am schimbat certificatul la un certificat RSA pe 2048 de biți.

Serverul meu Radius este sunat. Autentificarea utilizatorului reușește și clientul primește adresa IP. Sunt fericit. :-)

Configurația mea pentru conn-ios este acum:

  conn-ios : conn-defaults, eap-defaults {

    # Anularea valorii implicite de la „conn-default”
    local {
      auth = pubkey
      certs = vpn-rsa.cer
      id = vpn.example.com
    }

    copii {
      net {
        local_ts = 0.0.0.0/0, ::/0
      }

      esp_proposals = aes256-sha256
    }

    pool-uri = IkeVPN-site-ipv4, IkeVPN-site-ipv6
    propuneri = aes256-sha256-prfsha256-modp2048
  }

Toate celelalte sunt așa cum sunt din configurația mea inițială.

1013
1 + 7
drapel cn
ecdsa
Nu există retransmiteri, așa că cel mai probabil este ca clientul să nu aibă încredere/suporta certificatul serverului. Utilizați Let's Encrypt, pe care majoritatea clienților ar trebui să îl accepte.Deci singurul lucru la care mă pot gândi este că clientul are o problemă cu certificatul serverului ECDSA. Ai încercat cu un certificat RSA?
0
Răspunde
drapel us
Lasse Michael Mølgaard
Nu în combinație cu iPhone-urile, dar ar trebui să fie ușor de testat. Cu toate acestea, rezultatele din jurnal spun că verificarea certificatului a avut succes. Vedeți: „autentificarea „vpn.example.com” (eu) cu semnătura ECDSA-256 reușită”.
0
Răspunde
drapel us
Lasse Michael Mølgaard
Ar fi ciudat că Lets Encrypt ECDSA nu funcționează cu VPN, deoarece am iPhone-uri și iPad-uri care folosesc același certificat atunci când trimit sau primesc e-mail, deoarece serverul meu de e-mail este găzduit pe aceeași mașină cu VPN-ul meu.
0
Răspunde
drapel cn
ecdsa
Mesajul jurnal este de la serverul care generează semnătura (nu se verifică). Asta nu spune nimic despre dacă clientul îl poate verifica sau nu (ar trebui să accesați jurnalul clientului prin Xcode pentru asta). Și clientul de e-mail este, evident, o piesă de software complet diferită de clientul VPN, așa că nu le puteți compara cu adevărat pe cele două.
0
Răspunde
drapel us
Lasse Michael Mølgaard
Dreapta. Cea mai mare provocare a mea la depanarea iPhone-ului este că de fapt nu am un iPhone, așa că testarea a fost făcută de un prieten de la distanță, care practic mi-a răspuns doar „funcționează” sau „nu funcționează”. Cred că trebuie să fac un pic de depanare peste umăr data viitoare când mă întâlnesc cu prietenul meu.
0
Răspunde
drapel cn
ecdsa
Aș încerca cu un certificat RSA. Clienții Apple evident nu acceptă [RFC 7427](https://datatracker.ietf.org/doc/html/rfc7427) (în caz contrar, veți vedea un algoritm hash notificat în mesajele `IKE_SA_INIT`) și în bază IKEv2 RFC, opțiunile pentru ECDSA sunt destul de limitate (curbe specifice și algoritmi hash). Așa că s-ar putea să-l accepte/s-ar folosi doar dacă este configurat explicit într-un [profil de configurare](https://wiki.strongswan.org/projects/strongswan/wiki/AppleIKEv2Profile) (există o opțiune „CertificateType” care poate fi setată la „ ECDSA256`).
1
Răspunde
drapel us
Lasse Michael Mølgaard
@ecdsa: Și avem decolarea! :-) Vă rog, puteți adăuga un răspuns, astfel încât să puteți obține creditul pentru răspunsul corect? :-)
0
Răspunde
Puncte:0
avatar Server
drapel cn
ecdsa

După cum putem vedea în jurnal, clientul nu acceptă RFC 7427 (în caz contrar, notificările algoritmului hash ar fi schimbate în timpul IKE_SA_INIT), care definește autentificarea flexibilă bazată pe semnătură.

În timp ce IKEv2 acceptă și ECDSA fără această extensie, RFC 4754 a adăugat doar suport limitat pentru acesta (pot fi utilizate doar cele trei curbe NIST și fiecare are alocat un algoritm hash specific). Deci, este posibil ca clienții Apple să accepte/să folosească ECDSA numai dacă sunt configurați explicit într-un profil de configurare (există o opțiune Tip de certificat care poate fi setat la de ex. ECDSA256).

Dacă utilizarea profilurilor de configurare nu este o opțiune, singura alternativă este utilizarea Certificate de server RSA, cel puțin până când Apple implementează suport pentru RFC 7427 în clientul IKEv2.

0 + 1
drapel us
Lasse Michael Mølgaard
Mulțumesc. Soluția este pentru o școală cu peste 200 de utilizatori, așa că am vrut ceva care să poată fi folosit cu cât mai puțin suport tehnic pentru utilizatorii finali. Prin urmare, scopul a fost să le spunem la ce server să se conecteze și ce nume de utilizator și parolă să folosească. Orice altceva dincolo de aceasta este considerat „prea complicat” pentru utilizatorii finali. :-)
0
Răspunde
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.