IKEv2 NO_PROPOSAL_CHOSEN: aling yugto ang tumanggi sa suite?

Ang NO_PROPOSAL_CHOSEN sa isang log ay nagpapadala ng mga tao sa paunang ibinahaging key, at nananatili ang error pagkatapos ng pagbabago. Hindi kailanman ito naging problema sa mga kredensyal: tinanggihan ng peer ang bawat panukalang iniaalok para sa palitang iyon, na isang pahayag tungkol sa mga algorithm at hindi sa pagkakakilanlan. Ang unang kapaki-pakinabang na tanong ay hindi kung aling algorithm ang i-edit, kundi kung aling palitan ang tinanggihan. Sagutin iyon bago ihambing ang anuman. Pagkatapos ay ihambing ang buong suite na inaalok sa buong suite na pinapayagan ng peer.

Una: aling palitan ang tinanggihan

Ang IKEv2 ay nakikipag-usap sa dalawang uri ng asosasyon. Pinoprotektahan ng IKE SA ang negosasyon mismo, at pinoprotektahan ng CHILD SA ang trapiko. Bawat isa ay may sariling set ng panukala, at bawat isa ay maaaring mabigo sa parehong abiso. Ang pagtanggi sa unang negosasyon ng IKE at pagtanggi sa negosasyon ng CHILD ay nangangailangan ng magkaibang pag-aayos, at karaniwang pinangalanan ng log ang palitan isa o dalawang linya sa itaas ng abiso. Basahin ang dalawang linyang iyon nang magkasama, kung hindi ay mai-edit mo ang maling listahan ng panukala.

Ang abiso lamang ay hindi tumutukoy sa palitan. Pinangalanan ng linyang nasa itaas nito ang SA na kinakausap, at ang pangalang iyon ay tumuturo sa listahan ng panukalang dapat suriin.

Ihambing ang kumpletong suite, hindi ang mga indibidwal na keyword

Ang panukala ay isang kombinasyon: algorithm ng pag-encrypt, integridad o AEAD, grupo ng pagpapalitan ng key, at anumang pseudo-random na function. Ang paghahambing lamang ng pangalan ng pag-encrypt ay ang karaniwang pagkakamali, dahil ang dalawang peer ay maaaring magkasundo sa AES-256 at hindi pa rin magkasundo sa SHA-1 laban sa SHA-256. Isulat ang inaalok at pinapayagang suite nang magkatabi sa nabigong yugto, pagkatapos hanapin ang walang laman na interseksyon.

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

Tingnan din na sinusuportahan ng dalawang implementasyon ang iyong na-configure. Ang pangalang kinopya mula sa ibang platform ay maaaring magmukhang pamilyar sa sintaks habang ang plugin o implementasyon ay ganap na wala.

Ang IKE suite at ESP suite ay magkaibang bagay

Ang pag-edit ng panukalang IKE ay hindi mag-aayos ng tinanggihang panukalang CHILD, at ang kabaligtaran ay totoo rin. Sa strongSwan ito ay magkahiwalay na setting, humigit-kumulang proposals = aes256-sha256-modp2048 para sa IKE SA at hiwalay na listahan ng ESP para sa CHILD SA. Baguhin ang listahang tumutugma sa nabigong palitan, pagkatapos ay basahin muli ang log sa halip na ipagpalagay na gumana ang pag-aayos.

Para sa CHILD SA, ang kaugnay na setting ay ang listahan ng panukalang ESP, hindi ang listahan ng IKE. Ang pagkopya ng linyang IKE dito ay lumilikha ng configuration na na-parse ngunit nakikipag-usap sa maling bagay.

Isang gumaganang tunnel na nabigo sa pag-renew ng key

Kung ang tunnel ay tumakbo nang isang oras at pagkatapos ay nabigo, ang unang negosasyon ay hindi ang problema. Ang pag-renew ng key ay maaaring sumubok ng iba pang kondisyon: ibang grupo ng pagpapalitan ng key pagkatapos ng unang palitan, hindi pagkakatugma ng lifetime sa pagitan ng mga peer, o binagong patakaran ng responder. Itago ang timestamp ng pag-renew at ang mga identifier ng asosasyon mula sa magkabilang panig. Ang gayong pattern ay nangangailangan ng paghahambing ng panukala sa pag-renew, hindi ng mas mahabang timeout. Ang pagbabago ng timeout ay nagtatago ng sintomas at iniiwan ang pagkakaiba.

ipsec statusall na nagpapakita ng bawat asosasyon at ng mga algorithm na aktwal na napagkasunduan. Ang output na iyon ang pinakamabilis na paraan upang kumpirmahin kung aling listahan ang ginamit, at hinihiwalay nito ang error sa configuration mula sa lumang tunnel na hindi kailanman muling nakipag-usap.

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

Pumili ng interseksyon, pagkatapos ay kumpirmahin ang dalawang yugto

Hilingin sa administrator na pumili ng dokumentadong modernong interseksyon na sinusuportahan ng dalawang peer, at isulat ito. Huwag lutasin ang error sa pamamagitan ng pagpapagana sa lahat ng lumang algorithm o sa pamamagitan ng pag-disable ng pagpapatunay ng pagkakakilanlan, dahil wala sa dalawa ang sumusunod mula sa pagtanggi. Pagkatapos ng pagbabago, magtatag ng bagong koneksyon at pagkatapos ay pilitin ang pag-renew ng key. Ang unang koneksyon lamang ay hindi nagpapatunay na gumagana ang landas ng pag-renew.

Itago ang tinanggap na kombinasyon kasama ng mga bersyon ng firmware. Kung ang susunod na error ay tungkol sa mga tagapili ng trapiko, tratuhin ito nang hiwalay, dahil ang kasunduan sa kriptograpiya ay walang sinasabi tungkol sa kung aling mga subnet ang pinoprotektahan ng tunnel. Ang dokumentasyon ng panukala ng strongSwan ay sumasaklaw sa sintaks ng dalawang listahan.