Kvifor IPsec-tunnelen din verkar til den første CHILD SA-nøkkelfornyinga

Tunnelen kom opp, pinget svara, og alle signerte. Fire timar seinare fell økta, partane loggar ein feil i forslaget eller nøkkelutvekslinga, og den første antakinga er at noko endra seg på nettet. Ingenting endra seg. Ein tunnel som ber trafikk, har prova at dei to partane er samde om korleis dei autentiserer og korleis dei verner den første underordna assosiasjonen, og han har ikkje prova noko om nøkkelutvekslinga dei vil krevja ved fornyinga. Avviket sit i gapet mellom dei to hendingane.

Tilkopla tyder ikkje at PFS-innstillingane stemmer

Med IKEv2 blir den første underordna assosiasjonen oppretta under autentiseringsutvekslinga, og nøklane hans blir leidde ut frå materiale som IKE-assosiasjonen alt har produsert. Det skjer inga eiga Diffie-Hellman-utveksling for den underordna assosiasjonen, så ein policy som krev ei ved fornyinga, blir ikkje prøvd ved oppstart.

Fornyinga er ei anna utveksling. Når nøkkelen til ein underordna assosiasjon blir fornya, kan partane gjera ei fersk nøkkelutveksling med gruppa som er namngjeven i forslaga deira, og det er det første augneblinket gruppeinnstillingane blir samanlikna. To partar som er usamde, kan difor autentisera, installera ein underordna assosiasjon og sleppa trafikk gjennom, og deretter feila ved fornyinga.

Kvar avviket gøymer seg i forslagsstrengen

I strongSwan blir gruppa lagd til det underordna forslaget, og difor ser ein streng som aes256gcm16-prfsha256-ecp256 ut som eit krypteringsval, men ber òg eit krav om nøkkelutveksling. Ein part som berre tilbyr aes256gcm16-prfsha256 har ikkje eit slikt krav, og dei to listene overlappar på kryptering medan dei er usamde om utvekslinga.

Les det underordna forslaget og IKE-forslaget som separate lister. Ei gruppe som viser seg i IKE-lista, seier ingenting om den underordna lista, og å redigera den eine medan ein les den andre er den vanlege måten dette blir oversett på.

Les feilen, ikkje fila du redigerte

Finn notify-en som avslutta utvekslinga. Ei underordna nøkkelfornying som returnerer «ingen akseptabelt forslag», peikar på forslagslistene; ein fornyingsførespurnad som aldri får svar, peikar på banen eller på ein part som slutta å lytta. Desse to treng ulike rettingar, og formuleringa i logglina skil dei.

Stadfest den køyrande konfigurasjonen framfor den på disken. Ei fil som er lagra men ikkje lasta, eller ei tilkopling som er lesen inn på nytt frå ein annan include, vil gje eit avvik som inga redigering av den synlege fila kan retta.

Tre hendingar som alle blir kalla nøkkelfornying

Fornying av IKE-assosiasjonsnøkkelen, IKE-reautentisering og fornying av den underordna assosiasjonsnøkkelen er separate operasjonar med separate forslagsreglar. Ein feil rapportert ved ein av dei seier ingenting direkte om dei andre, og ein logg som blandar dei, blir lesen som éin tilbakevendande feil når han er tre.

Legg merke til kva hending parten nemner, og sjekk deretter berre forslaga for den hendinga. Endra éi liste, last inn på nytt og tving fram den same hendinga igjen. Viss loggen nemner ein reautentisering, er IKE-forslaget det som skal lesast. Viss han nemner ei underordna nøkkelfornying, ber det underordna forslaget gruppa som tyder noko.

Å slå av fornyinga er ikkje ei retting

Å setja fornyingstida til null undertrykkjer utvekslinga som feilar, og tunnelen overlever deretter til han blir riven ned eller parten startar på nytt. Det du har kjøpt, er ei lengre levetid for nøkkelen og eit avvik som vil møta deg igjen under ein migrasjon, ein revisjon eller ei oppdatering frå leverandøren. Det same gjeld levetider som blir strekte langt ut over policyen den andre sida ventar.

Juster heller forslaga. Vel ei gruppe som begge partar implementerer, set henne i det underordna forslaget i begge endar, og hald fornyingspolicyen innanfor området organisasjonen faktisk krev.

Prov det med utvekslinga som feila

Forkort den underordna fornyingstida i eit vedlikehaldsvindauge slik at hendinga kjem i minutt i staden for timar, eller utløys ei manuell underordna nøkkelfornying. Sjå deretter etter ei vellukka fornying og stadfest at trafikken held fram gjennom henne, fordi eit nytt handtrykk som installerer ein underordna assosiasjon men slepp applikasjonsstraumen er ein annan feil.

Gjenopprett deretter den normale levetida og ta vare på begge hendingsregistreringane, den feilande og den vellukka. Provet du vil ha, er at tilkoplinga overlever sin eigen livssyklus, ikkje at ho overlevde ein ping.