Que inclúe unha proposta IPsec? Campos de IKE e ESP

IKE arrinca, ambos os pares anuncian AES e o túnel segue fallando con NO_PROPOSAL_CHOSEN. O rexistro nomea a proposta pero non o campo que non coincidiu. Unha proposta é unha oferta completa, e un só campo incompatible invalida toda a combinación en lugar de só esa liña. Leela como un saco de eleccións independentes de algoritmos é a razón habitual pola que o desaxuste permanece invisible.

Dúas negociacións con listas de propostas separadas

IKEv2 constrúe dúas asociacións de seguridade. A primeira é a IKE SA, que protexe o propio intercambio de control, e a segunda é a CHILD SA, que transporta o seu tráfico por ESP. Cada unha ten a súa propia lista de propostas, e un par pode aceptar unha e rexeitar a outra.

Esa división explica unha confusión habitual: unha IKE SA que funciona só demostra que os algoritmos da canle de control coincidiron. Se a proposta CHILD falla, o túnel non transporta nin un paquete aínda que a primeira fase estea completada e os rexistros se vexan sans na parte superior.

A orde dentro de cada lista tamén importa. O respondedor elixe entre as ofertas ordenadas do iniciador, así que mover unha entrada amplamente compatible por riba dunha estreita cambia que conxunto se instala sen cambiar ningún nome de algoritmo. Fixe esa orde na configuración en lugar de confiar nos valores predeterminados. Unha orde estable tamén fai que a comparación de rexistros entre sitios teña sentido.

Que campos pertencen a que proposta

O conxunto de campos é pequeno, pero non é idéntico nas dúas negociacións. Lea a táboa fila por fila, porque un campo dunha columna pode faltar na outra. A sintaxe varía segundo a implementación; a documentación de propostas de strongSwan é unha referencia concreta.

O campo de cifrado nomea o cifrador e, na maioría das sintaxes, a súa lonxitude de chave. O campo de integridade nomea o hash usado para autenticar o texto cifrado, e o PRF nomea a función que deriva material de chave para a IKE SA. O grupo DH establece material secreto compartido novo, por iso aparece nos dous lados pero con fins distintos.

Os números de secuencia estendidos pertencen só á ruta de datos. Amplían o espazo de secuencia e negócianse como parte da proposta CHILD, así que un desaxuste alí rexeita unha oferta CHILD mentres deixa intacta a IKE SA.

Como se selecciona unha oferta completa

Cada proposta é un conxunto, e o respondedor busca un conxunto onde cada campo obrigatorio sexa aceptable. Dúas listas poden conter ambas AES e SHA-256 e aínda así non ter ningunha entrada compatible, porque a lonxitude de chave, o PRF ou o grupo DH difiren. A comparación faise por proposta, non por algoritmo.

Cando nada coincide, o respondedor envía NO_PROPOSAL_CHOSEN co tipo de SA que fallou. Lea a que lista de propostas se refire o aviso antes de editar a configuración; cambiar os algoritmos de ESP cando se rexeitou a proposta IKE desperdicia un ciclo de depuración.

Paga a pena coñecer o comportamento de selección cando axusta un perfil. Algunhas implementacións prefiren a orde do iniciador, outras reordenan segundo a política local, así que un conxunto que funciona entre dous provedores pode desaparecer cando invirte que lado inicia a conexión.

AEAD elimina un campo en lugar de engadir un

AES-GCM e ChaCha20-Poly1305 autentican e cifran nunha soa operación. Cando se selecciona calquera deles para ESP, o algoritmo de integridade non se negocia por separado, porque a construción AEAD xa o cobre. Por tanto, unha proposta que combina AES-GCM con SHA-256 é redundante no mellor caso e rexeitada no peor.

O PRF segue sendo independente no lado de IKE, xa que deriva chaves para a canle de control en lugar de protexer as cargas útiles. Por iso unha proposta IKE pode combinar lexitimamente un cifrador AEAD cun PRF e un grupo DH, mentres que a proposta ESP correspondente só enumera o cifrador AEAD e o grupo PFS opcional.

A lonxitude de chave forma parte do token de cifrado, así que AES-128-GCM e AES-256-GCM son ofertas distintas. Un perfil copiado dunha guía que asumía chaves de 256-bit non coincidirá cun extremo configurado para 128-bit, aínda que ambas as liñas digan AES-GCM. Dous pares poden acordar a familia de cifradores e aínda así rexeitarse polo número que segue o guión.

Lea a SA instalada, non a configuración

A lista de propostas configurada é unha oferta; a SA instalada é o resultado. En strongSwan e un núcleo Linux, ambas as vistas están dispoñibles:

sudo swanctl --list-sas
sudo ip xfrm state
sudo ip xfrm policy

swanctl --list-sas imprime os algoritmos negociados por SA, incluído se o CHILD usa AEAD. ip xfrm state mostra o que o núcleo instalou realmente, e é o lugar para confirmar que unha renovación de chaves non recaeu nun conxunto distinto do que documentou.

Garde esa saída xunto á configuración despois dunha corrección. Cando unha actualización do cliente cambia os seus valores predeterminados, o conxunto rexistrado dálle unha liña base para comparar, e a comparación sinala o campo que se moveu en lugar de reiniciar a investigación desde o principio.