IKEv2 NO_PROPOSAL_CHOSEN: katera faza je zavrnila nabor?

NO_PROPOSAL_CHOSEN v dnevniku pošlje ljudi k vnaprej deljenemu ključu, in napaka preživi tudi to spremembo. Nikoli ni šlo za težavo s poverilnicami: partner je zavrnil vsak predlog, ponujen za to izmenjavo, kar je izjava o algoritmih in ne o identiteti. Prvo koristno vprašanje ni, kateri algoritem urediti, ampak katera izmenjava je bila zavrnjena. Odgovorite na to, preden karkoli primerjate. Nato primerjajte celoten ponujeni nabor s celotnim naborom, ki ga partner dovoljuje.

Najprej: katera izmenjava je bila zavrnjena

IKEv2 pogaja dve vrsti asociacije. IKE SA ščiti samo pogajanje, CHILD SA pa ščiti promet. Vsaka ima svoj nabor predlogov in vsaka lahko spodleti z istim obvestilom. Zavrnitev med začetnim pogajanjem IKE in zavrnitev med pogajanjem CHILD zahtevata različne popravke, in dnevnik običajno poimenuje izmenjavo vrstico ali dve nad obvestilom. Berite ti dve vrstici skupaj, sicer boste uredili napačen seznam predlogov.

Samo obvestilo izmenjave ne identificira. Vrstica nad njim poimenuje SA, ki se pogaja, in to ime kaže na seznam predlogov, ki ga je treba pregledati.

Primerjajte cele nabore, ne posameznih ključnih besed

Predlog je kombinacija: algoritem šifriranja, celovitost ali AEAD, skupina za izmenjavo ključev in morebitna psevdonaključna funkcija. Primerjanje samo imena šifriranja je običajna napaka, ker se lahko dva partnerja strinjata o AES-256 in se še vedno razhajata glede SHA-1 proti SHA-256. Zapišite ponujeni in dovoljeni nabor drug ob drugem v spodleteli fazi, nato poiščite prazen presek.

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

Preverite tudi, da obe izvedbi podpirata to, kar ste nastavili. Ime, kopirano z druge platforme, je lahko videti sintaktično znano medtem ko vtičnik ali izvedba popolnoma manjka.

Nabor IKE in nabor ESP sta različna predmeta

Urejanje predloga IKE ne bo popravilo zavrnjenega predloga CHILD, in obratno prav tako velja. V strongSwanu so to ločene nastavitve, približno proposals = aes256-sha256-modp2048 za IKE SA in ločen seznam ESP za CHILD SA. Spremenite seznam, ki ustreza spodleteli izmenjavi, in nato znova preberite dnevnik, namesto da predpostavite, da je popravek deloval.

Za CHILD SA je ustrezna nastavitev seznam predlogov ESP, ne seznam IKE. Kopiranje vrstice IKE vanj ustvari konfiguracijo, ki se razčleni, a pogaja napačen predmet.

Delujoč tunel, ki spodleti pri obnovi ključa

Če je tunel deloval eno uro in nato spodletel, začetno pogajanje ni težava. Obnova ključa lahko preizkusi druge pogoje: drugo skupino za izmenjavo ključev po prvi izmenjavi, neusklajenost življenjske dobe med partnerji ali spremenjeno politiko odzivnika. Shranite časovni žig obnove in identifikatorje asociacije z obeh strani. Tak vzorec zahteva primerjavo predlogov pri obnovi, ne daljše časovne omejitve. Sprememba časovne omejitve skrije simptom in neusklajenost pusti na mestu.

ipsec statusall prikazuje vsako asociacijo in algoritme, ki so bili dejansko dogovorjeni. Ta izpis je najhitrejši način za potrditev, kateri seznam je bil uporabljen, in loči konfiguracijsko napako od zastarelega tunela, ki ni bil nikoli znova pogajan.

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

Izberite presek in nato potrdite obe fazi

Prosite skrbnika, naj izbere dokumentiran sodoben presek, ki ga podpirata oba partnerja, in ga zapiše. Napake ne rešujte z omogočanjem vseh starih algoritmov ali z izklopom preverjanja identitete, ker nobeno ne izhaja iz zavrnitve. Po spremembi vzpostavite novo povezavo in nato vsilite obnovo ključa. Samo prva povezava ne dokazuje, da pot obnove deluje.

Shranite sprejeto kombinacijo skupaj z različicami vdelane programske opreme. Če se naslednja napaka nanaša na izbirnike prometa, jo obravnavajte ločeno, saj dogovor o kriptografiji ne pove ničesar o tem, katere podmreže tunel ščiti. dokumentacija predlogov strongSwana pokriva sintakso obeh seznamov.