Do iOS IKEv2 ao strongSwan: nenhuma proposta escolhida, corrija a lista

O iPhone levanta o túnel, o gateway responde com nada e o telefone mostra uma falha genérica. O log do strongSwan é mais específico: no proposal chosen. Essa mensagem significa que as duas listas de conjuntos de cifra aceitáveis nunca se sobrepuseram, então a troca terminou antes de a autenticação começar. É um problema de correspondência, e a correção é fazer as listas cruzarem-se.

Onde o gateway declara a sua política

O strongSwan escreve a sua política na configuração, e o ponto de exclamação no fim decide como essa política é lida. Com o sinal, a lista é exaustiva: só essas entradas e mais nada serão aceites. Sem ele, a mesma linha é uma ordem de preferência, e o daemon pode escolher algo que não pretendia. Pergunte qual forma está implementada antes de traduzir seja o que for, porque as duas comportam-se de maneira diferente com o mesmo cliente. Registe a linha exata, sinal incluído, e teste contra ela.

Um cliente que oferece uma lista mais ampla ainda pode ligar-se a um gateway fixado, desde que uma combinação apareça dos dois lados. O que não pode acontecer é negociação fora do conjunto fixado.

É por isso que um perfil copiado de outra aplicação VPN pode funcionar onde o seu não funciona: a outra aplicação enviava uma lista diferente.

Os nomes têm de coincidir, não melhorar

Duas traduções enganam quem passa valores do strongSwan para o iOS. O algoritmo de integridade escrito SHA1 numa proposta IKE viaja na sua forma truncada, que o iOS chama .SHA96. O grupo Diffie-Hellman escrito modp1024 é o grupo 2, que o iOS chama .group2. Substituir por SHA-256 ou grupo 14 não negoceia com um gateway que só aceita o par mais antigo. O cliente tem de descrever o mesmo algoritmo, não um mais forte.

Defina esses valores explicitamente em NEVPNProtocolIKEv2. Os valores predefinidos podem ser mais amplos ou mais estreitos do que o perfil que está a substituir, e a diferença só aparece quando o handshake falha.

A proposta filha falha mais tarde e mais silenciosamente

Configure também a associação de segurança filha, não apenas a do IKE. Quando só os parâmetros do IKE coincidem, o túnel autentica-se e depois não transporta tráfego, o que é uma falha muito mais silenciosa do que uma recusa. Defina a cifra, a integridade, o grupo e o tempo de vida da filha no mesmo passo. Mantenha o tempo de vida do cliente igual ou inferior ao valor do gateway, porque insistir num mais longo produz a mesma mensagem no proposal chosen por outra causa. Uma divergência ali parece idêntica a uma divergência de IKE no log.

Verifique se o perfil autentica com certificados ou com um segredo partilhado enquanto está na configuração. A rejeição de uma proposta e a rejeição da autenticação aparecem em linhas diferentes, e corrigir a errada custa um dia. Teste com uma ligação nova após cada alteração, uma variável de cada vez, porque o estado em cache esconde qual parâmetro mudou.

Deixe o conjunto antigo apenas enquanto for necessário

Fixar SHA-1 com um grupo de 1024 bits é uma ponte, não um destino. Ambos estão obsoletos, e clientes mais recentes podem recusá-los de imediato, o que significa que o perfil falhará no próximo dispositivo sem qualquer alteração do seu lado. Trate a fixação como temporária e diga-o no registo.

Se o strongSwan for seu, acrescente uma proposta moderna e deixe ambos os lados negociar para cima enquanto a entrada antiga fica para dispositivos mais velhos. Leia a saída de estado do daemon para ver que conjunto cada ligação realmente usou. Depois remova a fixação do lado do cliente assim que o par moderno estiver confirmado. Um túnel que sobe não é prova suficiente, porque pode subir no conjunto que estava a tentar retirar. A documentação do strongSwan para IKEv2 descreve a sintaxe das propostas e o marcador strict.