Cifrari Windows e strongSwan: abbinare lo strato giusto

Entrambe le estremità dichiarano AES-128 e il tunnel continua a rifiutarsi di stabilirsi. CBC e GCM sono trasformazioni diverse che per caso condividono la stessa lunghezza di chiave, e un client che ne offre una non soddisfa un gateway che accetta solo l'altra. La parola AES descrive una famiglia, non un accordo.

C'è anche un secondo asse, ed è quello che produce gli errori confusi.

Due strati, due elenchi indipendenti

IKE protegge la negoziazione stessa, mentre l'associazione figlia protegge il traffico che ti interessa davvero. Windows espone la prima come metodo di cifratura e metodo di integrità, e la seconda come costanti di trasformazione di cifratura e autenticazione. Questi campi non sono alias l'uno dell'altro, e un valore valido in uno può essere privo di senso o errato nell'altro. Leggere il profilo con questa separazione in mente elimina gran parte della confusione.

La conseguenza pratica è che puoi avere una politica di scambio chiavi del tutto accettabile e una politica del canale dati che il peer non accetterà. Un elenco negozia; l'altro protegge i pacchetti. Cambiare un valore nel primo non ha alcun effetto sul secondo, per quanto simili appaiano i due in una finestra di configurazione.

Annota entrambi gli elenchi prima di confrontarli con il gateway. Un confronto fatto a memoria è il modo in cui un campo viene modificato due volte e l'altro mai. Tieni aperta la console del gateway accanto al profilo.

Leggi l'errore accanto alle proposte

La fase che ha fallito ti dice quale elenco esaminare. Un rifiuto durante lo scambio chiavi iniziale è un problema di proposta IKE, e avviene prima che esista qualsiasi associazione figlia. Un guasto mentre si negozia l'associazione del traffico protetto è un problema di proposta ESP, e lo scambio chiavi è già riuscito. Un messaggio generico di corrispondenza di politica dal client non nomina nessuna delle due fasi, per questo la visione del gateway stesso è quella utile.

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 60 --no-pager

Confronta la proposta ricevuta, la proposta configurata e quella selezionata per quel singolo tentativo. Qui contano tre elenchi diversi, e solo l'ultimo descrive ciò che è stato effettivamente usato. Citatala testualmente nel ticket invece di riassumerla.

Tieni CBC e GCM come alternative separate

Un gateway a cui è deliberatamente consentito accettare l'una o l'altra famiglia ha bisogno di due proposte, non di una. In strongSwan una virgola separa le alternative e un trattino unisce i componenti di una singola suite. Combinare entrambe le famiglie con i trattini produce una proposta impossibile invece di due accettabili.

proposals = aes128gcm16-prfsha256-ecp256, aes128-sha256-ecp256
esp_proposals = aes128gcm16-ecp256

La prima alternativa porta cifratura autenticata e nomina ancora una funzione pseudo-casuale, perché la derivazione delle chiavi ne ha bisogno anche quando l'integrità viene dal cifrario. La seconda alternativa è cifratura classica con un algoritmo di integrità separato. Entrambe restano soggette a ciò che supporta l'implementazione crittografica caricata.

Una proposta ESP non è una proposta IKE rinominata

Il token del cifrario appare identico in entrambi gli elenchi, e quasi nulla il resto viene trasferito. Una proposta ESP non ha una funzione pseudo-casuale di scambio chiavi, e i suoi requisiti di integrità e segretezza in avanti vengono argomentati contro la politica Windows dall'altra parte invece di essere copiati dalla riga IKE. Tradurre meccanicamente un elenco nell'altro produce qualcosa che valida e non negozia mai.

Scegli una direzione e restaci. O il gateway mantiene una politica solo GCM e il client distribuisce una politica compatibile completa, oppure il gateway accetta entrambe le famiglie e il client mantiene la sua suite esistente. Abilitare un fallback che la politica di sicurezza vieta non è una correzione, per quanto rapidamente elimini l'errore.

Verifica entrambe le suite, poi un rinnovo delle chiavi

Conferma separatamente la suite di scambio chiavi selezionata e la suite del traffico selezionata, perché provengono da elenchi diversi e possono riuscire indipendentemente. Poi lascia avvenire un rinnovo delle chiavi e confermalo. Una prima stretta di mano che funziona e un rinnovo delle chiavi che fallisce descrivono un insieme di proposte solo parzialmente accettabile.

Conserva questa prova insieme alla modifica. Una disconnessione ricorrente ha bisogno del proprio registro di scambio fallito prima che qualcuno incolpi un timer o un difetto della piattaforma.