Hvorfor IPsec-tunnelen din virker til den første CHILD SA-nøkkelfornyelsen

Tunnelen kom opp, pinget svarte, og alle signerte. Fire timer senere faller sesjonen, partene logger en feil i forslaget eller nøkkelutvekslingen, og den første antakelsen er at noe endret seg på nettverket. Ingenting endret seg. En tunnel som bærer trafikk, har bevist at de to partene er enige om hvordan de autentiserer og hvordan de beskytter den første underordnede assosiasjonen, og den har ikke bevist noe om nøkkelutvekslingen de vil kreve ved fornyelsen. Avviket sitter i gapet mellom de to hendelsene.

Tilkoblet betyr ikke at PFS-innstillingene stemmer

Med IKEv2 opprettes den første underordnede assosiasjonen under autentiseringsutvekslingen, og nøklene dens utledes fra materiale som IKE-assosiasjonen allerede har produsert. Det skjer ingen egen Diffie-Hellman-utveksling for den underordnede assosiasjonen, så en policy som krever en ved fornyelsen, blir ikke prøvd ved oppstart.

Fornyelsen er en annen utveksling. Når nøkkelen til en underordnet assosiasjon fornyes, kan partene utføre en fersk nøkkelutveksling med gruppen som er navngitt i forslagene deres, og det er det første øyeblikket gruppeinnstillingene sammenlignes. To parter som er uenige, kan derfor autentisere, installere en underordnet assosiasjon og slippe trafikk gjennom, og deretter feile ved fornyelsen.

Hvor avviket gjemmer seg i forslagsstrengen

I strongSwan legges gruppen til det underordnede forslaget, og derfor ser en streng som aes256gcm16-prfsha256-ecp256 ut som et krypteringsvalg, men bærer også et krav om nøkkelutveksling. En part som bare tilbyr aes256gcm16-prfsha256 har ikke et slikt krav, og de to listene overlapper på kryptering mens de er uenige om utvekslingen.

Les det underordnede forslaget og IKE-forslaget som separate lister. En gruppe som vises i IKE-listen, sier ingenting om den underordnede listen, og å redigere den ene mens man leser den andre er den vanlige måten dette overses på.

Les feilen, ikke filen du redigerte

Finn notify-en som avsluttet utvekslingen. En underordnet nøkkelfornyelse som returnerer «ingen akseptabelt forslag», peker på forslagslistene; en fornyelsesforespørsel som aldri får svar, peker på banen eller på en part som sluttet å lytte. Disse to trenger ulike rettelser, og formuleringen i logglinjen skiller dem.

Bekreft den kjørende konfigurasjonen framfor den på disken. En fil som er lagret men ikke lastet, eller en tilkobling som er lest inn på nytt fra en annen include, vil gi et avvik som ingen redigering av den synlige filen kan rette.

Tre hendelser som alle kalles nøkkelfornyelse

Fornyelse av IKE-assosiasjonsnøkkelen, IKE-reautentisering og fornyelse av den underordnede assosiasjonsnøkkelen er separate operasjoner med separate forslagsregler. En feil rapportert ved en av dem sier ingenting direkte om de andre, og en logg som blander dem, leses som én tilbakevendende feil når den er tre.

Legg merke til hvilken hendelse parten nevner, og sjekk deretter bare forslagene for den hendelsen. Endre én liste, last inn på nytt og tving fram den samme hendelsen igjen. Hvis loggen nevner en reautentisering, er IKE-forslaget det som skal leses. Hvis den nevner en underordnet nøkkelfornyelse, bærer det underordnede forslaget gruppen som betyr noe.

Å slå av fornyelsen er ikke en rettelse

Å sette fornyelsestiden til null undertrykker utvekslingen som feiler, og tunnelen overlever deretter til den rives ned eller parten starter på nytt. Det du har kjøpt, er en lengre levetid for nøkkelen og et avvik som vil møte deg igjen under en migrering, en revisjon eller en oppdatering fra leverandøren. Det samme gjelder levetider som strekkes langt ut over policyen den andre siden forventer.

Juster heller forslagene. Velg en gruppe som begge parter implementerer, sett den i det underordnede forslaget i begge ender, og hold fornyelsespolicyen innenfor området organisasjonen faktisk krever.

Bevis det med utvekslingen som feilet

Forkort den underordnede fornyelsestiden i et vedlikeholdsvindu slik at hendelsen kommer i minutter istedenfor timer, eller utløs en manuell underordnet nøkkelfornyelse. Se deretter etter en vellykket fornyelse og bekreft at trafikken fortsetter gjennom den, fordi et nytt håndtrykk som installerer en underordnet assosiasjon men slipper applikasjonsflyten er en annen feil.

Gjenopprett deretter den normale levetiden og ta vare på begge hendelsesregistreringene, den feilende og den vellykkede. Beviset du vil ha, er at tilkoblingen overlever sin egen livssyklus, ikke at den overlevde en ping.