IKEv2 NO_PROPOSAL_CHOSEN: kva trinn avviste settet?

NO_PROPOSAL_CHOSEN i ein logg sender folk mot den førehandsdelt nøkkelen, og feilen overlever endringa. Det var aldri eit problem med legitimasjon: peeren avviste kvart forslag som vart tilbode for den utvekslinga, noko som er ei utsegn om algoritmar og ikkje om identitet. Det første nyttige spørsmålet er ikkje kva algoritme som skal redigerast, men kva utveksling som vart avvist. Svar på det før du samanliknar noko. Samanlikn deretter det fulle settet som vart tilbode, med det fulle settet peeren tillèt.

Først: kva utveksling vart avvist

IKEv2 forhandlar to slag assosiasjonar. IKE SA vernar sjølve forhandlinga, og CHILD SA vernar trafikken. Kvar har sitt eige forslagssett, og kvar kan feile med same varsel. Ei avvising under den innleiande IKE-forhandlinga og ei avvising under CHILD-forhandlinga krev ulike rettingar, og loggen namngjev vanlegvis utvekslinga ei line eller to over varselet. Les dei to linjene saman, elles redigerer du feil forslagsliste.

Varselet åleine identifiserer ikkje utvekslinga. Lina over namngjev SA-en som vert forhandla, og namnet peikar på forslagslista som skal undersøkjast.

Samanlikn komplette sett, ikkje enkeltord

Eit forslag er ein kombinasjon: krypteringsalgoritme, integritet eller AEAD, nøkkelutvekslingsgruppe og eventuell pseudotilfeldig funksjon. Å samanlikne berre krypteringsnamnet er den vanlege feilen, fordi to peerar kan vere samde om AES-256 og framleis usamde om SHA-1 kontra SHA-256. Skriv dei tilbydde og tillatne setta side ved side på trinnet som feila, og sjå deretter etter den tomme snittmengda.

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

Kontroller òg at begge implementasjonane støttar det du har konfigurert. Eit namn kopiert frå ein annan plattform kan sjå syntaktisk kjent ut medan programtillegget eller implementasjonen manglar heilt.

IKE-settet og ESP-settet er ulike objekt

Å redigere IKE-forslaget reparerer ikkje eit avvist CHILD-forslag, og det motsette gjeld òg. I strongSwan er dette separate innstillingar, omtrent proposals = aes256-sha256-modp2048 for IKE SA og ei separat ESP-liste for CHILD SA. Endre lista som svarar til den feila utvekslinga, og les deretter loggen på nytt i staden for å anta at rettinga verka.

For CHILD SA er den relevante innstillinga ESP-forslagslista, ikkje IKE-lista. Å kopiere IKE-lina inn i ho gjev ein konfigurasjon som vert parsa, men forhandlar det gale objektet.

Ein fungerande tunnel som feilar ved nøkkelnying

Viss tunnelen køyrde i ein time og deretter feila, er ikkje den innleiande forhandlinga problemet. Ei nøkkelnying kan prøve andre vilkår: ei anna nøkkelutvekslingsgruppe etter den første utvekslinga, ein levealder-skilnad mellom peerane eller ein endra responder-policy. Ta vare på fornyingstidsstempelet og assosiasjonsidentifikatorane frå begge sider. Det mønsteret krev ein forslagssamanliknad ved fornyinga, ikkje ein lengre tidsavbrot. Ei endring av tidsavbrotet gøymer symptomet og lèt skilnaden stå.

ipsec statusall viser kvar assosiasjon og algoritmane som faktisk vart forhandla. Den utskrifta er den raskaste måten å stadfeste kva liste som vart brukt, og ho skil ein konfigurasjonsfeil frå ein forelda tunnel som aldri vart forhandla på nytt.

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

Vel ei snittmengd, og stadfest deretter begge fasane

La administratoren velje ei dokumentert moderne snittmengd som begge peerane støttar, og skrive ho ned. Ikkje løys feilen ved å slå på alle eldre algoritmar eller ved å slå av identitetsstadfesting, fordi ingen av delane følgjer av ei avvising. Etter endringa vert ei ny tilkopling oppretta, og deretter vert ei nøkkelnying tvinga. Den første tilkoplinga åleine beviser ikkje at fornyingsvegen verkar.

Ta vare på den aksepterte kombinasjonen saman med fastvareversjonane. Viss den neste feilen gjeld traffic selectors, handsam han separat, sidan semje om kryptografi ikkje seier noko om kva subnett tunnelen verner. strongSwans forslagsdokumentasjon dekkjer syntaksen for begge listene.