Zašto vaš IPsec tunel radi do prvog obnavljanja ključa CHILD SA

Tunel se podigao, ping je odgovorio i svi su potpisali. Četiri sata kasnije sesija padne, strane zabilježe pogrešku u prijedlogu ili razmjeni ključeva, a prva pretpostavka je da se nešto promijenilo na mreži. Ništa se nije promijenilo. Tunel koji prenosi promet dokazao je da se dvije strane slažu kako se autentificirati i kako zaštititi prvu podređenu asocijaciju, a nije dokazao ništa o razmjeni ključeva koju će zahtijevati pri obnovi. Nesklad leži u praznini između tih dvaju događaja.

Povezanost ne znači da se PFS postavke slažu

Uz IKEv2, prva podređena asocijacija nastaje tijekom razmjene autentifikacije, a njezini se ključevi izvode iz materijala koji je IKE asocijacija već proizvela. Za tu se podređenu asocijaciju ne odvija zasebna Diffie-Hellman razmjena, pa se politika koja je zahtijeva pri obnovi ne provjerava pri podizanju.

Obnova je druga razmjena. Kada se ključ podređene asocijacije obnovi, strane mogu izvesti novu razmjenu ključeva sa skupinom navedenom u njihovim prijedlozima, i to je prvi trenutak kada se postavke skupine uspoređuju. Zato se dvije strane koje se ne slažu mogu autentificirati, instalirati podređenu asocijaciju i propustiti promet, a zatim pasti pri obnovi.

Gdje se nesklad skriva u nizu prijedloga

U strongSwanu se skupina dodaje na prijedlog podređene asocijacije, zbog čega niz poput aes256gcm16-prfsha256-ecp256 izgleda kao izbor šifriranja, ali nosi i zahtjev za razmjenu ključeva. Strana koja nudi samo aes256gcm16-prfsha256 nema takav zahtjev, a dva se popisa sijeku u šifriranju dok se razilaze u razmjeni.

Čitajte prijedlog podređene asocijacije i IKE prijedlog kao odvojene popise. Skupina koja se pojavljuje u IKE popisu ne govori ništa o popisu podređene asocijacije, a uređivanje jednoga dok čitate drugi uobičajen je način da se to propusti.

Čitajte neuspjeh, a ne datoteku koju ste uredili

Pronađite notify koji je okončao razmjenu. Obnova ključa podređene asocijacije koja vraća „nema prihvatljivog prijedloga“ upućuje na popise prijedloga; zahtjev za obnovu koji nikada ne dobije odgovor upućuje na putanju ili na stranu koja je prestala slušati. Ta dva slučaja traže različite popravke, a formulacija retka u dnevniku ih razdvaja.

Potvrdite radnu konfiguraciju, a ne onu na disku. Datoteka spremljena ali ne učitana, ili veza ponovno pročitana iz drugog include-a, proizvest će nesklad koji nikakvo uređivanje vidljive datoteke ne može ispraviti.

Tri događaja koja svi nazivaju obnovom ključa

Obnova ključa IKE asocijacije, ponovna autentifikacija IKE i obnova ključa podređene asocijacije odvojene su operacije s odvojenim pravilima prijedloga. Neuspjeh prijavljen na jednoj od njih ne govori ništa izravno o ostalima, a dnevnik koji ih miješa čita se kao jedan ponavljajući kvar dok su tri.

Zabilježite koji događaj strana navodi, pa provjerite prijedloge samo za taj događaj. Promijenite jedan popis, ponovno učitajte i ponovno izazovite isti događaj. Ako dnevnik navodi ponovnu autentifikaciju, IKE prijedlog je onaj koji treba čitati. Ako navodi obnovu ključa podređene asocijacije, prijedlog podređene asocijacije nosi skupinu koja je bitna.

Isključivanje obnove nije popravak

Postavljanje vremena obnove ključa na nulu potiskuje razmjenu koja ne uspijeva, a tunel zatim preživi dok se ne razmontira ili strana ne restartira. Ono što ste kupili jest ključ koji dulje traje i nesklad koji će vas ponovno sresti tijekom migracije, revizije ili ažuriranja dobavljača. Isto vrijedi i za životne vijekove razvučene daleko iznad politike koju druga strana očekuje.

Umjesto toga uskladite prijedloge. Odaberite skupinu koju obje strane implementiraju, stavite je u prijedlog podređene asocijacije na oba kraja i držite politiku obnove unutar raspona koji organizacija zaista zahtijeva.

Dokažite to razmjenom koja nije uspjela

Skratite vrijeme obnove ključa podređene asocijacije u prozoru za održavanje da događaj stigne za nekoliko minuta, a ne sati, ili pokrenite ručnu obnovu. Zatim pazite na uspješnu obnovu i potvrdite da promet prolazi kroz nju, jer novo rukovanje koje instalira podređenu asocijaciju ali ispusti tok aplikacije je druga pogreška.

Poslije vratite normalni životni vijek i sačuvajte oba zapisa o događajima, neuspjeli i uspješni. Dokaz koji želite jest da veza preživi vlastiti životni ciklus, a ne da je preživjela ping.