Nøkkelbytte, attilkopling eller reautentisering: kva treng du?

Ei økt som har køyrt i timar held ikkje dei same nøklane for alltid, og det er med vilje. Tre ulike hendingar vert kalla nøkkelrotasjon: nytt øktmateriale under ein eksisterande assosiasjon, ein full gjenoppbygging av sambandet og ei gjentaking av identitetskontrollen. Kvar har ein annan utløysar, ein annan kostnad og ein annan feilsignatur. Vel du feil, gjer rettinga anten ingenting eller tek tunnelen ned utan grunn.

Avgjerda avheng av kva lag som faktisk er gått ut.

Tre operasjonar som vert kalla rotasjon

Eit nøkkelbytte lagar ferske trafiksnøklar innanfor det eksisterande kontrollhøvet, ved hjelp av mekanismen protokollen definerer. IKEv2 gjer det med ein ny underordna tryggleiksassosiasjon, TLS 1.3 med ei nøkkeloppdateringsmelding, og WireGuard med eit nytt handtrykk når tids- eller meldingsgrensene er nådde. Tunneladressene og den autentiserte identiteten vert verande der dei var.

Attilkopling kastar sambandet og byggjer det opp att frå byrjinga, noko som gjentek adressetildeling, installasjon av ruter og kvar forhandling den fyrste freistnaden gjorde.

Reautentisering gjentek sjølve identitetsprovet, som kan omfatte eit passord, eit sertifikat eller ein annan faktor. Det kan skje med eller utan attilkopling, avhengig av produktet.

Kva brukarane legg merke til ved fornying

Eit nøkkelbytte bør vere nesten usynleg. Assosiasjons-ID-ar endrar seg, teljarar kan nullstillast, og applikasjonar held på socketane sine; ein kort pause i éi retning er normalt under utvekslinga. Ein ny ID i ei statusliste er ikkje prov på feil. Logglinja som følgjer utvekslinga, er det som fortel deg om ho vart ferdig.

Eit faktisk brot ved fornying peikar på noko bestemt. Ueinigheit i forslaget, eit utgått passord eller ei endra sti gjev kvar si logglinje, og berre éi av dei vert retta ved å justere levetider.

Kvar dei tre skil lag i praksis

Er det einaste som er gått ut nøkkelmateriale, gjer eit nøkkelbytte. Er peer-adressa, ruta eller NAT-bindinga endra og pakkane kjem ikkje lenger, kople til på nytt. Krev organisasjonen ein periodisk identitetskontroll, er det reautentisering, og inga justering av levetider erstattar han.

Standardverdiane i protokollane inneheld vanlegvis det rette svaret. WireGuard byter nøkkel etter ei tids- og datamengdegrense utan brukarinngrep; IKEv2-levetider vert forhandla per underordna assosiasjon; TLS-baserte tunnelar roterer nøklar inne i den eksisterande økta. Å auke levetidene for å unngå ein tilbakevendande feil utset feilen og forlengjer eksponeringa om ein nøkkel vert kompromittert.

Eitt atterhald er viktig for lange økter: hyppigheit åleine skapar ikkje forward secrecy. Eigenskapen avheng av korleis øktnøklar høver til langsiktige løyndomar og om gamle nøklar vert øydelagde, noko som er eit design- og implementeringsspørsmål, ikkje ei innstilling.

Vel standardverdiar, og registrer deretter fasen

Hald på standardverdiane til leverandøren med mindre eit dokumentert krav seier noko anna, og endre levetider på begge peerane om du endrar dei i det heile. Registrer deretter kva fase kvar hending nådde, slik at neste førekomst kan kontrollerast mot same punkt i handtrykket.

swanctl --list-sas
ip xfrm state | grep -E 'proto|replay-window'
wg show
journalctl -u strongswan --since '1 hour ago' | grep -i -E 'rekey|rekeyed|child'

Etter ei retting, køyr ei kontrollert fornying og send fersk applikasjonstrafikk gjennom den nye assosiasjonen. Ein tunnel som melder at han er etablert men ikkje videresender noko, er feilen denne kontrollen finst for å fange.