înregistrare Logare
Puncte:0
avatar Server

Nu s-a putut porni conexiunea VPN IKEv2 la surfshark prin NetworkManager

drapel us
Morse

Încerc să mă conectez manual la furnizorul surfshark VPN prin IKEv2. Aici sunt jurnalele

 charon-nm[5070]: 05[CFG] a primit inițierea pentru conexiunea NetworkManager Surfshark IKE2
 charon-nm[5070]: 05[CFG] folosind identitatea gateway-ului „ru-mos.prod.surfshark.com”
 charon-nm[5070]: 05[IKE] care inițiază IKE_SA Surfshark IKE2[1] la 92.38.138.139
 charon-nm[5070]: 05[ENC] generează cererea IKE_SA_INIT 0 [ SA KE Nu N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
 charon-nm[5070]: 05[NET] trimitere pachet: de la 192.168.2.35[35071] la 92.38.138.139[500] (1096 octeți)
 NetworkManager[4583]: <informații> [1636055533.4566] vpn-connection[0x56150178a510,6c89b390-d6ee-47d8-a547-346f75797487, „Surfshark”: modificarea IKE2 state0]: IKEing state00]
 charon-nm[5070]: 15[NET] pachet primit: de la 92.38.138.139[500] la 192.168.2.35[35071] (38 octeți)
 charon-nm[5070]: 15[ENC] a analizat răspunsul IKE_SA_INIT 0 [ N(INVAL_KE) ]
 charon-nm[5070]: peer-ul 15[IKE] nu a acceptat grupul DH ECP_256, a solicitat ECP_521
 charon-nm[5070]: 15[IKE] care inițiază IKE_SA Surfshark IKE2[1] la 92.38.138.139
 charon-nm[5070]: 15[ENC] generează cererea IKE_SA_INIT 0 [ SA KE Nu N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
 charon-nm[5070]: 15[NET] trimitere pachet: de la 192.168.2.35[35071] la 92.38.138.139[500] (1164 de octeți)
 charon-nm[5070]: 01[NET] pachet primit: de la 92.38.138.139[500] la 192.168.2.35[35071] (332 de octeți)
 charon-nm[5070]: 01[ENC] a analizat răspunsul IKE_SA_INIT 0 [ SA KE Nu N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(MULT_AUTH) ]
 charon-nm[5070]: 01[CFG] propunere selectată: IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/ECP_521
 charon-nm[5070]: gazda locală 01[IKE] este în spatele NAT, trimițând keep alives
 charon-nm[5070]: 01[IKE] trimiterea cererii de certificare pentru „C=VG, O=Surfshark, CN=Surfshark Root CA”
 charon-nm[5070]: 01[IKE] se înființează CHILD_SA Surfshark IKE2{1}
 charon-nm[5070]: 01[ENC] generează cererea IKE_AUTH 1 [ IDi N(INIT_CONTACT) CERTREQ SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_6_ADDR) N(MULT_AP_AUTH) N(MULT_AP_)LY) (MSG_ID_SYN_SUP) ]
 charon-nm[5070]: 01[NET] trimitere pachet: de la 192.168.2.35[58480] la 92.38.138.139[4500] (438 octeți)
 charon-nm[5070]: 07[NET] pachet primit: de la 92.38.138.139[4500] la 192.168.2.35[58480] (1248 octeți)
 charon-nm[5070]: 07[ENC] a analizat răspunsul IKE_AUTH 1 [ EF(1/3) ]
 charon-nm[5070]: 07[ENC] a primit fragmentul #1 din 3, în așteptarea mesajului IKE complet
 charon-nm[5070]: 08[NET] pachet primit: de la 92.38.138.139[4500] la 192.168.2.35[58480] (1248 octeți)
 charon-nm[5070]: 08[ENC] a analizat răspunsul IKE_AUTH 1 [ EF(2/3) ]
 charon-nm[5070]: 08[ENC] a primit fragmentul #2 din 3, în așteptarea mesajului IKE complet
 charon-nm[5070]: 09[NET] pachet primit: de la 92.38.138.139[4500] la 192.168.2.35[58480] (579 de octeți)
 charon-nm[5070]: 09[ENC] a analizat răspunsul IKE_AUTH 1 [ EF(3/3) ]
 charon-nm[5070]: 09[ENC] a primit fragmentul #3 din 3, mesaj IKE fragmentat reasamblat (2949 de octeți)
 charon-nm[5070]: 09[ENC] a analizat răspunsul IKE_AUTH 1 [ IDr CERT CERT AUTH EAP/REQ/ID ]
 charon-nm[5070]: 09[IKE] a primit certificatul de entitate finală „CN=ru-mos.prod.surfshark.com”
 charon-nm[5070]: 09[IKE] a primit certificatul emitentului „C=VG, O=Surfshark, CN=Surfshark Intermediate CA”
 charon-nm[5070]: 09[CFG] folosind certificatul „CN=ru-mos.prod.surfshark.com”
 charon-nm[5070]: 09[CFG] utilizând certificatul intermediar neîncrezat „C=VG, O=Surfshark, CN=Surfshark Intermediate CA”
 charon-nm[5070]: 09[CFG] se verifică starea certificatului „CN=ru-mos.prod.surfshark.com”
 charon-nm[5070]: starea certificatului 09[CFG] nu este disponibilă
 charon-nm[5070]: 09[CFG] folosind certificatul CA de încredere „C=VG, O=Surfshark, CN=Surfshark Root CA”
 charon-nm[5070]: 09[CFG] se verifică starea certificatului „C=VG, O=Surfshark, CN=Surfshark Intermediate CA”
 charon-nm[5070]: starea certificatului 09[CFG] nu este disponibilă
 charon-nm[5070]: 09[CFG] a ajuns la rădăcina auto-semnată ca cu o lungime a căii de 1
 charon-nm[5070]: 09[IKE] autentificarea „ru-mos.prod.surfshark.com” cu RSA_EMSA_PKCS1_SHA2_256 cu succes
 charon-nm[5070]: serverul 09[IKE] a solicitat EAP_IDENTITY (id 0x00), trimițând „mYidENtitY”
 charon-nm[5070]: 09[ENC] generează cererea IKE_AUTH 2 [ EAP/RES/ID ]
 charon-nm[5070]: 09[NET] trimitere pachet: de la 192.168.2.35[58480] la 92.38.138.139[4500] (90 octeți)
 charon-nm[5070]: 10[NET] pachet primit: de la 92.38.138.139[4500] la 192.168.2.35[58480] (67 de octeți)
 charon-nm[5070]: 10[ENC] analizat răspunsul IKE_AUTH 2 [ EAP/REQ/PEAP ]
 charon-nm[5070]: serverul 10[IKE] a solicitat autentificare EAP_PEAP (id 0x01)
 charon-nm[5070]: 10[TLS] Versiunea EAP_PEAP este v0
 charon-nm[5070]: 10[ENC] generează cererea IKE_AUTH 3 [ EAP/RES/PEAP ]
 charon-nm[5070]: 10[NET] trimitere pachet: de la 192.168.2.35[58480] la 92.38.138.139[4500] (275 octeți)
 charon-nm[5070]: 11[NET] pachet primit: de la 92.38.138.139[4500] la 192.168.2.35[58480] (1065 octeți)
 charon-nm[5070]: 11[ENC] a analizat răspunsul IKE_AUTH 3 [ EAP/REQ/PEAP ]
 charon-nm[5070]: 11[TLS] a negociat TLS 1.2 folosind suita TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
 charon-nm[5070]: 11[ENC] generează cererea IKE_AUTH 4 [ EAP/RES/PEAP ]
 charon-nm[5070]: 11[NET] trimitere pachet: de la 192.168.2.35[58480] la 92.38.138.139[4500] (67 octeți)
 charon-nm[5070]: 12[NET] pachet primit: de la 92.38.138.139[4500] la 192.168.2.35[58480] (1061 octeți)
 charon-nm[5070]: 12[ENC] a analizat răspunsul IKE_AUTH 4 [ EAP/REQ/PEAP ]
 charon-nm[5070]: 12[ENC] generează cererea IKE_AUTH 5 [ EAP/RES/PEAP ]
 charon-nm[5070]: 12[NET] trimitere pachet: de la 192.168.2.35[58480] la 92.38.138.139[4500] (67 octeți)
 charon-nm[5070]: 13[NET] pachet primit: de la 92.38.138.139[4500] la 192.168.2.35[58480] (747 de octeți)
 charon-nm[5070]: 13[ENC] a analizat răspunsul IKE_AUTH 5 [ EAP/REQ/PEAP ]
 charon-nm[5070]: 13[TLS] a primit certificatul de server TLS „C=FR, ST=Radius, O=Example Inc., CN=Example Server Certificate, [email protected]”
 charon-nm[5070]: 13[TLS] a primit certificatul intermediar TLS „C=FR, ST=Radius, L=Undeva, O=Example Inc., [email protected], CN=Exemplu de autoritate de certificare”
 charon-nm[5070]: 13[CFG] folosind certificatul „C=FR, ST=Radius, O=Example Inc., CN=Example Server Certificate, [email protected]”
 charon-nm[5070]: 13[CFG] utilizând un certificat intermediar neîncrezat „C=FR, ST=Radius, L=Undeva, O=Example Inc., [email protected], CN=Example Certificate Authority”
 charon-nm[5070]: 13[CFG] certificat de subiect invalid (valabil de la 12 aprilie 17:41:01 2021 până la 11 iunie 17:41:01 2021)
 charon-nm[5070]: 13[TLS] nu a fost găsită nicio cheie publică TLS pentru serverul „%any”
 charon-nm[5070]: 13[TLS] trimite alertă TLS fatală „certificat necunoscut”
 charon-nm[5070]: 13[ENC] generează cererea IKE_AUTH 6 [ EAP/RES/PEAP ]
 charon-nm[5070]: 13[NET] trimitere pachet: de la 192.168.2.35[58480] la 92.38.138.139[4500] (74 de octeți)
 charon-nm[5070]: 14[NET] pachet primit: de la 92.38.138.139[4500] la 192.168.2.35[58480] (65 octeți)
 charon-nm[5070]: 14[ENC] a analizat răspunsul IKE_AUTH 6 [ EAP/FAIL ]
 charon-nm[5070]: 14[IKE] a primit EAP_FAILURE, autentificarea EAP a eșuat

