Què inclou una proposta IPsec? Camps d'IKE i d'ESP

IKE arrenca, tots dos parells anuncien AES i el túnel encara falla amb NO_PROPOSAL_CHOSEN. El registre anomena la proposta però no el camp que no ha coincidit. Una proposta és una oferta completa, i un sol camp incompatible invalida tota la combinació, no només aquella línia. Llegir-la com un sac d'eleccions independents d'algoritmes és la raó habitual per la qual el desajust roman invisible.

Dues negociacions amb llistes de propostes separades

IKEv2 construeix dues associacions de seguretat. La primera és la IKE SA, que protegeix el mateix intercanvi de control, i la segona és la CHILD SA, que transporta el vostre trànsit per ESP. Cadascuna té la seva llista de propostes, i un parell pot acceptar-ne una i rebutjar l'altra.

Aquesta divisió explica una confusió habitual: una IKE SA que funciona només demostra que els algoritmes del canal de control han coincidit. Si la proposta CHILD falla, el túnel no transporta cap paquet tot i que la primera fase s'hagi completat i els registres semblin sans a la part superior.

L'ordre dins de cada llista també importa. El responedor tria entre les ofertes ordenades de l'iniciador, de manera que moure una entrada àmpliament compatible per sobre d'una de estreta canvia quin conjunt s'instal·la sense canviar cap nom d'algoritme. Fixeu aquest ordre a la configuració en lloc de confiar en els valors per defecte. Un ordre estable també fa que la comparació de registres entre llocs tingui sentit.

Quins camps pertanyen a quina proposta

El conjunt de camps és petit, però no és idèntic a les dues negociacions. Llegiu la taula fila a fila, perquè un camp d'una columna pot faltar a l'altra. La sintaxi varia segons la implementació; la documentació de propostes de strongSwan n'és una referència concreta.

El camp de xifratge anomena el xifrador i, en la majoria de sintaxis, la longitud de clau. El camp d'integritat anomena el hash emprat per autenticar el text xifrat, i el PRF anomena la funció que deriva material de clau per a la IKE SA. El grup DH estableix material secret compartit nou, i per això apareix als dos costats però amb finalitats diferents.

Els números de seqüència estesos només pertanyen al camí de dades. Amplien l'espai de seqüència i es negocien com a part de la proposta CHILD, de manera que un desajust allà rebutja una oferta CHILD mentre deixa la IKE SA intacta.

Com es tria una oferta completa

Cada proposta és un conjunt, i el responedor busca un conjunt on cada camp obligatori sigui acceptable. Dues llistes poden contenir totes dues AES i SHA-256 i no tenir cap entrada compatible, perquè la longitud de clau, el PRF o el grup DH difereixen. La comparació es fa per proposta, no per algoritme.

Quan no coincideix res, el responedor envia NO_PROPOSAL_CHOSEN amb el tipus d'SA que ha fallat. Llegiu a quina llista de propostes es refereix l'avís abans d'editar la configuració; canviar els algoritmes d'ESP quan s'ha rebutjat la proposta IKE malbarata un cicle de depuració.

Val la pena conèixer el comportament de selecció quan ajusteu un perfil. Algunes implementacions prefereixen l'ordre de l'iniciador, d'altres reordenen segons la política local, així que un conjunt que funciona entre dos proveïdors pot desaparèixer quan invertiu quin costat inicia la connexió.

AEAD elimina un camp en lloc d'afegir-ne un

AES-GCM i ChaCha20-Poly1305 autentiquen i xifren en una sola operació. Quan se selecciona qualsevol dels dos per a ESP, l'algoritme d'integritat no es negocia per separat, perquè la construcció AEAD ja el cobreix. Per tant, una proposta que combina AES-GCM amb SHA-256 és redundant en el millor cas i rebutjada en el pitjor.

El PRF continua sent separat al costat d'IKE, ja que deriva claus per al canal de control en lloc de protegir les càrregues. És per això que una proposta IKE pot combinar legítimament un xifrador AEAD amb un PRF i un grup DH, mentre que la proposta ESP corresponent només llista el xifrador AEAD i el grup PFS opcional.

La longitud de clau forma part del testimoni de xifratge, així que AES-128-GCM i AES-256-GCM són ofertes diferents. Un perfil copiat d'una guia que assumia claus de 256-bit no coincidirà amb un extrem configurat per a 128-bit, encara que les dues línies diguin AES-GCM. Dos parells poden acordar la família de xifradors i tot i així rebutjar-se pel número que segueix el guió.

Llegiu l'SA instal·lada, no la configuració

La llista de propostes configurada és una oferta; l'SA instal·lada és el resultat. A strongSwan i al nucli de Linux, totes dues vistes són disponibles:

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

swanctl --list-sas imprimeix els algoritmes negociats per SA, incloent si el CHILD fa servir AEAD. ip xfrm state mostra què ha instal·lat realment el nucli, i aquest és el lloc per confirmar que una renovació de claus no ha reculat a un conjunt diferent del que heu documentat.

Deseu aquesta sortida al costat de la configuració després d'una correcció. Quan una actualització del client canvia els valors per defecte, el conjunt enregistrat us dona una línia base per comparar, i la comparació assenyala el camp que s'ha mogut en lloc de reiniciar la investigació des del principi.