Recurg să cer ajutor după o perioadă brutală de timp pentru a remedia problemele de conexiune dintre client și server.
Necazuri
Clienții Mac OS X Catalina și Linux funcționează bine conectându-se la server, dar Big Sur nu. Nu am testat încă Mojave (ceea ce oricum ar fi mai lax din punct de vedere al securității), și nici nu am testat Windows 10. Motivul pentru toți clienții diferiți este complex, dar în esență suntem o mică companie de consultanță unde oamenii pot alege platforma lor, deși Mojave mai veche, este pur și simplu pentru că nu s-au actualizat încă. În orice caz, asta îmi face munca (ca administrator de sistem) semnificativ mai complexă, dar iată.
Servere
- RedHat 8.2. Unul este configurat în modul FIPS, altul nu, datorită OpenVPN. Ambele rulează, desigur, Libreswan.
- Instalare implicită Libreswan de la yum. Versiune: 3.29-7
- IKEv2 folosind NSS, cu certificate RSA pentru autentificare.
- Infrastructură CA rădăcină/intermediară personalizată. CRL este valid, integrat și stocat în NSS.
- Firewall, tabelul de rutare, setările sysctl etc., toate par a fi configurate corect. Folosesc iptables cu un set de reguli personalizate, mai degrabă decât firewalld.
Clienții
- Mac OS X Mojave, Catalina și Big Sur
- Windows 10
- Clienți Ubuntu și RedHat Linux
Configurare
Partea client (Mobileconfig pentru a le împacheta pe toate)
Folosesc clientul de rețea încorporat, fără clienți externi pentru a simplifica lucrurile. Majoritatea clienților cu plată nu par să accepte IKEv2 oricum, deși am încercat pe scurt GreenBow VPN.
Fila Sarcină utilă VPN (Apple Configurator 2, ambele Catalina/Big Sur aceleași date/configurație)
- Tip conexiune: IKEv2
- Identificatorul serverului/la distanță: IP-ul serverului (certificatul serverului are IP SubjectAltName: IP server)
- Identificator local: adresa de e-mail a utilizatorului pare să funcționeze bine aici presupunând că nu este Big Sur. Setarea ca goală a funcționat și la un moment dat. Nu sunt sigur ce am schimbat sau dacă chiar eu am făcut-o, dar e-mailul trebuie să fie prezent acum.Am început să adaug acest lucru ca subiectAltName și partea clientului de e-mail, la sugestia unui coleg.
- Autentificarea mașinii este un certificat, RSA pentru tip și numele emitentului CA este setat corect.
- Toate celelalte lucruri de securitate, cum ar fi parametrii DH și cripto, sunt de grad mediu, AES-256 și DH21. Inițial am configurat cu AES-256-GCM pentru a încerca să evit orice legat de bug-ul de trunchiere SHA2. Nici asta nu merge.
Fila Sarcină utilă certificate
- Am configurat asta în moduri diferite. Totuși, aici se aplică chestii standard: O identitate .p12, cu atât o parolă cu cheie privată pentru utilizator, cât și o parolă de export (ambele 23 de caractere lungime). Durata este de 920 de zile. Am citit undeva că aceasta ar putea fi problema, dar jurnalele pe care le-am găsit din partea clientului nu reflectă faptul că sunt supărată de perioada de valabilitate. De asemenea, am testat un timp de certificat mai scurt, 500 de zile pentru a vedea dacă a făcut ceva bun; Nu a făcut-o.
- CA rădăcină/intermediară a fost inclusă în două configurații aici în timpul creării PKCS12: doar CA intermediară, față de lanțul ca complet. Niciuna dintre configurații nu a funcționat în Big Sur.
- Importate manual CA-urile rădăcină/intermediare; Le-am marcat pe ambele ca fiind de încredere pentru toate cazurile de utilizare. Le-am importat/copiat din brelocul de conectare, în brelocul de sistem. Am făcut tot ce am găsit pe acest subiect și nimic nu a funcționat.
Configurare partea serverului
auto=adăugați
authby=rsasig
dpddelay=30
dpdtimeout=120
dpdaction=clear
fragmentare=nu (Big sur dă o eroare diferită cu aceasta activată)
modecfgpull=da
modecfgdns="DNS intern"
pfs=da
rekey=da
durata de viață=8h
ikelifetime=8h
stânga=IP PUBLIC
leftcert=IP PUBLIC (Am încercat aici diverse forme; @PUB... etc)
leftid=IP PUBLIC
leftsendcert=intotdeauna
leftsubnet=0.0.0.0/0
leftrsasigkey=%cert
leftmodecfgserver=da
rightaddresspool=Bag de adrese interne
dreapta=%oricare
rightrsasigkey=%cert
rightmodecfgclient=da
Jurnalele din partea clientului
În primul rând, singurul pop-up de eroare GUI pe care îl văd aici la încercarea de conectare este „Autentificarea utilizatorului eșuat”. Apoi folosesc următoarea comandă pentru a obține jurnale mai bune/mai utile pe Mac OS X:
jurnal show --start DATE --predicate 'senderImagePath contains[cd] "NetworkExtension"'
Acești bușteni sunt, în mare parte, 1000 de linii de gunoi. Acestea fiind spuse, acest lucru pare relevant:
2021-08-10 0x1aa44 Eroare 0x0 2375 0 NEIKEv2Provider: (NetworkExtension) [com.apple.networkextension: =] Certificatevaluation errorResultFaurerTcoverilResultKustFaurerTcoverrust
2021-08-10 0x1aa44 Eroare 0x0 2375 0 NEIKEv2Provider: (NetworkExtension) [com.apple.networkextension:] Certificatul nu este de încredere
2021-08-10 0x1aa44 Eroare 0x0 2375 0 NEIKEv2Provider: (NetworkExtension) [com.apple.networkextension:] Datele certificatului nu au putut fi autentificate
2021-08-10 0x1aa44 Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 0 Â Â NEIKEv2Provider: (NetworkExtension) [com.apple.networkextension:] [2BC.2F20CF18C72F202C202020202010 > Eroare deconectată (null) -> Error Domain=NEIKEv2ErrorDomain Code=8 „Autentificare: Datele de autentificare a certificatului nu au putut fi verificate” UserInfo={NSLocalizedDescription=Autentificare: Datele de autentificare a certificatului nu au putut fi verificate}
2021-08-10 0x1aa44 Eroare 0x0 2375 0 NEIKEv2Provider: (NetworkExtension) [com.apple.networkextension:] IKEv2,237C72F267C72F267C72F18C72F17C72F procesează pachetul IKE Auth (conectare)
Note
Așa cum este descris în comentariile anterioare despre configurarea clientului .. Am făcut munca pentru a face acest lucru corect, aparent. Arată chiar și pe afișajul Apple Configurator că acesta este un pachet de configurare acceptabil. Evident că nu este semnat de Apple, dar nicio surpriză.Configurația standard, manuală IKEv2 pur și simplu nu este suficient de cuprinzătoare pentru nevoile noastre. Și pur și simplu nu funcționează, pentru a fi sigur, nici. Cel puțin pentru ceva mai complex decât o jucărie pentru copii a unui server.
Am cercetat și problema transparenței certificatelor; Din păcate, aceasta nu este o soluție pentru Mac OS X. Este doar o soluție aplicabilă dispozitivelor precum iPad-uri etc. Încercarea de a instala un mobileconfig pe OS X cu CT activat și cu excepția anumitor certificate, este respins și nu va instala mobileconfig.
Jurnalele pe partea serverului
Am serverul extern în modul de depanare, pentru a genera mai multe jurnale decât în mod normal. Acestea fiind spuse, în acest caz, serverul pare perfect mulțumit de tranzacție, partea clientului este cea care urăște ........ Ceva. nu stiu ce.
Iată ce văd totuși:
10 august serverName pluto[]: | CA oferit: „C=US, ST=US, O=companyName, OU=OUCA, CN=CAName, [email protected]”
10 august serverName pluto[]: „la distanță”[51] serverIP #90: ID-ul peer în modul IKEv2 este ID_USER_FQDN: „[email protected]”
10 august serverName pluto[]: | a primit v2N_INITIAL_CONTACT
10 august serverName pluto[]: | A primit o notificare necunoscută/neacceptată v2N_NON_FIRST_FRAGMENTS_ALSO - ignorată
10 august serverName pluto[]: | a primit v2N_MOBIKE_SUPPORTED în timp ce nu a fost trimis
10 august serverName pluto[]: | a primit sarcina utilă CERTREQ; mergi să-l decodific
10 august serverName pluto[]: | CERT_X509_SIGNATURE CR:
10 august serverName pluto[]: | 10 81 9a c1 4c a6 94 70 ca d1 7d 77 e1 5a ab 36
10 august serverName pluto[]: | 93 3d cd 39
10 august serverName pluto[]: | Conținutul blob cert nu este binar ASN.1
10 august serverName pluto[]: | verificând sarcina utilă AUTH
10 august serverName pluto[]: | CA RSA obligatorie este „%any”
10 august serverName pluto[]: | verificarea codului de cheie RSA „serverIP” pentru potrivire cu „[email protected]”
10 august serverName pluto[]: | verificarea codului cheie RSA „C=US, ST=US, L=City, O=companyName, OU=OUCA, CN=UserCN, [email protected]” pentru potrivire cu „[email protected]”
10 august serverName pluto[]: | verificarea codului de cheie RSA „[email protected]” pentru potrivire cu „[email protected]”
10 august serverName pluto[]: | trusted_ca_nss: administrator A = 'C=US, ST=US, O=companyName, OU=OUCA, CN=CAName, [email protected]'
10 august serverName pluto[]: | CA emitentul cheie este „C=US, ST=US, O=companyName, OU=OUCA, CN=CAName, [email protected]”
10 august serverName pluto[]: | un control RSA Sig a trecut cu *AwEAAbi14 [certificate la distanță]
10 august serverName pluto[]: „la distanță”[51] serverIP #90: Autentificat folosind RSA
Jurnalele serverului arată că clientul Mac OS X Big Sur se autentifică corect. Apoi se construiește relația SA etc., așa cum ați vedea de obicei. Clientul, este cel care respinge din mână conexiunea. Ce nu inteleg este ce s-a schimbat intre Catalina, versus Big Sur ??
Nu am găsit informații despre această schimbare a sistemului de operare. Nu înțeleg de ce acesta nu este în font de 60 de puncte, îngroșat, pe prima pagină a site-ului Apple, că oh, da, fapt distractiv, am schimbat total modul în care funcționează IPSEC în această versiune a sistemului de operare. Și m-am săturat să-mi însângerez capul, fie să-mi smulg părul, fie să-l lovesc de perete în mod repetat.
Orice ajutor ar fi apreciat.
