Hvorfor din IPsec-tunnel virker indtil den første nøglefornyelse af CHILD SA

Tunnelen kom op, pinget svarede, og alle skrev under. Fire timer senere falder sessionen, parterne logger en fejl i forslaget eller nøgleudvekslingen, og den første formodning er, at noget ændrede sig på netværket. Intet ændrede sig. En tunnel, der bærer trafik, har bevist, at de to parter er enige om, hvordan man autentificerer, og hvordan man beskytter den første underordnede association, og den har intet bevist om den nøgleudveksling, de vil kræve ved fornyelsen. Uoverensstemmelsen sidder i hullet mellem de to begivenheder.

Forbundet betyder ikke, at PFS-indstillingerne er ens

Med IKEv2 oprettes den første underordnede association under autentificeringsudvekslingen, og dens nøgler udledes af materiale, som IKE-associationen allerede har produceret. Der sker ingen særskilt Diffie-Hellman-udveksling for den underordnede association, så en politik, der kræver en ved fornyelsen, afprøves ikke ved opstarten.

Fornyelsen er en anden udveksling. Når en underordnet associations nøgle fornys, kan parterne udføre en frisk nøgleudveksling med den gruppe, der er nævnt i deres forslag, og det er det første øjeblik, gruppeindstillingerne sammenlignes. To parter, der er uenige, kan derfor autentificere, installere en underordnet association og sende trafik, og derefter fejle ved fornyelsen.

Hvor uoverensstemmelsen gemmer sig i forslagsstrengen

I strongSwan tilføjes gruppen til det underordnede forslag, og derfor ser en streng som aes256gcm16-prfsha256-ecp256 ud som et krypteringsvalg, men bærer også et krav om nøgleudveksling. En part, der kun tilbyder aes256gcm16-prfsha256 har ikke det krav, og de to lister overlapper på kryptering, mens de er uenige om udvekslingen.

Læs det underordnede forslag og IKE-forslaget som separate lister. En gruppe, der optræder i IKE-listen, siger intet om den underordnede liste, og at redigere den ene, mens man læser den anden, er den sædvanlige måde at overse det på.

Læs fejlen, ikke den fil du redigerede

Find den notify, der afsluttede udvekslingen. En underordnet nøglefornyelse, der returnerer »intet acceptabelt forslag«, peger på forslagslisterne; en fornyelsesanmodning, der aldrig får svar, peger på stien eller på en part, der holdt op med at lytte. De to kræver forskellige rettelser, og formuleringen i loglinjen skiller dem.

Bekræft den kørende konfiguration frem for den på disken. En fil, der er gemt men ikke indlæst, eller en forbindelse, der er læst igen fra et andet include, vil give en uoverensstemmelse, som ingen redigering af den synlige fil kan rette.

Tre begivenheder, som alle kaldes nøglefornyelse

Fornyelse af IKE-associationsnøglen, IKE-genautentificering og fornyelse af den underordnede associations nøgle er separate operationer med separate forslagsregler. En fejl rapporteret ved en af dem siger intet direkte om de andre, og en log, der blander dem, læses som én tilbagevendende fejl, når den er tre.

Bemærk, hvilken begivenhed parterne nævner, og kontrollér derefter kun forslagene for den begivenhed. Ændr én liste, genindlæs, og fremtving den samme begivenhed igen. Hvis loggen nævner en genautentificering, er IKE-forslaget det, der skal læses. Hvis den nævner en underordnet nøglefornyelse, bærer det underordnede forslag den gruppe, der betyder noget.

At slå fornyelse fra er ikke en rettelse

At sætte fornyelsestiden til nul undertrykker den udveksling, der fejler, og tunnelen overlever derefter, indtil den rives ned, eller parterne genstarter. Det, du har købt, er en længere levetid for nøglen og en uoverensstemmelse, der vil møde dig igen under en migrering, en revision eller en opdatering fra leverandøren. Det samme gælder levetider, der strækkes langt ud over den politik, den anden side forventer.

Tilpas i stedet forslagene. Vælg en gruppe, som begge parter implementerer, sæt den i det underordnede forslag i begge ender, og hold fornyelsespolitikken inden for det interval, organisationen faktisk kræver.

Bevis det med den udveksling, der fejlede

Forkort den underordnede fornyelsestid i et vedligeholdelsesvindue, så begivenheden kommer i minutter i stedet for timer, eller udløs en manuel underordnet nøglefornyelse. Hold derefter øje med en vellykket fornyelse, og bekræft, at trafikken fortsætter gennem den, fordi et nyt håndtryk, der installerer en underordnet association, men taber applikationsstrømmen er en anden fejl.

Gendan derefter den normale levetid, og gem begge begivenhedsregistreringer, den fejlende og den vellykkede. Det bevis, du vil have, er, at forbindelsen overlever sin egen livscyklus, ikke at den overlevede et ping.