Windows e strongSwan: allineare le quattro trasformazioni di una proposta IKE

Entrambi i peer supportano AES, entrambi accettano SHA-256, e il tunnel continua a non salire. La proposta è fallita su un componente che nessuno aveva confrontato, di solito il gruppo di scambio delle chiavi. Questa guida legge lo scambio reale prima di cambiare qualcosa, applica un’unica politica circoscritta e lascia un rollback che ripristina i parametri precedenti.

Leggete l’errore prima di cambiare un gruppo

Un «errore di corrispondenza dei criteri» è un riepilogo, non una diagnosi. Significa che non è stata trovata alcuna proposta accettabile per entrambi e non dice nulla su quale componente sia stato rifiutato. Trattatelo come l’inizio dell’indagine e non come prova su un gruppo specifico.

La risposta di solito sta sul lato server. Un log di strongSwan a un livello adeguato elenca la proposta ricevuta dal client e quella che è configurato per accettare, e la differenza fra i due elenchi nomina il componente che ha fallito.

Non date per scontato che il client offra ciò che afferma un vecchio post del forum. Il profilo attivo e la sua politica installata decidono l’elenco offerto, e una build di Windows aggiornata può offrire un insieme diverso da quello nello screenshot che state copiando.

Scrivete entrambi gli elenchi. Quattro posizioni di trasformazione e un gruppo sono un elenco breve, e confrontarlo riga per riga richiede meno tempo di qualsiasi esperimento. Quattro posizioni si tengono facilmente a mente. Un file di log no.

Confrontate ogni trasformazione, non un solo nome familiare

Una proposta IKE è un insieme di scelte che devono corrispondere tutte. La cifratura protegge la negoziazione, l’integrità o un PRF la autentica, e un gruppo Diffie-Hellman stabilisce materiale di chiave nuovo. Una proposta che corrisponde sulle prime due e differisce sulla terza resta inaccettabile per entrambi i peer.

I due campi di Windows che qui si confondono appartengono a fasi diverse. DHGroup si applica allo scambio di chiavi IKE, mentre PfsGroup si applica all’associazione figlia che protegge il traffico. Cambiare il secondo non può riparare un errore nel primo.

I nomi dei gruppi differiscono fra implementazioni, e questa è un’altra fonte di confusione. strongSwan scrive modp2048 e ecp256, mentre Windows usa nomi di enumerazione come Group14 e ECP256, quindi un confronto deve tradurre prima di confrontare. Tenete una nota a due colonne con entrambi i nomi. La prossima discrepanza si classifica allora in pochi secondi.

Applicate una politica completa e circoscritta

Lo strumento supportato per un profilo IKEv2 nativo è una politica IPsec per connessione, impostata come un unico oggetto anziché campo per campo. Visualizzatela in anteprima prima, poi applicatela, e conservate i parametri precedenti nel registro delle modifiche.

Set-VpnConnectionIPsecConfiguration -ConnectionName "Northwind IKEv2" -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -DHGroup ECP256 -PfsGroup ECP256 -WhatIf

L’opzione -WhatIf mostra in anteprima la modifica locale e non applica nulla. È utile e insieme è una trappola comune, perché un’anteprima dimostra solo che i parametri sono sintatticamente accettabili per il cmdlet locale. Non dice nulla sull’accettazione della proposta risultante da parte del gateway.

Allineate anche l’ambito, già che ci siete. Una connessione nell’archivio di tutti gli utenti richiede il parametro corrispondente per tutti gli utenti, e modificare il profilo per utente con lo stesso nome visualizzato cambia un altro oggetto che il tunnel non usa.

Poi regolate il lato strongSwan sullo stesso insieme prima di provare. Una modifica coordinata su entrambe le estremità è l’unica versione che converge; cambiare un lato e riprovare più volte produce un log pieno dello stesso rifiuto.

Verificate separatamente lo scambio e il rinnovo delle chiavi

Una connessione riuscita è un’osservazione, e il rinnovo delle chiavi è un’altra. La negoziazione IKE iniziale usa un insieme di parametri, e l’associazione figlia che trasporta il traffico può essere rinegoziata più avanti con la propria politica. Un’installazione che si connette e poi cade dopo un po’ è di solito il secondo caso.

ipsec statusall | grep -A6 "Northwind"
Get-VpnConnection -Name "Northwind IKEv2" | Format-List *

Il primo comando mostra la vista del server sulle associazioni stabilite, compresa l’associazione figlia e la sua vita residua. Il secondo mostra cosa contiene ora il profilo del client, ed è l’unico modo per confermare che la politica impostata è quella in vigore.

Osservate un rinnovo delle chiavi completo prima di dichiarare il successo. Ciò significa lasciare la connessione attiva abbastanza a lungo perché l’associazione figlia venga sostituita, poi confermare che il traffico continua. La maggior parte delle discrepanze di politica si nasconde in quel passo, perché la negoziazione iniziale può riuscire con un insieme che il rinnovo non accetta.

Il rollback è l’insieme di parametri precedente, non un ripiego permissivo. Se il client offriva solo un gruppo vecchio e debole, la risposta è migliorare la politica comune di client e server, non aggiungere quel gruppo al gateway dove ogni peer futuro potrà negoziare al ribasso fino a esso.

Annotate i quattro parametri, il gruppo, l’ambito della connessione e l’esito del rinnovo. È una nota breve, ed è la differenza fra una guida e un racconto su quella volta che il tunnel è salito.