IKEv2 adresa serverului vs identitate: ce verifică de fapt clientul

Un gateway care își schimbă adresa poate continua să funcționeze în timp ce același gateway din spatele unui nou certificat se oprește și se întâmplă și invers. Adresa îi spune clientului unde să trimită pachetele; identitatea autentificată îi spune clientului dacă peer-ul care răspunde este cel în care ar trebui să aibă încredere. IKEv2 le păstrează ca două câmpuri separate, ceea ce este util odată ce încetați să le tratați ca pe un șir. De asemenea, sunt configurate în locuri diferite, astfel încât unul poate fi corect în timp ce celălalt este greșit.

Verificați-le în această ordine și opriți-vă la prima nepotrivire, deoarece verificările ulterioare presupun că cele anterioare au trecut.

În primul rând, care valoare este adresa

Adresa de conexiune este orice apelează clientul: un IP, un nume DNS care se rezolvă la unul sau un front-end cu încărcare echilibrată. Adica informatii despre transport si nimic mai mult. Identitatea rulează în încărcătura utilă de identificare IKEv2 și apoi este comparată cu certificatul de peer. Un nume DNS în caseta de adresă nu devine identitatea așteptată, iar un IP brut nu devine identitate doar pentru că socketul este conectat la acesta.

În termeni strongSwan, adresa este right sau left, iar identitatea așteptată este rightid sau leftid și asta descrie documentația de configurare IKEv2. Dacă ați editat doar adresa, ați configurat jumătate din pereche.

În al doilea rând, ce poate dovedi certificatul

Identitatea are un tip, iar certificatul trebuie să poarte un nume corespunzător. O identitate DNS este satisfăcută de o intrare dNSName în extensia de nume alternativă a subiectului; o identitate IP necesită o intrare iPAddress. Un certificat emis pentru vpn.example.com nu dovedește nimic despre adresa literală 203.0.113.10, iar unul emis pentru acea adresă nu dovedește nimic despre nume. Prin urmare, reemiterea pentru un nume diferit nu este o înlocuire, chiar și atunci când aceeași cheie și CA sunt reutilizate.

Clienții moderni ignoră numele comun atunci când există un nume alternativ al subiectului și mulți îl ignoră în totalitate. Dacă lista SAN nu conține valoarea pe care clientul o verifică, strângerea de mână eșuează după ce certificatul a fost deja acceptat ca demn de încredere, motiv pentru care jurnalul se citește ca o eroare de identitate și nu ca o eroare de încredere.

În al treilea rând, modul în care fiecare client afirmă așteptările

Windows preia numele serverului sau adresa pe care ați introdus-o și necesită ca certificatul să se potrivească cu el, așa că introducerea unui IP creează o așteptare IP. Clientul IKEv2 al lui Android se comportă în același mod și ambii resping un certificat valid, de încredere public, care denumește o altă gazdă. Un profil poate începe să eșueze doar pentru că cineva a înlocuit numele de gazdă cu adresa sa în timpul unei migrări. Priviți ce a cerut clientul înainte de a vă uita la ce conține certificatul.

Pe strongSwan așteptarea este explicită: setați rightid la identitatea pe care o prezintă de fapt serverul, care poate diferi de dreapta. Setarea lui %any acceptă orice oferă peer-ul și elimină exact cecul pe care încercați să îl păstrați.

În al patrulea rând, autentificarea utilizatorului separat de identitatea de peer

Autentificarea EAP și identitatea serverului răspund la diferite întrebări. O identitate EAP, cum ar fi [email protected], spune cine este utilizatorul, după ce clientul a decis că serverul este cel potrivit. Rotirea acelei parole nu poate remedia o nepotrivire a identității de la egal la egal, deoarece conexiunea nu ajunge niciodată la etapa de conectare a utilizatorului.

Un raport igienizat ar trebui să numească ambele: identitatea pe care clientul o aștepta, identitatea prezentată de server și intrările SAN ale certificatului.

În al cincilea rând, schimbați-l printr-un canal verificat

Când gateway-ul se mută în mod legitim, actualizați mai întâi adresa și lăsați identitatea în pace, pentru că acesta este cazul IKEv2 se descurcă bine. Când identitatea în sine se schimbă, tratați-o ca pe un eveniment de încredere și obțineți noua valoare de la o sursă în care aveți deja încredere, nu de la punctul final care eșuează în prezent. Un mesaj transmis prin conexiunea pe care încercați să o validați nu este o dovadă a conexiunii respective.

Înregistrați împreună adresa finală, identitatea și lista SAN în notele de profil. Următoarea persoană care atinge certificatul va vedea apoi care dintre cele trei are voie să se miște.