Puncte:1

Problemă cu conectarea mai multor clienți Windows 10 la distanță la Strongswan cu certificate les-encrypt (IKEv2-EAP)

drapel de

Am configurat un server Strongswan pentru ca clienții VPN să acceseze rețeaua internă (EAP-IKEv2). L-am configurat cu succes folosind certificate de server Letsencrypt și funcționează pentru clienții care folosesc Mac OS X, IOS, Windows 7 și Windows 10.

Totul a funcționat bine timp de un an

Dar acum câteva săptămâni mai mulți clienți la distanță care foloseau Windows 10 au început să primească erori în timpul conexiunii

Server: Strongswan versiunea 5.8.2 pe FreeBSD 11.2-RELEASE-p15 Client: Mac OS X (mai multe versiuni) / IOS (mai multe versiuni) / Windows 7 (mai multe versiuni) / Windows 10 (mai multe versiuni)

Eroare VPN Windows 10: 13801: acreditările de autentificare IKE sunt o eroare inacceptabilă

În același timp, alți clienți la distanță, inclusiv cei care folosesc Windows 10 cu același număr de versiune, funcționează bine.

Cel mai trist lucru este că eroarea nu se corelează cu numărul de versiuni al Windows 10

Desigur, certificatul este extins și valabil

Toate detaliile le găsiți mai jos.

Multumesc pentru timpul acordat. As fi recunoscator pentru orice ajutor

ipsec.conf

  configurare
  strictcrlpolicy=nu
  charondebug="ike 1, knl 1, cfg 0"
  uniceids=nu

conn ikev2-vpn
  auto=adăugați
  compresa=nu
  tip=transport
  keyexchange=ikev2
  fragmentare=da
  forcecaps=da

  ike=aes128-sha256-ecp256,aes256-sha384-ecp384,aes128-sha256-modp2048,aes128-sha1-modp2048,aes256-sha384-modp4096,aes256,aes256-56-modes162-modes42056-256-modes1625625162625625626262626262626262626162625626162562562562561616561 aes128-sha1-modp1536,aes256-sha384-modp2048,aes256-sha2
  esp=aes128gcm16-ecp256,aes256gcm16-ecp384,aes128-sha256-ecp256,aes256-sha384-ecp384,aes128-sha256-modp2048,aes128-sha28-sha256-sha256-modes40206-modes4656-modes40204-modes402656-modes40204 modp4096,aes128-sha256-modp1536,aes128-sha1-modp1

  dpdaction=clear
  dpddelay=300s
  rekey=nu

  stânga=%oricare
  [email protected]
  leftcert=fullchain.pem
  leftsendcert=intotdeauna
  leftsubnet=0.0.0.0/0

  dreapta=%oricare
  rightid=%orice
  rightauth=eap-mschapv2
  rightsourceip=192.168.20.2-192.168.20.50
  rightdns=192.168.70.253,192.168.70.254

  eap_identity=%identitate

partea finală a charon.log

23 iunie 09:12:17 11[MGR] <ikev2-vpn|10> înregistrare IKE_SA ikev2-vpn[10]
23 iunie 09:12:17 03[NET] trimitere pachet: de la *serverip*[4500] la *clientip*[4500]
23 iunie 09:12:17 11[MGR] <ikev2-vpn|10> înregistrarea IKE_SA cu succes
23 iunie 09:12:17 03[NET] trimitere pachet: de la *serverip*[4500] la *clientip*[4500]
23 iunie 09:12:46 06[NET] în așteptarea datelor pe socluri
23 iunie 09:12:46 01[JOB] a primit eveniment, așteaptă lucrarea în coadă pentru execuție
23 iunie 09:12:46 01[JOB] următorul eveniment în 628 ms, în așteptare
23 iunie 09:12:46 11[MGR] checkout IKEv2 SA cu SPI-uri 688d0386698d3362_i b3e60629dc447607_r
23 iunie 09:12:46 11[MGR] IKE_SA nu a reușit.
23 iunie 09:12:47 01[JOB] a primit eveniment, așteaptă lucrarea în coadă pentru execuție
23 iunie 09:12:47 01[JOB] următorul eveniment în 98s 38ms, în așteptare
23 iunie 09:12:47 11[MGR] checkout IKEv2 SA cu SPI-uri ef71603dd0f2ce38_i 6e86dbaeb491d377_r
23 iunie 09:12:47 11[MGR] IKE_SA ikev2-vpn[10] a verificat cu succes
23 iunie 09:12:47 11[JOB] <ikev2-vpn|10> ștergerea IKE_SA pe jumătate deschisă cu *clientip* după expirare
23 iunie 09:12:47 11[MGR] <ikev2-vpn|10> înregistrarea și distrugerea IKE_SA ikev2-vpn[10]
23 iunie 09:12:47 11[IKE] <ikev2-vpn|10> IKE_SA ikev2-vpn[10] schimbare de stare: CONECTARE => DISTRUGERE
23 iunie 09:12:47 11[MGR] înregistrarea și distrugerea IKE_SA cu succes
drapel cn
Postat încrucișat [aici](https://github.com/strongswan/strongswan/discussions/473).
Puncte:1
drapel cn

Am avut aceeași problemă, rezolvată prin adăugarea celui mai recent certificat CA rădăcină Let's Encrypt în Mașină locală magazin cert.

Nu pot garanta că a fost aceeași problemă ca și dumneavoastră, dar a rezolvat-o pentru mine. Am adăugat și versiunea PEM a aceluiași certificat în fișierul /etc/ipsec/cacerts dir pe serverul VPN, care de la sine nu a rezolvat problema.

Iată un script PowerShell pentru a instala certificatul rădăcină în magazinul local de certificate Windows:

    Write-Host „Preluarea permite criptarea certificatului CA rădăcină...” -ForegroundColor Cyan
    $ieșire = "isrgrootx1.der"
    $configUrl = "https://letsencrypt.org/certs/isrgrootx1.der"
    Invoke-WebRequest -Uri $configUrl -OutFile $output
    Import-Certificat -FilePath „$output” -CertStoreLocation „Cert:\LocalMachine\Root”-Verbose
Alexey Rusanovsky avatar
drapel de
Buna! Instalarea certificatului rădăcină a ajutat. Înainte de asta, instalasem certificatul în sine în stocarea privată.
Puncte:0
drapel me

Am avut aceeași problemă, scriptul powershell dat de @StampyCode funcționează, dar și utilizatorul pur și simplu vizitând https://valid-isrgrootx1.letsencrypt.org/ activează certificatul ISRG Root X1 pe mașină și rezolvă și problema.

Scriptul este ideal dacă îl puteți implementa pe multe mașini pe care le gestionați, dar pentru cazuri individuale este mult mai ușor să spuneți utilizatorului să viziteze acel site web, caz în care Windows activează automat certificatul rădăcină.

Mi-aș dori totuși ca Microsoft să aibă ISRG Root X1 activat în mod implicit.

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.