IKEv2 NO_PROPOSAL_CHOSEN: millises etapis komplekt tagasi lükati?

NO_PROPOSAL_CHOSEN logis saadab inimesed eelnevalt jagatud võtme juurde ja viga jääb ka pärast muudatust püsima. See ei olnud kunagi mandaatide probleem: partner lükkas tagasi iga selle vahetuse jaoks pakutud ettepaneku, mis on väide algoritmide, mitte identiteedi kohta. Esimene kasulik küsimus ei ole, millist algoritmi muuta, vaid milline vahetus tagasi lükati. Vastake sellele enne millegi võrdlemist. Seejärel võrrelge kogu pakutud komplekti kogu komplektiga, mille partner lubab.

Esmalt: milline vahetus tagasi lükati

IKEv2 läbiräägib kahte liiki assotsiatsiooni. IKE SA kaitseb läbirääkimist ennast ja CHILD SA kaitseb liiklust. Kummagi jaoks on oma ettepanekute komplekt ja kumbki võib sama teatega ebaõnnestuda. Tagasilükkamine esialgse IKE läbirääkimise ajal ja tagasilükkamine CHILD läbirääkimise ajal nõuavad erinevaid parandusi ning logi nimetab tavaliselt vahetuse üks või kaks rida teate kohal. Lugege neid kahte rida koos, muidu muudate vale ettepanekute loendit.

Teade üksi ei tuvasta vahetust. Selle kohal olev rida nimetab läbiräägitava SA ja see nimi osutab ettepanekute loendile, mida uurida.

Võrrelge terveid komplekte, mitte üksikuid märksõnu

Ettepanek on kombinatsioon: krüpteerimisalgoritm, terviklikkus või AEAD, võtmevahetusgrupp ja mis tahes pseudojuhuslik funktsioon. Ainult krüpteerimise nime võrdlemine on tavaline viga, sest kaks partnerit võivad kokku leppida AES-256-s ja siiski erineda SHA-1 ja SHA-256 osas. Kirjutage pakutud ja lubatud komplektid ebaõnnestunud etapis kõrvuti ja otsige seejärel tühja ühisosa.

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

Kontrollige ka, et mõlemad rakendused toetavad seda, mille te seadistasite. Teiselt platvormilt kopeeritud nimi võib tunduda süntaktiliselt tuttav samal ajal kui pistikprogramm või rakendus puudub täielikult.

IKE komplekt ja ESP komplekt on erinevad objektid

IKE ettepaneku muutmine ei paranda tagasilükatud CHILD ettepanekut ja ka vastupidi. strongSwanis on need eraldi seaded, umbes proposals = aes256-sha256-modp2048 IKE SA jaoks ja eraldi ESP loend CHILD SA jaoks. Muutke loendit, mis vastab ebaõnnestunud vahetusele, ja lugege seejärel logi uuesti, selle asemel et eeldada, et parandus toimis.

CHILD SA puhul on asjakohane seade ESP ettepanekute loend, mitte IKE loend. IKE rea sinna kopeerimine loob konfiguratsiooni, mis parsitakse, kuid läbiräägib vale objekti.

Töötav tunnel, mis ebaõnnestub võtmeuuendusel

Kui tunnel töötas tund aega ja siis ebaõnnestus, ei ole esialgne läbirääkimine probleem. Võtmeuuendus võib rakendada teisi tingimusi: teistsugune võtmevahetusgrupp pärast esimest vahetust, eluea lahknevus partnerite vahel või muudetud vastaja poliitika. Hoidke uuendamise ajatempel ja assotsiatsiooni identifikaatorid mõlemalt poolt. See muster nõuab uuendamisel ettepanekute võrdlemist, mitte pikemat ajalõppu. Ajalõpu muutmine peidab sümptomi ja jätab lahknevuse alles.

ipsec statusall näitab iga assotsiatsiooni ja tegelikult läbiräägitud algoritme. See väljund on kiireim viis kinnitada, millist loendit kasutati, ja eristab konfiguratsiooniviga tunnelist, mida ei ole kunagi uuesti läbiräägitud.

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

Valige ühisosa ja seejärel kinnitage mõlemad faasid

Las administraator valib dokumenteeritud kaasaegse ühisosa, mida mõlemad partnerid toetavad, ja kirjutab selle üles. Ärge lahendage viga kõigi vanade algoritmide lubamise ega identiteedi kontrollimise keelamisega, sest kumbki ei tulene tagasilükkamisest. Pärast muudatust looge uus ühendus ja seejärel sundige võtmeuuendus. Ainult esimene ühendus ei tõesta, et uuendamise tee töötab.

Hoidke vastuvõetud kombinatsiooni koos püsivara versioonidega. Kui järgmine viga puudutab liikluse valijaid, käsitlege seda eraldi, sest kokkulepe krüptograafias ei ütle midagi selle kohta, milliseid alamvõrke tunnel kaitseb. strongSwani ettepanekute dokumentatsioon katab mõlema loendi süntaksi.