Da iOS IKEv2 a strongSwan: nessuna proposta scelta, correggi l'elenco

L'iPhone alza il tunnel, il gateway non risponde nulla e il telefono mostra un errore generico. Il log di strongSwan è più preciso: no proposal chosen. Quel messaggio significa che i due elenchi di suite cifrate accettabili non si sono mai sovrapposti, quindi lo scambio è terminato prima che iniziasse l'autenticazione. È un problema di corrispondenza e la soluzione è far intersecare gli elenchi.

Dove il gateway dichiara la sua politica

strongSwan scrive la sua politica nella configurazione e il punto esclamativo finale decide come va letta. Con il segno l'elenco è esaustivo: verranno accettate quelle voci e nient'altro. Senza il segno la stessa riga è un ordine di preferenza e il daemon può scegliere qualcosa che non intendevi. Chiedi quale forma è installata prima di tradurre qualsiasi cosa, perché le due si comportano diversamente con lo stesso client. Registra la riga esatta, segno incluso, e prova su quella.

Un client che offre un elenco più ampio può comunque connettersi a un gateway vincolato, purché una combinazione compaia da entrambe le parti. Ciò che non può accadere è una negoziazione fuori dall'insieme vincolato.

Ecco perché un profilo copiato da un'altra app VPN può funzionare dove il tuo no: l'altra app distribuiva un elenco diverso.

I nomi devono corrispondere, non migliorare

Due traduzioni ingannano chi sposta i valori da strongSwan a iOS. L'algoritmo di integrità scritto SHA1 in una proposta IKE viaggia nella sua forma troncata, che iOS chiama .SHA96. Il gruppo Diffie-Hellman scritto modp1024 è il gruppo 2, che iOS chiama .group2. Sostituire SHA-256 o il gruppo 14 non negozierà con un gateway che accetta solo la coppia più vecchia. Il client deve descrivere lo stesso algoritmo, non uno più forte.

Imposta quei valori esplicitamente in NEVPNProtocolIKEv2. I valori predefiniti possono essere più ampi o più stretti del profilo che stai sostituendo, e la differenza emerge solo quando l'handshake fallisce.

La proposta figlia fallisce più tardi e in silenzio

Configura anche la security association figlia, oltre a quella IKE. Quando solo i parametri IKE coincidono, il tunnel si autentica e poi non trasporta traffico, un guasto molto più silenzioso di un rifiuto. Imposta cifratura, integrità, gruppo e durata della figlia nello stesso passaggio. Mantieni la durata del client pari o inferiore al valore del gateway, perché insistere su una più lunga produce lo stesso messaggio no proposal chosen da una causa diversa. Una discrepanza lì sembra identica a una discrepanza IKE nel log.

Controlla se il profilo si autentica con certificati o con un segreto condiviso mentre sei nella configurazione. Il rifiuto di una proposta e il rifiuto dell'autenticazione compaiono su righe diverse, e correggere quello sbagliato costa una giornata. Prova con una connessione nuova dopo ogni modifica, una variabile alla volta, perché lo stato in cache nasconde quale parametro si è spostato.

Lascia la suite legacy solo finché serve

Fissare SHA-1 con un gruppo a 1024 bit è un ponte, non una destinazione. Entrambi sono deprecati e i client più nuovi possono rifiutarli del tutto, il che significa che il profilo fallirà sul prossimo dispositivo senza alcuna modifica da parte tua. Tratta il pin come temporaneo e scrivilo nel verbale.

Se strongSwan è tuo, aggiungi una proposta moderna e lascia che entrambe le estremità negozino verso l'alto mentre la voce legacy resta per i dispositivi più vecchi. Leggi l'output di stato del daemon per vedere quale suite ha usato davvero ogni connessione. Poi rimuovi il pin lato client una volta confermata la coppia moderna. Un tunnel che si alza non basta come prova, perché può alzarsi sulla suite che stavi cercando di ritirare. La documentazione IKEv2 di strongSwan descrive la sintassi delle proposte e il marcatore strict.