Cosa comprende una proposta IPsec? Campi IKE ed ESP

IKE parte, entrambi i peer annunciano AES, e il tunnel fallisce comunque con NO_PROPOSAL_CHOSEN. Il registro nomina la proposta ma non il campo che non ha corrisposto. Una proposta è un'offerta completa, e un solo campo incompatibile invalida l'intera combinazione anziché solo quella riga. Leggerla come un sacco di scelte indipendenti di algoritmi è la ragione abituale per cui il disallineamento resta invisibile.

Due negoziazioni con liste di proposte separate

IKEv2 costruisce due associazioni di sicurezza. La prima è l'IKE SA, che protegge lo scambio di controllo stesso, e la seconda è la CHILD SA, che trasporta il vostro traffico tramite ESP. Ognuna ha la propria lista di proposte, e un peer può accettarne una e rifiutare l'altra.

Questa separazione spiega una confusione comune: un IKE SA funzionante dimostra solo che gli algoritmi del canale di controllo hanno corrisposto. Se la proposta CHILD fallisce, il tunnel non trasporta nemmeno un pacchetto, anche se la prima fase è completata e i registri sembrano sani in alto.

Anche l'ordine all'interno di ciascuna lista conta. Il responder sceglie tra le offerte ordinate dell'iniziatore, quindi spostare una voce ampiamente compatibile sopra una stretta cambia quale suite viene installata senza cambiare alcun nome di algoritmo. Fissate quell'ordine nella configurazione invece di affidarvi ai valori predefiniti. Un ordine stabile rende significativo anche il confronto dei registri tra siti.

Quali campi appartengono a quale proposta

L'insieme dei campi è piccolo, ma non è identico nelle due negoziazioni. Leggete la tabella riga per riga, perché un campo di una colonna può mancare nell'altra. La sintassi varia secondo l'implementazione; la documentazione delle proposte di strongSwan è un riferimento concreto.

Il campo di cifratura indica il cifrario e, nella maggior parte delle sintassi, la sua lunghezza di chiave. Il campo di integrità indica l'hash usato per autenticare il testo cifrato, e il PRF indica la funzione che deriva il materiale di chiave per l'IKE SA. Il gruppo DH stabilisce materiale segreto condiviso nuovo, ed è per questo che compare su entrambi i lati ma con scopi diversi.

I numeri di sequenza estesi appartengono solo al percorso dati. Ampliano lo spazio di sequenza e vengono negoziati come parte della proposta CHILD, quindi un disallineamento lì rifiuta un'offerta CHILD lasciando intatto l'IKE SA.

Come viene selezionata un'offerta completa

Ogni proposta è un insieme, e il responder cerca un insieme in cui ogni campo obbligatorio sia accettabile. Due liste possono entrambe contenere AES e SHA-256 e non avere comunque alcuna voce compatibile, perché la lunghezza di chiave, il PRF o il gruppo DH differiscono. Il confronto avviene per proposta, non per algoritmo.

Quando nulla corrisponde, il responder invia NO_PROPOSAL_CHOSEN con il tipo di SA che ha fallito. Leggete a quale lista di proposte si riferisce la notifica prima di modificare la configurazione; cambiare gli algoritmi ESP quando la proposta IKE è stata rifiutata spreca un ciclo di debug.

Vale la pena conoscere il comportamento di selezione quando regolate un profilo. Alcune implementazioni preferiscono l'ordine dell'iniziatore, altre riordinano secondo la politica locale, quindi una suite che funziona tra due fornitori può sparire quando invertite quale lato avvia la connessione.

AEAD rimuove un campo invece di aggiungerne uno

AES-GCM e ChaCha20-Poly1305 autenticano e cifrano in un'unica operazione. Quando uno dei due viene scelto per ESP, l'algoritmo di integrità non viene negoziato separatamente, perché la costruzione AEAD lo copre già. Una proposta che abbina AES-GCM a SHA-256 è quindi ridondante nel migliore dei casi e rifiutata nel peggiore.

Il PRF resta separato sul lato IKE, poiché deriva chiavi per il canale di controllo invece di proteggere i payload. È per questo che una proposta IKE può combinare legittimamente un cifrario AEAD con un PRF e un gruppo DH, mentre la proposta ESP corrispondente elenca solo il cifrario AEAD e il gruppo PFS opzionale.

La lunghezza della chiave fa parte del token di cifratura, quindi AES-128-GCM e AES-256-GCM sono offerte diverse. Un profilo copiato da una guida che presupponeva chiavi da 256-bit non corrisponderà a un endpoint configurato per 128-bit, anche se entrambe le righe dicono AES-GCM. Due peer possono concordare sulla famiglia di cifrari e rifiutarsi comunque a vicenda per il numero dopo il trattino.

Leggete l'SA installata, non la configurazione

La lista di proposte configurata è un'offerta; l'SA installata è il risultato. Su strongSwan e su un kernel Linux, entrambe le viste sono disponibili:

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

swanctl --list-sas stampa gli algoritmi negoziati per SA, compreso se il CHILD usa AEAD. ip xfrm state mostra ciò che il kernel ha effettivamente installato, ed è il punto in cui confermare che un rinnovo delle chiavi non sia ricaduto su una suite diversa da quella documentata.

Conservate quell'output accanto alla configurazione dopo una correzione. Quando un aggiornamento del client cambia i suoi valori predefiniti, la suite registrata vi dà una linea di base per il confronto, e il confronto indica il campo che si è spostato invece di ricominciare l'indagine dall'inizio.