IKEv2: obnavljanje ključeva nasuprot ponovnoj autentifikaciji — zašto veza kasnije pada

Tunel se podiže ujutro i radi satima. Zatim padne, ponovo se poveže nakon pokušaja i sljedeći dan uradi isto. Na mreži se ništa nije promijenilo i niko nije dirao lozinku. Sesije koje padnu na granici obnavljanja obično prelaze jednu od dvije različite operacije, a samo jedna od njih ponovo provjerava vaše vjerodajnice. Čitanje toga koja je od njih djelovala jeste cijela dijagnoza.

Dvije operacije koje spolja izgledaju slično

Obnavljanje ključeva zamjenjuje sigurnosne asocijacije ili ključni materijal unutar razmjene koju propisuje protokol. Autentifikacija se ne ponavlja, pa se identitet prihvaćen na početku sesije jednostavno prenosi dalje.

Ponovna autentifikacija ide dalje: uspostavlja svjež autentificirani odnos, što znači da se vjerodajnice ponovo procjenjuju. Sve što je isteklo, bilo opozvano ili promijenjeno u direktoriju postaje vidljivo u tom trenutku.

Šta obnavljanje ključeva zapravo zamjenjuje

IKEv2 drži dvije vrste asocijacija s odvojenim životnim ciklusima. IKE SA štiti kontrolni kanal, a CHILD SA štite stvarni promet. Obnavljanje jedne nije sinonim za ponovno povezivanje klijenta.

Ta podjela objašnjava poznat obrazac: promet teče dobro, zatim se CHILD SA obnovi i prijedlog se više ne poklapa jer je neko prije sedmica uredio fazu 2 na jednoj strani. Promjena je stajala tamo bezopasno dok je obnavljanje nije pokrenulo.

Nesklad između trajanja ponaša se isto. Ona strana koja prva dosegne svoj limit započinje razmjenu, a druga je mora prihvatiti.

Šta ponovna autentifikacija ponovo procjenjuje

Uz ponovnu autentifikaciju, klijentski certifikat koji je bio valjan pri prijavi možda je sada istekao. Opozvana vjerodajnica, rotirana lozinka ili nedostupan drugi faktor svi se pojavljuju ovdje, a ne u vrijeme obnavljanja.

Zato izgleda kao da je produženje svakog trajanja popravka, a nije. Odgodili ste provjeru umjesto da ste je prošli. Sljedeće obnavljanje dolazi s istim defektom i s kraćim prozorom u kojem ga možete primijetiti.

Neke implementacije preklapaju staro i novo stanje tokom ponovne autentifikacije. Druge stvaraju kratku prazninu. Zato identična podešavanja kod dva dobavljača mogu dati različito korisničko iskustvo. Testirajte ponašanje umjesto da pretpostavljate da ga standard propisuje.

Pročitajte vremenske oznake prije nego što išta promijenite

Zabilježite trenutak kvara zajedno sa stanjem asocijacije prije i poslije. Ako je stara asocijacija zamijenjena bez razmjene autentifikacije, bili ste na granici obnavljanja. Ako se neposredno prije kvara pojavi razmjena AUTH, bili ste na ponovnoj autentifikaciji.

strongSwan to izlaže kao odvojena podešavanja: rekey upravlja obnavljanjem ključeva, reauth upravlja time da li se dogodi nova autentifikacija, a vrijednosti margin odlučuju koliko prije isteka svaka počinje. dokumentacija o obnavljanju ključeva opisuje tu interakciju i vrijedi je pročitati prije nego što kopirate trajanje s forumaške objave.

Razlikujte sve to od običnog gubitka mreže. Prekinuta veza proizvodi događaj otkrivanja mrtvog partnera ili oluju ponovnog slanja, a ne čistu razmjenu s odgovarajućim prijedlozima.

Promijenite onu stvar koja je pokvarila

Odbijanje vjerodajnice zahtijeva popravku problema identiteta: obnovite certifikat, vratite račun, ponovo registrirajte faktor. Nesklad prijedloga ili trajanja zahtijeva da se parametri uporede na obje strane.

Razvlačenje trajanja da bi se izbjegao simptom jedina je opcija koja uvijek izgleda kao da je uspjela i nikada ne uspije.

Testirajte kontrolirano obnavljanje

Prisilite obnavljanje umjesto da čekate dan za njega. Zatim ponovite s ponovnom autentifikacijom ako je implementacija podržava, i gledajte oba kraja.

Uspješna prva prijava ne vježba ništa od ovoga. Životni ciklus nakon nje je mjesto gdje se ove implementacije stvarno lome.