IKEv2 NO_PROPOSAL_CHOSEN: kiun etapon rifuzis la aro?

NO_PROPOSAL_CHOSEN en protokolo sendas homojn al la antaŭe dividita ŝlosilo, kaj la eraro postvivas la ŝanĝon. Ĝi neniam estis problemo pri akreditaĵoj: la partnero rifuzis ĉiun proponon ofertitan por tiu interŝanĝo, kio estas aserto pri algoritmoj, ne pri identeco. La unua utila demando ne estas, kiun algoritmon redakti, sed kiun interŝanĝon oni rifuzis. Respondu tion antaŭ ol kompari ion ajn. Poste komparu la plenan aron, kiu estis ofertita, kun la plena aro, kiun la partnero permesas.

Unue: kiun interŝanĝon oni rifuzis

IKEv2 intertraktas du specojn de asocio. La IKE SA protektas la intertraktadon mem, kaj la CHILD SA protektas la trafikon. Ĉiu havas sian propran proponaron, kaj ĉiu povas malsukcesi kun la sama sciigo. Rifuzo dum la komenca IKE-intertraktado kaj rifuzo dum la CHILD-intertraktado bezonas malsamajn riparojn, kaj la protokolo kutime nomas la interŝanĝon unu aŭ du liniojn super la sciigo. Legu tiujn du liniojn kune, alie vi redaktos la malĝustan proponliston.

La sciigo sola ne identigas la interŝanĝon. La linio super ĝi nomas la SA intertraktatan, kaj tiu nomo montras al la proponlisto por inspekti.

Komparu kompletan aron, ne unuopajn ŝlosilvortojn

Propono estas kombinaĵo: ĉifra algoritmo, integreco aŭ AEAD, ŝlosilinterŝanĝa grupo kaj ajna pseŭdohazarda funkcio. Kompari nur la nomon de la ĉifrado estas la kutima eraro, ĉar du partneroj povas konsenti pri AES-256 kaj tamen malkonsenti pri SHA-1 kontraŭ SHA-256. Skribu la ofertitajn kaj permesitajn arojn flankon ĉe flanko ĉe la malsukcesa etapo, poste serĉu la malplenan komunaĵon.

offered:   aes256-sha256-modp2048
permitted: aes256-sha1-modp2048

Kontrolu ankaŭ, ke ambaŭ efektivigoj subtenas tion, kion vi agordis. Nomo kopiita de alia platformo povas aspekti sintakse konata dum la kromprogramo aŭ efektivigo tute mankas.

IKE-aro kaj ESP-aro estas malsamaj objektoj

Redakti la IKE-proponon ne riparos rifuzitan CHILD-proponon, kaj la inverso ankaŭ veras. En strongSwan ĉi tiuj estas apartaj agordoj, proksimume proposals = aes256-sha256-modp2048 por la IKE SA kaj aparta ESP-listo por la CHILD SA. Ŝanĝu la liston, kiu kongruas kun la malsukcesa interŝanĝo, poste relegu la protokolon anstataŭ supozi, ke la riparo funkciis.

Por la CHILD SA, la koncerna agordo estas la ESP-proponlisto, ne la IKE-listo. Kopii la IKE-linion en ĝin produktas agordon, kiu analiziĝas kaj intertraktas la malĝustan objekton.

Funkcianta tunelo, kiu malsukcesas ĉe ŝlosilrenovigo

Se la tunelo funkciis dum horo kaj poste malsukcesis, la komenca intertraktado ne estas la problemo. Ŝlosilrenovigo povas provi aliajn kondiĉojn: alian ŝlosilinterŝanĝan grupon post la unua interŝanĝo, malkongruon de vivodaŭro inter partneroj aŭ ŝanĝitan politikon de respondanto. Konservu la renovigan tempomarkon kaj la asociajn identigilojn de ambaŭ flankoj. Tiu ŝablono bezonas proponkomparon ĉe renovigo, ne pli longan tempolimon. Ŝanĝo de tempolimo kaŝas la simptomon kaj lasas la malkongruon surloke.

ipsec statusall montras ĉiun asocion kaj la algoritmojn fakte intertraktitajn. Tiu eligo estas la plej rapida maniero konfirmi, kiun liston oni uzis, kaj ĝi apartigas agordan eraron de kaduka tunelo, kiu neniam reintertraktiĝis.

ipsec statusall | grep -E "IKE:|ESP:"

Elektu komunaĵon, poste konfirmu ambaŭ fazojn

Petu la administranton elekti dokumentitan modernan komunaĵon, kiun ambaŭ partneroj subtenas, kaj skribu ĝin. Ne solvu la eraron per ŝaltado de ĉiu malnova algoritmo aŭ per malŝaltado de identeca kontrolo, ĉar nek unu nek la alia sekvas el rifuzo. Post la ŝanĝo, starigu novan konekton kaj poste devigu ŝlosilrenovigon. La unua konekto sola ne pruvas, ke la renoviga vojo funkcias.

Konservu la akceptitan kombinaĵon kune kun la firmvaraj versioj. Se la sekva eraro temas pri trafikaj selektiloj, traktu ĝin aparte, ĉar interkonsento pri kriptografio diras nenion pri tio, kiujn subretojn la tunelo protektas. La propona dokumentaro de strongSwan kovras la sintakson por ambaŭ listoj.