IKEv2 NO_PROPOSAL_CHOSEN: watter stadium het die stel verwerp?

NO_PROPOSAL_CHOSEN in 'n logboek stuur mense na die vooraf-gedeelde sleutel, en die fout oorleef die verandering. Dit was nooit 'n geloofwaardigheidsprobleem nie: die eweknie het elke voorstel vir daardie uitruiling verwerp, wat 'n stelling oor algoritmes eerder as identiteit is. Die eerste nuttige vraag is nie watter algoritme om te wysig nie, maar watter uitruiling verwerp is. Beantwoord dit voordat jy enigiets vergelyk. Vergelyk dan die volledige stel wat aangebied is met die volledige stel wat die eweknie toelaat.

Eerste: watter uitruiling is verwerp

IKEv2 onderhandel twee soorte assosiasie. Die IKE SA beskerm die onderhandeling self, en die CHILD SA beskerm die verkeer. Elkeen het sy eie voorstelstel, en elkeen kan met dieselfde kennisgewing misluk. 'n Verwerping tydens die aanvanklike IKE-onderhandeling en 'n verwerping tydens CHILD-onderhandeling vereis verskillende regstellings, en die logboek noem gewoonlik die uitruiling 'n lyn of twee bo die kennisgewing. Lees daardie twee reëls saam, of jy sal die verkeerde voorstelllys wysig.

Die kennisgewing alleen identifiseer nie die uitruiling nie. Die lyn bo dit noem die SA wat onderhandel word, en daardie naam wys na die voorstelllys wat ondersoek moet word.

Vergelyk volledige stelle, nie enkele sleutelwoorde nie

A voorstel is 'n kombinasie: enkripsie-algoritme, integriteit of AEAD, sleutel-uitruilgroep en enige pseudo-eweredige funksie. Om net die enkripsienaam te vergelyk is die gewone fout, want twee eweknieë kan oor AES-256 ooreenkom en steeds oor SHA-1 teenoor SHA-256 verskil. Skryf die aangebode en toegelate stelle langs mekaar by die mislukte stadium, en soek dan die leë snypunt.

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

Kontroleer ook dat beide implementasies ondersteun wat jy gekonfigureer het. 'n Naam wat van 'n ander platform gekopieer is, kan sintakties bekend lyk terwyl die inprop of implementasie heeltemal ontbreek.

IKE-stel en ESP-stel is verskillende objekte

Wysiging van die IKE-voorstel sal nie 'n verwerpte CHILD-voorstel regstel nie, en die omgekeerde is ook waar. In strongSwan is dit afsonderlike instellings, omtrent proposals = aes256-sha256-modp2048 vir die IKE SA en 'n afsonderlike ESP-lys vir die CHILD SA. Verander die lys wat by die mislukte uitruiling pas, en lees dan die logboek weer eerder as om aan te neem die regstelling het gewerk.

Vir die CHILD SA is die relevante instelling die ESP-voorstellys, nie die IKE een nie. Om die IKE-lyn daarin te kopieer, lewer 'n konfigurasie wat ontleed en die verkeerde objek onderhandel.

'n Werkende tonnel wat by hernuwing van sleutels misluk

Het die tonnel 'n uur lank geloop en toe misluk, is die aanvanklike onderhandeling nie die probleem nie. 'n Heronderhandeling van sleutels kan ander toestande gebruik: 'n ander sleutel-uitruilgroep ná die eerste uitruiling, 'n leeftyd-misverhouding tussen eweknieë, of 'n antwoorder-beleid wat verander het. Bewaar die hernuwingstydstempel en die assosiasie-identifiseerders van beide kante. Daardie patroon vereis 'n voorstelvergeliking by hernuwing, nie 'n langer verstektyd nie. 'n Verstektydverandering verberg die simptoom en laat die mispas in plek.

ipsec statusall wys elke assosiasie en die algoritmes wat werklik onderhandel is. Daardie uitset is die vinnigste manier om te bevestig watter lys gebruik is, en dit skei 'n konfigurasiefout van 'n verouderde tonnel wat nooit weer onderhandel het nie.

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

Kies 'n snypunt, bevestig dan beide fases

Laat die administrateur 'n gedokumenteerde moderne snypunt kies wat beide eweknieë ondersteun, en skryf dit neer. Moenie die fout oplos deur elke erfenis-algoritme te aktiveer of identiteitsverifikasie uit te skakel nie, want geen van beide volg uit 'n verwerping nie. Stel ná die verandering 'n nuwe verbinding op en dwing dan 'n hernuwing van sleutels af. Die eerste verbinding alleen bewys nie dat die hernuwingspad werk nie.

Bewaar die aanvaarde kombinasie saam met die firmware-weergawes. As die volgende fout verkeerselektore betref, behandel dit afsonderlik, want ooreenkoms oor kriptografie sê niks oor watter subnetwerke die tonnel beskerm nie. strongSwan se voorstel-dokumentasie dek die sintaksis vir beide lyste.