IKEv2 NO_PROPOSAL_CHOSEN: quale fase ha rifiutato la suite?

NO_PROPOSAL_CHOSEN in un registro manda le persone alla chiave precondivisa, e l'errore sopravvive al cambiamento. Non è mai stato un problema di credenziali: il peer ha rifiutato ogni proposta offerta per quello scambio, il che è un'affermazione sugli algoritmi e non sull'identità. La prima domanda utile non è quale algoritmo modificare, ma quale scambio è stato rifiutato. Rispondete prima di confrontare qualsiasi cosa. Poi confrontate la suite completa offerta con la suite completa che il peer consente.

Prima: quale scambio è stato rifiutato

IKEv2 negozia due tipi di associazione. L'IKE SA protegge la negoziazione stessa, e la CHILD SA protegge il traffico. Ciascuna ha il proprio insieme di proposte, e ciascuna può fallire con la stessa notifica. Un rifiuto durante la negoziazione IKE iniziale e un rifiuto durante la negoziazione CHILD richiedono correzioni diverse, e il registro di solito nomina lo scambio una o due righe sopra la notifica. Leggete insieme quelle due righe, altrimenti modificherete la lista di proposte sbagliata.

La notifica da sola non identifica lo scambio. La riga sopra nomina l'SA in negoziazione, e quel nome punta alla lista di proposte da ispezionare.

Confrontate suite complete, non singole parole chiave

Una proposta è una combinazione: algoritmo di cifratura, integrità o AEAD, gruppo di scambio chiavi e qualsiasi funzione pseudocasuale. Confrontare solo il nome della cifratura è l'errore abituale, perché due peer possono concordare su AES-256 e comunque dissentire su SHA-1 rispetto a SHA-256. Scrivete le suite offerta e consentita affiancate nella fase fallita, poi cercate l'intersezione vuota.

offered:   aes256-sha256-modp2048
permitted: aes256-sha1-modp2048

Verificate anche che entrambe le implementazioni supportino ciò che avete configurato. Un nome copiato da un'altra piattaforma può sembrare sintatticamente familiare mentre il plugin o l'implementazione manca del tutto.

La suite IKE e la suite ESP sono oggetti diversi

Modificare la proposta IKE non riparerà una proposta CHILD rifiutata, e vale anche il contrario. In strongSwan sono impostazioni separate, all'incirca proposals = aes256-sha256-modp2048 per l'IKE SA e una lista ESP separata per la CHILD SA. Cambiate la lista che corrisponde allo scambio fallito, poi rileggete il registro invece di supporre che la correzione abbia funzionato.

Per la CHILD SA, l'impostazione rilevante è la lista di proposte ESP, non quella IKE. Copiarvi la riga IKE produce una configurazione che viene analizzata ma negozia l'oggetto sbagliato.

Un tunnel funzionante che fallisce al rinnovo della chiave

Se il tunnel ha funzionato per un'ora e poi è fallito, la negoziazione iniziale non è il problema. Un rinnovo della chiave può mettere alla prova condizioni diverse: un gruppo di scambio chiavi diverso dopo il primo scambio, una discrepanza di durata tra i peer o una politica del responder modificata. Conservate il timestamp di rinnovo e gli identificatori di associazione da entrambi i lati. Quel modello richiede un confronto di proposte al rinnovo, non un timeout più lungo. Cambiare il timeout nasconde il sintomo e lascia la discrepanza al suo posto.

ipsec statusall mostra ogni associazione e gli algoritmi realmente negoziati. Quell'output è il modo più rapido per confermare quale lista è stata usata, e separa un errore di configurazione da un tunnel obsoleto che non è mai stato rinegoziato.

ipsec statusall | grep -E "IKE:|ESP:"

Scegliete un'intersezione, poi confermate entrambe le fasi

Fate scegliere all'amministratore un'intersezione moderna documentata che entrambi i peer supportano, e mettetela per iscritto. Non risolvete l'errore abilitando tutti gli algoritmi legacy né disabilitando la verifica dell'identità, perché nessuna delle due cose deriva da un rifiuto. Dopo la modifica, stabilite una nuova connessione e poi forzate un rinnovo della chiave. La prima connessione da sola non dimostra che il percorso di rinnovo funzioni.

Conservate la combinazione accettata insieme alle versioni del firmware. Se l'errore successivo riguarda i selettori di traffico, trattatelo separatamente, poiché l'accordo sulla crittografia non dice nulla su quali sottoreti protegga il tunnel. La documentazione delle proposte di strongSwan copre la sintassi di entrambe le liste.