iOS IKEv2 cap a strongSwan: cap proposta triada, arregleu la llista

L'iPhone aixeca el túnel, la passarel·la respon amb res i el telèfon mostra una fallada genèrica. El registre de strongSwan és més específic: cap proposta triada. Aquest missatge vol dir que les dues llistes de conjunts de xifratge acceptables mai no es van solapar, així que l'intercanvi va acabar abans que comencés l'autenticació. És un problema d'emparellament, i la solució és fer que les llistes s'intersequin.

On la passarel·la declara la seva política

strongSwan escriu la seva política a la configuració, i el signe d'exclamació final decideix com es llegeix aquesta política. Amb el signe, la llista és exhaustiva: s'acceptaran aquelles entrades i res més. Sense el signe, la mateixa línia és un ordre de preferència, i el dimoni pot triar una cosa que no volíeu. Pregunteu quina forma hi ha desplegada abans de traduir res, perquè les dues es comporten diferent davant del mateix client. Anoteu la línia exacta, signe inclòs, i proveu contra ella.

Un client que ofereix una llista més àmplia encara es pot connectar a una passarel·la fixada, sempre que una combinació aparegui a les dues bandes. El que no pot passar és una negociació fora del conjunt fixat.

Per això un perfil copiat d'una altra aplicació VPN pot funcionar on el vostre no ho fa: l'altra aplicació portava una llista diferent.

Els noms han de coincidir, no millorar

Dues traduccions enganxen la gent que trasllada valors de strongSwan a iOS. L'algorisme d'integritat escrit SHA1 en una proposta IKE viatja en la seva forma truncada, que iOS anomena .SHA96. El grup de Diffie-Hellman escrit modp1024 és group 2, que iOS anomena .group2. Substituir per SHA-256 o group 14 no negociarà contra una passarel·la que només accepta la parella antiga. El client ha de descriure el mateix algorisme, no un de més fort.

Definiu aquests valors explícitament a NEVPNProtocolIKEv2. Els valors per defecte poden ser més amplis o més estrets que el perfil que substituïu, i la diferència només es veu quan falla l'encaixada de mans.

La proposta filla falla més tard i més silenciosament

Configureu l'associació de seguretat filla igual que la d'IKE. Quan només coincideixen els paràmetres IKE, el túnel s'autentica i després no porta cap trànsit, cosa que és una fallada molt més silenciosa que un rebuig. Definiu el xifratge, la integritat, el grup i la vida útil de la filla en la mateixa passada. Manteniu la vida útil del client igual o per sota del valor de la passarel·la, perquè insistir en una de més llarga produeix el mateix missatge de cap proposta triada per una causa diferent. Una discrepància allà es veu idèntica a una discrepància IKE al registre.

Comproveu si el perfil s'autentica amb certificats o amb un secret compartit mentre sou a la configuració. Un rebuig de proposta i un rebuig d'autenticació apareixen en línies diferents, i arreglar el que no toca costa un dia. Proveu amb una connexió nova després de cada canvi, una variable alhora, perquè l'estat en memòria cau amaga quin paràmetre s'ha mogut.

Deixeu el conjunt antic només mentre calgui

Fixar SHA-1 amb un grup de 1024 bits és un pont, no una destinació. Tots dos estan obsolets, i els clients més nous poden rebutjar-los directament, cosa que significa que el perfil fallarà al dispositiu següent sense cap canvi a la vostra banda. Tracteu la fixació com a temporal i digueu-ho al registre.

Si strongSwan és vostre, afegiu una proposta moderna i deixeu que les dues bandes negociïn cap amunt mentre l'entrada antiga es queda per als dispositius antics. Llegiu la sortida d'estat del dimoni per veure quin conjunt ha fet servir realment cada connexió. Després traieu la fixació del costat del client quan la parella moderna estigui confirmada. Un túnel que s'aixeca no és prou evidència, perquè pot aixecar-se amb el conjunt que intentàveu retirar. La documentació d'IKEv2 de strongSwan descriu la sintaxi de les propostes i el marcador estricte.