Planificați setări IKEv2 potrivite pentru mai mult de un client

Un profil funcțional pe un singur desktop este un test reușit al unui singur client. Nu este o implementare multiplatformă, iar tratarea lui ca atare produce tiparul de suport cunoscut: Windows se conectează, telefonul eșuează la verificarea identității, iar laptopul administrat se reconectează la fiecare trezire. Diferențele sunt reale și în mare parte previzibile, de aceea planul ar trebui să fie o matrice, nu o captură de ecran.

Mai întâi stabiliți contractul de identitate

Documentați identitatea serverului, încrederea în certificat și metoda de autentificare a clientului înainte de a discuta algoritmi. Aceste trei decid dacă un client se poate autentifica, și sunt exact părțile pe care platformele le exprimă diferit.

Verificați cum numește fiecare platformă identificatorul așteptat și cum tratează numele alternative ale subiectului. Un profil care acceptă un nume de server pe un client poate respinge același certificat pe altul, pentru că câmpul identificatorului este completat dintr-o altă valoare.

Apoi alegeți intersecția criptografică

Comparați propunerile pe care le poate oferi fiecare client acceptat și alegeți o intersecție modernă pe care o permite și gateway-ul. Nu activați o listă veche supradimensionată doar pentru ca un dispozitiv vechi să se conecteze, pentru că acea listă devine valoarea implicită a gateway-ului pentru toți cei care urmează. Notați de ce fiecare opțiune veche mai există. Dacă nimeni nu poate numi dispozitivul care are nevoie de ea, nu este o cerință.

Păstrați setările IKE și CHILD separate în plan. O propunere acceptabilă pentru schimbul IKE nu este automat acceptabilă pentru traficul protejat, iar cele două se negociază separat. Un gateway care acceptă o propunere la un strat o poate refuza la celălalt, iar jurnalul va arăta o eroare care pare că primul strat a reușit.

Furnizați acreditările printr-un proces verificat și păstrați parola de utilizator, secretul partajat și cheia privată a clientului în câmpurile lor. Încercările și erorile pe cutii cu nume similare sunt calea prin care un test funcțional devine nereproductibil.

Testați ciclul de viață, nu starea stabilă

Pentru fiecare client, testați autentificarea inițială, aplicația dorită, rezolvarea DNS și acoperirea familiilor de adrese. Apoi exersați părțile care apar doar mai târziu: reînnoirea, repausul și o schimbare normală de rețea.

Suportul MOBIKE și comportamentul la reautentificare pot diferi de rezultatul stabil pe care tocmai l-ați măsurat. Înregistrați evenimentul și starea asocierii în acel moment, nu doar dacă interfața pare în final conectată.

Definiți ce poate face traficul direct cât timp VPN-ul nu este disponibil. Este o decizie de politică separată de întrebarea dacă clientul se reconectează, iar majoritatea implementărilor răspund la a doua întrebare ignorând-o pe prima. Scrieți răspunsul în notele de implementare lângă numele profilelor. Cineva va avea nevoie de el în timpul unei întreruperi și nu va avea timp să îl reconstruiască.

Folosiți verificări de identitate a serverului când o platformă nu este de acord

Când un profil funcționează pe o platformă, iar alta îi respinge numele, comparați identificatorul trimis efectiv de client cu identificatorii pe care îi poartă certificatul. Această comparație rezolvă majoritatea acestor cazuri mai repede decât schimbarea listelor de cifruri.

Păstrați matricea testată împreună cu sursa configurației și procedura de actualizare. Când suportul pentru un client vechi se termină, eliminați excepția lui în mod deliberat, în loc să lăsați setări de compatibilitate mai slabe ascunse în gateway pentru următorul audit. Documentația strongSwan despre IKEv2 este o referință utilă despre modul în care sunt configurate schimburile.