Planifiqueu la configuració d’IKEv2 per a més d’un client

Un perfil que funciona en un escriptori és una prova satisfactòria d’un sol client. No és un desplegament multiplataforma, i tractar-lo com a tal produeix el patró de suport conegut: Windows es connecta, el telèfon falla a la comprovació d’identitat i l’ordinador portàtil gestionat es reconnecta cada cop que es desperta. Les diferències són reals i majoritàriament previsibles, per això el pla ha de ser una matriu i no una captura de pantalla.

Primer decidiu el contracte d’identitat

Documenteu la identitat del servidor, la confiança en el certificat i el mètode d’autenticació del client abans de parlar d’algoritmes. Aquests tres elements decideixen si un client pot autenticar-se, i són les parts que les plataformes expressen de manera diferent.

Comproveu com cada plataforma anomena l’identificador esperat i com tracta els noms alternatius del subjecte. Un perfil que accepta un nom de servidor en un client pot rebutjar el mateix certificat en un altre perquè el camp de l’identificador s’omple amb un valor diferent.

Després trieu la intersecció criptogràfica

Compareu les propostes que pot oferir cada client compatible i trieu una intersecció moderna que la passarel·la també permeti. No activeu una llista antiga massa gran perquè es connecti un sol dispositiu vell, perquè aquesta llista es converteix en el valor per defecte de la passarel·la per a tothom qui vingui després. Anoteu per què cada opció antiga encara hi és. Si ningú no pot anomenar el dispositiu que la necessita, no és un requisit.

Manteniu les opcions d’IKE i CHILD separades al pla. Una proposta acceptable per a l’intercanvi IKE no és automàticament acceptable per al tràfic protegit, i les dues es negocien per separat. Una passarel·la que accepta una proposta en una capa encara la pot rebutjar a l’altra, i el registre mostrarà un error que sembla que la primera capa ha funcionat.

Proporcioneu les credencials mitjançant un procés verificat i manteniu la contrasenya d’usuari, el secret compartit i la clau privada del client en camps propis. L’assaig i error en caixes amb noms semblants és com una prova que funciona es converteix en una de no reproduïble.

Proveu el cicle de vida, no l’estat estable

Per a cada client, proveu l’autenticació inicial, l’aplicació prevista, la resolució de DNS i la cobertura de famílies d’adreces. Després exerciteu les parts que només apareixen més tard: renovació, suspensió i un canvi de xarxa normal.

El suport de MOBIKE i el comportament de reautenticació poden diferir del resultat estable que acabeu de mesurar. Registreu l’esdeveniment i l’estat de l’associació en aquell moment, no només si la interfície acaba semblant connectada.

Definiu què pot fer el tràfic directe mentre la VPN no està disponible. És una decisió de política independent de si el client es reconnecta, i la majoria de desplegaments responen la segona pregunta mentre ignoren la primera. Escriviu la resposta a les notes de desplegament al costat dels noms dels perfils. Algú la necessitarà durant una interrupció i no tindrà temps de reconstruir-la.

Utilitzeu comprovacions d’identitat del servidor quan una plataforma no hi estigui d’acord

Quan un perfil funciona en una plataforma i una altra rebutja el seu nom, compareu l’identificador que el client ha enviat realment amb els identificadors que porta el certificat. Aquesta comparació resol la majoria d’aquests casos més de pressa que canviar les llistes de xifratge.

Conserveu la matriu provada amb la font de configuració i el procediment d’actualització. Quan acabi el suport per a un client antic, retireu-ne l’excepció deliberadament en lloc de deixar configuracions de compatibilitat més febles amagades a la passarel·la perquè la propera auditoria les trobi. La documentació d’IKEv2 de strongSwan és una referència útil sobre com es configuren els intercanvis.