IKEv2: raktų atnaujinimas prieš pakartotinę autentifikaciją — kodėl ryšys nutrūksta vėliau

Tunelis pakyla ryte ir veikia valandas. Tada jis nutrūksta, po bandymo vėl prisijungia ir kitą dieną daro tą patį. Tinkle niekas nepasikeitė ir niekas nelietė slaptažodžio. Sesijos, kurios nepavyksta atnaujinimo riboje, paprastai peržengia vieną iš dviejų skirtingų operacijų, ir tik viena iš jų dar kartą patikrina jūsų prisijungimo duomenis. Perskaityti, kuri suveikė, yra visa diagnozė.

Dvi operacijos, kurios iš išorės atrodo panašiai

Raktų atnaujinimas pakeičia saugos asociacijas arba raktų medžiagą protokolo apibrėžtame mainuose. Autentifikacija nekartojama, todėl sesijos pradžioje priimta tapatybė tiesiog perkeliama toliau.

Pakartotinė autentifikacija eina toliau: ji sukuria naują autentifikuotą ryšį, o tai reiškia, kad prisijungimo duomenys vertinami iš naujo. Viskas, kas pasibaigė, buvo atšaukta arba pasikeitė kataloge, tampa matoma tuo momentu.

Ką raktų atnaujinimas iš tikrųjų pakeičia

IKEv2 laiko dviejų rūšių asociacijas su atskirais gyvavimo ciklais. IKE SA saugo valdymo kanalą, o CHILD SA saugo faktinį srautą. Vienos atnaujinimas nėra sinonimas kliento prisijungimui iš naujo.

Šis atskyrimas paaiškina pažįstamą modelį: srautas teka gerai, tada atnaujinama CHILD SA ir pasiūlymas nebeatitinka, nes kažkas prieš savaites vienoje pusėje paredagavo 2 fazę. Pakeitimas gulėjo ten nekenksmingai, kol atnaujinimas jo nepanaudojo.

Gyvavimo trukmės neatitikimai elgiasi taip pat. Kuri pusė pirmoji pasiekia savo ribą, pradeda mainus, o kita turi juos priimti.

Ką pakartotinė autentifikacija vertina iš naujo

Pakartotinės autentifikacijos metu kliento sertifikatas, kuris buvo galiojantis prisijungus, dabar gali būti pasibaigęs. Atšaukti prisijungimo duomenys, pakeistas slaptažodis ar nepasiekiamas antrasis veiksnys visi iškyla čia, o ne atnaujinimo metu.

Štai kodėl kiekvienos trukmės pratęsimas atrodo kaip taisymas ir nėra juo. Jūs atidėjote patikrinimą, o ne jį praėjote. Kitas atnaujinimas ateina su tuo pačiu defektu ir trumpesniu pertraukos langu jam pastebėti.

Kai kurios implementacijos pakartotinės autentifikacijos metu perdengia seną ir naują būseną. Kitos sukuria trumpą tarpą. Todėl identiški nustatymai pas du tiekėjus gali duoti skirtingą naudotojo patirtį. Testuokite elgseną, o ne manykite, kad standartas ją nustato.

Perskaitykite laiko žymes prieš ką nors keisdami

Užfiksuokite gedimo momentą kartu su asociacijos būsena prieš ir po. Jei senoji asociacija buvo pakeista be autentifikacijos mainų, buvote atnaujinimo riboje. Jei prieš pat gedimą pasirodo AUTH mainai, buvote pakartotinėje autentifikacijoje.

strongSwan tai pateikia kaip atskirus nustatymus: rekey valdo raktų atnaujinimą, reauth valdo, ar įvyksta nauja autentifikacija, o margin reikšmės nusprendžia, kiek prieš pasibaigimą kiekviena prasideda. raktų atnaujinimo dokumentacija aprašo sąveiką, ir verta ją perskaityti prieš kopijuojant trukmę iš forumo pranešimo.

Atskirkite visa tai nuo paprasto tinklo praradimo. Nutraukta jungtis sukuria negyvo partnerio aptikimo įvykį arba pakartotinio siuntimo audrą, o ne švarų mainą su atitinkančiais pasiūlymais.

Pakeiskite tai, kas nepavyko

Prisijungimo duomenų atmetimas reikalauja ištaisyti tapatybės problemą: atnaujinkite sertifikatą, atkurkite paskyrą, iš naujo registruokite veiksnį. Pasiūlymo ar trukmės neatitikimas reikalauja palyginti parametrus abiejose pusėse.

Trukmių tempimas, siekiant išvengti simptomo, yra vienintelė parinktis, kuri visada atrodo, kad suveikė, ir niekada nesuveikia.

Išbandykite kontroliuojamą atnaujinimą

Priverstinai atlikite atnaujinimą, o ne laukite jo dieną. Tada pakartokite su pakartotine autentifikacija, jei diegimas ją palaiko, ir stebėkite abu galus.

Sėkmingas pirmasis prisijungimas nieko iš to nepraktikuoja. Gyvavimo ciklas po jo yra vieta, kur šie diegimai iš tikrųjų lūžta.