IKEv2 NO_PROPOSAL_CHOSEN: hvilket trinn avviste settet?

NO_PROPOSAL_CHOSEN i en logg sender folk mot den forhåndsdelt nøkkelen, og feilen overlever endringen. Det var aldri et legitimasjonsproblem: peeren avviste hvert forslag som ble tilbudt for den utvekslingen, noe som er en uttalelse om algoritmer og ikke om identitet. Det første nyttige spørsmålet er ikke hvilken algoritme som skal redigeres, men hvilken utveksling som ble avvist. Svar på det før du sammenligner noe. Sammenlign deretter det fulle settet som ble tilbudt, med det fulle settet peeren tillater.

Først: hvilken utveksling ble avvist

IKEv2 forhandler to slags assosiasjoner. IKE SA beskytter selve forhandlingen, og CHILD SA beskytter trafikken. Hver har sitt eget forslagssett, og hver kan feile med samme varsel. En avvisning under den innledende IKE-forhandlingen og en avvisning under CHILD-forhandlingen krever forskjellige rettelser, og loggen navngir vanligvis utvekslingen en linje eller to over varselet. Les de to linjene sammen, ellers redigerer du feil forslagsliste.

Varselet alene identifiserer ikke utvekslingen. Linjen over navngir SA-en som forhandles, og navnet peker på forslagslisten som skal undersøkes.

Sammenlign komplette sett, ikke enkeltord

Et forslag er en kombinasjon: krypteringsalgoritme, integritet eller AEAD, nøkkelutvekslingsgruppe og eventuell pseudotilfeldig funksjon. Å sammenligne bare krypteringsnavnet er den vanlige feilen, fordi to peers kan være enige om AES-256 og fortsatt uenige om SHA-1 kontra SHA-256. Skriv de tilbudte og tillatte settene side ved side på trinnet som feilet, og se deretter etter den tomme snittmengden.

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

Kontroller også at begge implementasjonene støtter det du har konfigurert. Et navn kopiert fra en annen plattform kan se syntaktisk kjent ut mens programtillegget eller implementasjonen mangler helt.

IKE-settet og ESP-settet er forskjellige objekter

Å redigere IKE-forslaget reparerer ikke et avvist CHILD-forslag, og det motsatte gjelder også. I strongSwan er dette separate innstillinger, omtrent proposals = aes256-sha256-modp2048 for IKE SA og en separat ESP-liste for CHILD SA. Endre listen som samsvarer med den feilede utvekslingen, og les deretter loggen på nytt i stedet for å anta at rettelsen virket.

For CHILD SA er den relevante innstillingen ESP-forslagslisten, ikke IKE-listen. Å kopiere IKE-linjen inn i den gir en konfigurasjon som parses, men forhandler det gale objektet.

En fungerende tunnel som feiler ved nøkkelnying

Hvis tunnelen kjørte i en time og deretter feilet, er ikke den innledende forhandlingen problemet. En nøkkelnying kan prøve andre betingelser: en annen nøkkelutvekslingsgruppe etter den første utvekslingen, en levetidsforskjell mellom peerne eller en endret responder-policy. Ta vare på fornyelsestidsstempelet og assosiasjonsidentifikatorene fra begge sider. Det mønsteret krever en forslagssammenligning ved fornyelsen, ikke en lengre tidsavbrudd. En endring av tidsavbruddet skjuler symptomet og lar uoverensstemmelsen bli stående.

ipsec statusall viser hver assosiasjon og algoritmene som faktisk ble forhandlet. Den utskriften er den raskeste måten å bekrefte hvilken liste som ble brukt, og den skiller en konfigurasjonsfeil fra en foreldet tunnel som aldri ble forhandlet på nytt.

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

Velg en snittmengde, og bekreft deretter begge fasene

La administratoren velge en dokumentert moderne snittmengde som begge peerne støtter, og skrive den ned. Ikke løs feilen ved å aktivere alle eldre algoritmer eller ved å deaktivere identitetsbekreftelse, fordi ingen av delene følger av en avvisning. Etter endringen opprettes en ny tilkobling, og deretter tvinges en nøkkelnying. Den første tilkoblingen alene beviser ikke at fornyelsesveien virker.

Ta vare på den aksepterte kombinasjonen sammen med fastvareversjonene. Hvis den neste feilen gjelder traffic selectors, behandles den separat, siden enighet om kryptografi ikke sier noe om hvilke subnett tunnelen beskytter. strongSwans forslagsdokumentasjon dekker syntaksen for begge listene.