Totul arată bine până când la răspunsul 5 primesc un certificat ciudat. Nu știu exact cum decurge protocolul PEAP și ce ar trebui să se întâmple pe acel pas, dar conexiunea funcționează pe Windows, așa că presupun că este o problemă din partea mea.

280
0 + 0
Puncte:1
avatar Server
drapel cn
ecdsa 
charon-nm[5070]: 13[CFG] certificat de subiect invalid (valabil de la 12 aprilie 17:41:01 2021 până la 11 iunie 17:41:01 2021)

Aparent, certificatul serverului RADIUS care a cerut EAP-PEAP a expirat, dar subiectul cu toate acele chestii „exemplu” oricum arată ciudat (dacă nu ai modificat asta). De ce ar accepta Windows asta, dacă de fapt folosește EAP-PEAP, nu știu.

Ai putea încerca să dezactivezi eap-peap plugin și sperăm că serverul acceptă alte metode EAP (de exemplu, EAP-MD5 sau EAP-MSCHAPv2). Pentru a face acest lucru, adăugați următoarele la strongswan.conf:

charon-nm {
  pluginuri {
    eap-peap {
      sarcina = nu
    }
  }
}
0 + 0
drapel us
Morse
Da, dezactivarea eap-peap a funcționat. Practic, orice alt protocol a funcționat. Ar putea exista un motiv pentru care configurația eap-peap este întreruptă? Nu cred că au făcut-o intenționat. De asemenea, există o modalitate de a dezactiva pluginul pentru o singură conexiune? Este greșit să îl dezactivați la nivelul întregului sistem pentru un singur server. Nu contează pentru mine, din moment ce nu plănuiesc să fac alte conexiuni IKEv2, dar totuși.
0
Răspunde
drapel cn
ecdsa
Chestia aia „exemplu” arată ca un certificat de testare. Deci, poate că nici măcar nu sunt conștienți că este încă activat sau configurat greșit (posibil să funcționeze doar cu alți clienți, fie pentru că ignoră certificatul, fie pentru că nu acceptă EAP-PEAP). Este prima metodă pe care o solicită serverul, totuși, nu este că solicită una diferită, iar clientul cere trecerea la ea. Alte metode EAP (de exemplu, cele enumerate mai sus) nu folosesc certificate pe serverul RADIUS, deci... Și nu, metodele EAP nu pot fi dezactivate pe conexiune. Este posibil să selectați o metodă în configurațiile de conexiune, dar nu prin NM.
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.