iOS IKEv2 cara a strongSwan: ningunha proposta elixida, corrixa a lista

O iPhone levanta o túnel, a pasarela responde con nada e o teléfono mostra un fallo xenérico. O rexistro de strongSwan é máis concreto: ningunha proposta elixida. Esa mensaxe significa que as dúas listas de conxuntos de cifrado aceptables nunca se solaparon, así que o intercambio rematou antes de que comezase a autenticación. É un problema de coincidencia, e a solución é facer que as listas se crucen.

Onde declara a pasarela a súa política

strongSwan escribe a súa política na configuración, e o signo de exclamación final decide como se le esa política. Co signo, a lista é exhaustiva: aceptaranse esas entradas e nada máis. Sen el, a mesma liña é unha orde de preferencia, e o daemon pode escoller algo que non pretendía. Pregunte que forma está despregada antes de traducir nada, porque as dúas compórtanse distinto fronte ao mesmo cliente. Anote a liña exacta, signo incluído, e probe contra ela.

Un cliente que ofrece unha lista máis ampla aínda pode conectarse a unha pasarela fixada, sempre que unha combinación apareza nos dous lados. O que non pode ocorrer é unha negociación fóra do conxunto fixado.

Por iso un perfil copiado doutra aplicación VPN pode funcionar onde o seu non: a outra aplicación traía unha lista distinta.

Os nomes deben coincidir, non mellorar

Dúas traducións atrapan a quen traslada valores de strongSwan a iOS. O algoritmo de integridade escrito como SHA1 nunha proposta IKE viaxa na súa forma truncada, que iOS chama .SHA96. O grupo Diffie-Hellman escrito como modp1024 é group 2, que iOS chama .group2. Substituír por SHA-256 ou group 14 non negociará contra unha pasarela que só acepta o par antigo. O cliente debe describir o mesmo algoritmo, non un máis forte.

Defina eses valores explicitamente en NEVPNProtocolIKEv2. Os valores predeterminados poden ser máis amplos ou máis estreitos que o perfil que substitúe, e a diferenza só se ve cando falla o aperto de mans.

A proposta filla falla máis tarde e máis silenciosamente

Configure a asociación de seguridade filla ademais da de IKE. Cando só coinciden os parámetros IKE, o túnel autentícase e despois non transporta tráfico, o que é un fallo moito máis silencioso que un rexeitamento. Defina o cifrado, a integridade, o grupo e a vida útil da filla na mesma pasada. Manteña a vida útil do cliente no valor da pasarela ou por baixo, porque insistir nunha máis longa produce a mesma mensaxe de proposta non elixida por outra causa. Unha discrepancia alí vese idéntica a unha discrepancia de IKE no rexistro.

Comprobe se o perfil se autentica con certificados ou cun segredo compartido mentres está na configuración. Un rexeitamento de proposta e un rexeitamento de autenticación aparecen en liñas distintas, e arranxar o equivocado custa un día. Probe cunha conexión nova despois de cada cambio, unha variable á vez, porque o estado na caché oculta que parámetro se moveu.

Deixe o conxunto antigo só mentres faga falta

Fixar SHA-1 cun grupo de 1024 bits é unha ponte, non un destino. Ambos están obsoletos, e os clientes máis novos poden rexeitalos de plano, o que significa que o perfil fallará no seguinte dispositivo sen ningún cambio pola súa parte. Trate a fixación como temporal e dígao no rexistro.

Se strongSwan é seu, engada unha proposta moderna e deixe que ambos os extremos negocien cara arriba mentres a entrada antiga queda para dispositivos antigos. Lea a saída de estado do daemon para ver que conxunto usou realmente cada conexión. Despois retire a fixación do lado do cliente cando o par moderno estea confirmado. Un túnel que se levanta non é proba suficiente, porque pode levantarse co conxunto que intentaba retirar. A documentación de IKEv2 de strongSwan describe a sintaxe das propostas e o marcador estrito.