Planifique os axustes de IKEv2 para máis dun cliente

Un perfil que funciona nun escritorio é unha proba exitosa dun só cliente. Non é un despregamento multiplataforma, e tratalo como tal produce o patrón de asistencia coñecido: Windows conéctase, o teléfono falla na comprobación de identidade e o portátil xestionado reconéctase cada vez que espertar. As diferenzas son reais e na súa maioría previsibles, por iso o plan debe ser unha matriz e non unha captura de pantalla.

Decida primeiro o contrato de identidade

Documente a identidade do servidor, a confianza no certificado e o método de autenticación do cliente antes de falar de algoritmos. Eses tres elementos deciden se un cliente pode autenticarse, e son as partes que as plataformas expresan de forma distinta.

Comprobe como cada plataforma nomea o identificador esperado e como trata os nomes alternativos do suxeito. Un perfil que acepta un nome de servidor nun cliente pode rexeitar o mesmo certificado noutro porque o campo do identificador énchese cun valor distinto.

Despois escolla a intersección criptográfica

Compare as propostas que pode ofrecer cada cliente compatible e escolla unha intersección moderna que a pasarela tamén permita. Non active unha lista antiga sobredimensionada para que se conecte un só dispositivo vello, porque esa lista convértese no valor predeterminado da pasarela para todos os que veñen despois. Anote por que cada opción antiga segue aí. Se ninguén pode nomear o dispositivo que a necesita, non é un requisito.

Manteña separados os axustes de IKE e CHILD no plan. Unha proposta aceptable para o intercambio IKE non é automaticamente aceptable para o tráfico protexido, e ambas se negocian por separado. Unha pasarela que acepta unha proposta nunha capa aínda pode rexeitala na outra, e o rexistro mostrará un fallo que parece como se a primeira capa funcionase.

Aprovisione as credenciais mediante un proceso verificado e manteña o contrasinal de usuario, o segredo compartido e a clave privada do cliente nos seus propios campos. O ensaio e erro en caixas con nomes parecidos é a forma en que unha proba que funciona se converte nunha non reproducible.

Probe o ciclo de vida, non o estado estable

Para cada cliente, probe a autenticación inicial, a aplicación prevista, a resolución de DNS e a cobertura de familias de enderezos. Despois exercite as partes que só aparecen máis tarde: renovación, suspensión e un cambio de rede normal.

A compatibilidade con MOBIKE e o comportamento de reautenticación poden diferir do resultado estable que acaba de medir. Rexistre o evento e o estado da asociación nese momento, non só se a interface acaba parecendo conectada.

Defina que pode facer o tráfico directo mentres a VPN non está dispoñible. É unha decisión de política separada de se o cliente se reconecta, e a maioría dos despregamentos responden a segunda pregunta mentres ignoran a primeira. Escriba a resposta nas notas de despregamento xunto aos nomes dos perfís. Alguén a necesitará durante unha interrupción e non terá tempo de reconstruíla.

Use comprobacións de identidade do servidor cando unha plataforma non estea de acordo

Cando un perfil funciona nunha plataforma e outra rexeita o seu nome, compare o identificador que o cliente enviou realmente cos identificadores que leva o certificado. Esa comparación resolve a maioría destes casos máis rápido que cambiar as listas de cifrado.

Garde a matriz probada coa orixe da configuración e o procedemento de actualización. Cando remate o soporte dun cliente antigo, retire a súa excepción deliberadamente en lugar de deixar axustes de compatibilidade máis débiles ocultos na pasarela para que os atope a próxima auditoría. A documentación de IKEv2 de strongSwan é unha referencia útil sobre como se configuran os intercambios.