IKEv2 NO_PROPOSAL_CHOSEN: kuris etapas atmetė rinkinį?

NO_PROPOSAL_CHOSEN žurnale nukreipia žmones prie bendro iš anksto paskirstyto rakto, o klaida išlieka ir po pakeitimo. Tai niekada nebuvo prisijungimo duomenų problema: partneris atmetė kiekvieną pasiūlymą, pateiktą tam mainui, o tai yra teiginys apie algoritmus, o ne apie tapatybę. Pirmas naudingas klausimas nėra kurį algoritmą redaguoti, o kuris mainas buvo atmestas. Atsakykite į tai prieš ką nors lygindami. Tada palyginkite visą pasiūlytą rinkinį su visu rinkiniu, kurį partneris leidžia.

Pirmiausia: kuris mainas buvo atmestas

IKEv2 derasi dėl dviejų asociacijų tipų. IKE SA saugo pačias derybas, o CHILD SA saugo srautą. Kiekviena turi savo pasiūlymų rinkinį, ir kiekviena gali nepavykti su tuo pačiu pranešimu. Atmetimas pradinių IKE derybų metu ir atmetimas CHILD derybų metu reikalauja skirtingų pataisų, o žurnalas paprastai nurodo mainą viena ar dviem eilutėmis virš pranešimo. Skaitykite tas dvi eilutes kartu, kitaip redaguosite neteisingą pasiūlymų sąrašą.

Vien pranešimas maino nenurodo. Eilutė virš jo nurodo deramą SA, o tas pavadinimas rodo tikrintiną pasiūlymų sąrašą.

Lyginkite ištisus rinkinius, o ne atskirus raktinius žodžius

Pasiūlymas yra derinys: šifravimo algoritmas, vientisumas arba AEAD, raktų mainų grupė ir bet kuri pseudoatstitiktinė funkcija. Lyginti vien šifravimo pavadinimą yra įprasta klaida, nes du partneriai gali sutarti dėl AES-256 ir vis tiek nesutarti dėl SHA-1 ir SHA-256. Nepavykusiame etape užrašykite pasiūlytus ir leidžiamus rinkinius vieną šalia kito, tada ieškokite tuščios sankirtos.

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

Taip pat patikrinkite, ar abi implementacijos palaiko tai, ką sukonfigūravote. Iš kitos platformos nukopijuotas pavadinimas gali atrodyti sintaksiškai pažįstamas tuo tarpu papildinio arba implementacijos visiškai nėra.

IKE rinkinys ir ESP rinkinys yra skirtingi objektai

IKE pasiūlymo redagavimas nepataisys atmesto CHILD pasiūlymo, ir atvirkščiai. strongSwan tai yra atskiri nustatymai, maždaug proposals = aes256-sha256-modp2048 IKE SA ir atskiras ESP sąrašas CHILD SA. Pakeiskite sąrašą, atitinkantį nepavykusį mainą, tada perskaitykite žurnalą, o ne manykite, kad pataisa suveikė.

CHILD SA atveju atitinkamas nustatymas yra ESP pasiūlymų sąrašas, o ne IKE. Nukopijavus į jį IKE eilutę sukuriama konfigūracija, kuri išanalizuojama, bet derasi dėl netinkamo objekto.

Veikiantis tunelis, kuris nepavyksta atnaujinant raktą

Jei tunelis veikė valandą ir tada nepavyko, pradinės derybos nėra problema. Rakto atnaujinimas gali išbandyti kitas sąlygas: kitą raktų mainų grupę po pirmojo maino, gyvavimo trukmės neatitikimą tarp partnerių arba pakeistą atsakiklio politiką. Išsaugokite atnaujinimo laiko žymą ir asociacijos identifikatorius iš abiejų pusių. Toks modelis reikalauja pasiūlymų palyginimo atnaujinimo metu, o ne ilgesnio laiko limito. Laiko limito pakeitimas paslepia simptomą ir palieka neatitikimą.

ipsec statusall rodo kiekvieną asociaciją ir faktiškai suderėtus algoritmus. Ši išvestis yra greičiausias būdas patvirtinti, kuris sąrašas buvo naudojamas, ir ji atskiria konfigūracijos klaidą nuo pasenusio tunelio, kuris niekada nebuvo iš naujo suderėtas.

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

Pasirinkite sankirtą, tada patvirtinkite abi fazes

Paprašykite administratoriaus pasirinkti dokumentuotą šiuolaikinę sankirtą, kurią palaiko abu partneriai, ir ją užrašyti. Nespręskite klaidos įjungdami visus senus algoritmus arba išjungdami tapatybės patikrinimą, nes nė viena iš to neišplaukia iš atmetimo. Po pakeitimo užmegzkite naują ryšį ir tada priverstinai atnaujinkite raktą. Vien pirmasis ryšys neįrodo, kad atnaujinimo kelias veikia.

Išsaugokite priimtą derinį kartu su programinės įrangos versijomis. Jei kita klaida susijusi su srauto selektoriais, nagrinėkite ją atskirai, nes susitarimas dėl kriptografijos nieko nesako apie tai, kuriuos potinklius tunelis saugo. strongSwan pasiūlymų dokumentacija apima abiejų sąrašų sintaksę.