Por que o teu túnel IPsec funciona ata o primeiro cambio de clave de CHILD SA

O túnel levantouse, o ping respondeu e todos deron o visto e prace. Catro horas despois a sesión cae, os pares rexistran un erro de proposta ou de intercambio de claves, e a primeira suposición é que algo cambiou na rede. Nada cambiou. Un túnel que transporta tráfico demostrou que os dous pares coinciden en como autenticarse e como protexer a primeira asociación filla, e non demostrou nada sobre o intercambio de claves que esixirán na renovación. O desaxuste está no oco entre eses dous eventos.

Conectado non significa que a configuración de PFS coincida

Con IKEv2, a primeira asociación filla créase durante o intercambio de autenticación, e as súas claves derívanse do material que a asociación IKE xa produciu. Para esa filla non ocorre un intercambio Diffie-Hellman aparte, así que unha política que o esixa na renovación non se proba no levantamento.

A renovación é outro intercambio. Cando se renova a clave dunha asociación filla, os pares poden realizar un intercambio de claves novo co grupo que nomean as súas propostas, e ese é o primeiro momento en que se comparan os axustes do grupo. Por iso dous pares que non coinciden poden autenticarse, instalar unha asociación filla e pasar tráfico, e despois fallar na renovación.

Onde se agocha o desaxuste na cadea da proposta

En strongSwan o grupo engádese á proposta filla, e por iso unha cadea como aes256gcm16-prfsha256-ecp256 parece unha elección de cifrado pero tamén arrastra un requisito de intercambio de claves. Un par que só ofrece aes256gcm16-prfsha256 non ten ese requisito, e as dúas listas coinciden no cifrado pero discrepan no intercambio.

Le a proposta filla e a proposta IKE como listas separadas. Un grupo que aparece na lista IKE non di nada sobre a lista filla, e editar unha mentres se le a outra é a forma habitual de que isto se escape.

Le o fallo, non o ficheiro que editaches

Atopa o notify que rematou o intercambio. Unha renovación de clave filla que devolve «ningunha proposta aceptable» apunta ás listas de propostas; unha solicitude de renovación que nunca recibe resposta apunta ao camiño ou a un par que deixou de escoitar. Eses dous necesitan correccións distintas, e a redacción da liña de rexistro sepáraos.

Confirma a configuración en execución e non a do disco. Un ficheiro gardado pero non cargado, ou unha conexión relida desde outro include, producirán un desaxuste que ningunha cantidade de edición do ficheiro visible pode arranxar.

Tres eventos aos que todos chaman renovación de clave

A renovación de clave da asociación IKE, a reautenticación IKE e a renovación de clave da asociación filla son operacións separadas con regras de proposta separadas. Un fallo informado nunha delas non di nada directamente sobre as outras, e un rexistro que as mestura lise como unha única avaría recorrente cando son tres.

Fíxate en que evento nomea o par e despois revisa as propostas só para ese evento. Cambia unha lista, recarga e forza o mesmo evento outra vez. Se o rexistro nomea unha reautenticación, a proposta IKE é a que hai que ler. Se nomea unha renovación de clave filla, a proposta filla leva o grupo que importa.

Desactivar a renovación non é unha solución

Pór o tempo de renovación de clave a cero suprime o intercambio que falla, e o túnel sobrevive ata que se desmonta ou o par se reinicia. O que compraches é unha clave máis duradeira e un desaxuste que te volverá atopar durante unha migración, unha auditoría ou unha actualización do provedor. O mesmo vale para vidas útiles estiradas moi máis alá da política que espera o outro lado.

Aliña as propostas. Escolle un grupo que implementen ambos os pares, pono na proposta filla nos dous extremos e mantén a política de renovación dentro do rango que a organización realmente require.

Demostrao co intercambio que fallou

Acorta o tempo de renovación de clave filla nunha ventá de mantemento para que o evento chegue en minutos en lugar de horas, ou dispara unha renovación manual. Despois vixía unha renovación correcta e confirma que o tráfico segue pasando por ela, porque un novo handshake que instala unha asociación filla pero deixa caer o fluxo da aplicación é outro defecto.

Despois restaura a vida útil normal e conserva os dous rexistros de eventos, o fallido e o correcto. A proba que queres é que a conexión sobreviva ao seu propio ciclo de vida, non que sobrevivise a un ping.