iOS ha rifiutato il tuo tunnel strongSwan: confronta le proposte IKE

Niente nel certificato o nell'indirizzo spiega perché un iPhone che l'anno scorso si collegava a strongSwan quest'anno fallisca. Nulla dell'indirizzo, della chiave precondivisa o dell'identità del client deve essere cambiato. Ciò che si è spostato è l'elenco delle trasformazioni che il client integrato del telefono è disposto a negoziare, e non appena quell'elenco smette di sovrapporsi a quello del server, lo scambio finisce prima che venga esaminata l'identità di qualcuno.

La riga di log che decide

Alza il livello di log per quella connessione e trova le due voci che decidono l'esito: cosa ha offerto il telefono e cosa ha scelto il server. Se il log finisce senza una proposta selezionata e riporta che nulla corrispondeva, l'autenticazione non è mai stata tentata. Un certificato nuovo e una password nuova non cambiano nulla a quel punto, perché entrambi si consumano in una fase successiva. Nessuno dei due può influire su un esito deciso prima che l'identità fosse esaminata.

Tieni separate le due forme di guasto prima di modificare qualsiasi cosa. Nessuna modifica alle trasformazioni salva credenziali rifiutate, e nessuna correzione delle credenziali salva una trasformazione rifiutata. La voce di log che nomina una proposta selezionata ti dice in quale dei due casi ti trovi. Senza quella voce, stai indovinando.

La riga selezionata nomina la proposta tramite il suo insieme di trasformazioni anziché un'etichetta amichevole. Confronta i campi di cifratura, integrità e gruppo di quella riga con l'elenco inviato dal telefono, perché una discrepanza in anche un solo campo basta a perdere.

Cosa è cambiato sul telefono

Una versione di iOS ha ridotto gli algoritmi che il suo client è disposto a usare. Hash di integrità deboli, gruppi Diffie-Hellman piccoli e proposte che elencano per prime le opzioni legacy hanno smesso di essere accettabili.

Elenchi più lunghi qui non sono più sicuri. La selezione segue l'insieme accettato del telefono e il suo ordine di preferenza, quindi un server che annuncia un catalogo ampio può comunque perdere la negoziazione quando le voci moderne non sono quelle scelte. Preferisci un elenco corto con le voci moderne in testa. Un elenco lungo che si apre con opzioni legacy invita esattamente il guasto che stai cercando di evitare. L'insieme accettato è un vincolo esterno che si sposta a ogni aggiornamento del client, quindi una configurazione che funzionava ieri è una prova su ieri.

Una coppia che negozia ancora

Per i telefoni attuali basta una sola combinazione moderna. Una coppia che negozia assomiglia a questa:

ike=aes256-sha2_256-modp2048
esp=aes256-sha2_256

La riga ike porta la cifratura, l'integrità e il gruppo Diffie-Hellman usati mentre lo scambio di chiavi è in corso. La riga esp copre solo il canale dati, perché il gruppo è stato deciso prima che si applichi. Ricarica la connessione o riavvia il demone, poi ricollega il telefono. Mantieni quel valore di gruppo solo se ogni client che servi lo accetta ancora, e non ampliare la proposta per tutti solo perché un vecchio peer ha bisogno di più.

Tre punti in cui correggerlo, uno di solito è chiuso

• Una proposta moderna per ogni peer. Corretto quando tutti i client sono telefoni e desktop attuali. Elimina le trasformazioni vecchie invece di negoziare attorno a esse.
• Una seconda definizione di connessione per i client Apple. Mantiene vivo un vecchio peer e allo stesso tempo dà al telefono una proposta che accetta. Costa un altro blocco di connessione e rende visibile l'eccezione.
• Cambiare il client. Raramente alla tua portata: quando un sistema di gestione o un'app distribuisce il profilo, non c'è alcun editor di proposte da toccare, e il client integrato non ne espone nessuno.

Scegli la seconda opzione quando un dispositivo fuori dal tuo controllo non può essere aggiornato. Scegli la prima quando puoi dismettere il vecchio peer e preferisci portare una sola politica.

In entrambi i casi la scelta è visibile nella configurazione, ed è questo il punto. Un ripiego silenzioso che negozia al ribasso fino a una trasformazione vecchia è peggio di un blocco esplicito, perché nessuna revisione lo porterà mai in superficie.

Dimostralo, poi annotalo

Ricollega e verifica tre fatti separati sul server: è stata selezionata una proposta, la connessione risulta stabilita e il client ha ricevuto un indirizzo. Una stretta di mano stabilita senza indirizzo remoto punta al pool o ai selettori di traffico, e appartiene a una modifica separata. Trattare le due cose insieme fa sembrare irrisolta una negoziazione risolta.

Annota l'insieme di trasformazioni accettato, quando l'hai cambiato e quale build del client hai verificato. Il prossimo aggiornamento può spostare di nuovo il requisito, e i valori che hanno funzionato sono la prima cosa che vorrai avere accanto a quelli nuovi.