iOS IKEv2 al strongSwan: neniu propono elektita, riparu la liston

La iPhone starigas la tunelon, la enirejo respondas per nenio, kaj la telefono montras ĝeneralan fiaskon. La protokolo de strongSwan estas pli preciza: neniu propono elektita. Tiu mesaĝo signifas, ke la du listoj de akcepteblaj ĉifraj aroj neniam interkovriĝis, do la interŝanĝo finiĝis antaŭ ol la aŭtentikigo komenciĝis. Ĝi estas kongrua problemo, kaj la solvo estas igi la listojn intersekciĝi.

Kie la enirejo deklaras sian politikon

strongSwan skribas sian politikon en la agordo, kaj la krisigno ĉe la fino decidas kiel tiu politiko estas legata. Kun la signo la listo estas elĉerpa: tiuj enskriboj kaj nenio alia estos akceptitaj. Sen ĝi la sama linio estas prefera ordo, kaj la demono povas elekti ion, kion vi ne intencis. Demandu, kiu formo estas deplojita antaŭ ol traduki ion ajn, ĉar la du kondutas malsame rilate al la sama kliento. Notu la precizan linion, kun la signo, kaj testu kontraŭ ĝi.

Kliento, kiu proponas pli vastan liston, ankoraŭ povas konektiĝi al fiksita enirejo, kondiĉe ke unu kombinaĵo aperas ambaŭflanke. Kio ne povas okazi estas intertraktado ekster la fiksita aro.

Tial profilo kopiita el alia VPN-aplikaĵo povas funkcii tie, kie via ne funkcias: la alia aplikaĵo liveris alian liston.

La nomoj devas kongrui, ne pliboniĝi

Du tradukoj kaptas homojn, kiuj transigas valorojn de strongSwan al iOS. La integreca algoritmo skribita SHA1 en IKE-propono vojaĝas en sia mallongigita formo, kiun iOS nomas .SHA96. La Diffie-Hellman-grupo skribita modp1024 estas group 2, kiun iOS nomas .group2. Anstataŭigi per SHA-256 aŭ group 14 ne intertraktos kontraŭ enirejo, kiu akceptas nur la pli malnovan paron. La kliento devas priskribi la saman algoritmon, ne pli fortan.

Agordu tiujn valorojn eksplicite en NEVPNProtocolIKEv2. Defaŭltoj povas esti pli vastaj aŭ pli mallarĝaj ol la profilo, kiun vi anstataŭigas, kaj la diferenco montriĝas nur kiam la manpremo fiaskas.

La infana propono fiaskas pli poste kaj pli silente

Agordu la sekurecan asocion de la infano same kiel tiun de IKE. Kiam kongruas nur la IKE-parametroj, la tunelo aŭtentikiĝas kaj poste portas neniun trafikon, kio estas multe pli silenta fiasko ol rifuzo. Agordu ĉifradon, integrecon, grupon kaj vivdaŭron de la infano en la sama paŝo. Tenu la vivdaŭron de la kliento je la valoro de la enirejo aŭ sube, ĉar insisti pri pli longa produktas la saman mesaĝon pri nenelektita propono el alia kaŭzo. Miskongruo tie aspektas idente al miskongruo de IKE en la protokolo.

Kontrolu, ĉu la profilo aŭtentikiĝas per atestiloj aŭ per komuna sekreto, dum vi estas en la agordo. Rifuzo de propono kaj rifuzo de aŭtentikigo aperas en malsamaj linioj, kaj ripari la malĝustan kostas tagon. Testu per freŝa konekto post ĉiu ŝanĝo, unu variablo samtempe, ĉar kaŝmemorita stato kaŝas, kiu parametro moviĝis.

Lasu la malnovan aron nur dum ĝi necesas

Fiksi SHA-1 kun 1024-bita grupo estas ponto, ne celo. Ambaŭ estas eksmodaj, kaj pli novaj klientoj povas tute rifuzi ilin, kio signifas, ke la profilo fiaskos sur la sekva aparato sen ia ŝanĝo ĉe vi. Traktu la fiksadon kiel provizoran kaj diru tion en la registro.

Se strongSwan estas via, aldonu modernan proponon kaj lasu ambaŭ flankojn intertrakti supren dum la malnova enskribo restas por pli malnovaj aparatoj. Legu la statusan eligon de la demono por vidi, kiun aron ĉiu konekto efektive uzis. Poste forigu la fiksadon ĉe la klienta flanko, kiam la moderna paro estos konfirmita. Tunelo, kiu stariĝas, ne estas sufiĉa pruvo, ĉar ĝi povas stariĝi sur la aro, kiun vi klopodis emeritigi. La strongSwan-dokumentaro pri IKEv2 priskribas la sintakson de proponoj kaj la striktan markilon.