Zakaj vaš tunel IPsec deluje do prve obnove ključa CHILD SA

Tunel se je dvignil, ping je odgovoril in vsi so podpisali. Štiri ure pozneje seja pade, strani zabeležita napako v predlogu ali v izmenjavi ključev, in prva domneva je, da se je v omrežju nekaj spremenilo. Nič se ni spremenilo. Tunel, ki prenaša promet, je dokazal, da se obe strani strinjata, kako se avtenticirati in kako zaščititi prvo podrejeno asociacijo, in ni dokazal ničesar o izmenjavi ključev, ki jo bosta zahtevali pri obnovi. Neskladje sedi v vrzeli med tema dvema dogodkoma.

Povezanost ne pomeni, da se nastavitve PFS ujemajo

Pri IKEv2 prva podrejena asociacija nastane med izmenjavo avtentikacije, njeni ključi pa se izpeljejo iz gradiva, ki ga je asociacija IKE že ustvarila. Za to podrejeno asociacijo se ne izvede ločena izmenjava Diffie-Hellman, zato se politika, ki jo zahteva pri obnovi, pri dvigu ne preizkusi.

Obnova je druga izmenjava. Ko se ključ podrejene asociacije obnovi, lahko strani izvedeta novo izmenjavo ključev s skupino, navedeno v njunih predlogih, in to je prvi trenutek, ko se nastavitve skupine primerjajo. Zato se dve strani, ki se ne strinjata, lahko avtenticirata, namestita podrejeno asociacijo in spustita promet, nato pa pri obnovi spodletita.

Kje se neskladje skriva v nizu predloga

V strongSwanu se skupina doda predlogu podrejene asociacije, zato je niz, kot je aes256gcm16-prfsha256-ecp256 videti kot izbira šifriranja, vendar nosi tudi zahtevo po izmenjavi ključev. Stran, ki ponuja le aes256gcm16-prfsha256 nima take zahteve, in oba seznama se sekata pri šifriranju, a se razhajata pri izmenjavi.

Berite predlog podrejene asociacije in predlog IKE kot ločena seznama. Skupina, ki se pojavi na seznamu IKE, ne pove ničesar o podrejenem seznamu, in urejanje enega med branjem drugega je običajen način, da se to spregleda.

Berite napako, ne datoteke, ki ste jo uredili

Poiščite notify, ki je končal izmenjavo. Obnova ključa podrejene asociacije, ki vrne »nobenega sprejemljivega predloga«, kaže na sezname predlogov; zahteva za obnovo, ki nikoli ne prejme odgovora, kaže na pot ali na stran, ki je prenehala poslušati. Ta dva primera zahtevata različna popravka in besedilo vrstice v dnevniku ju loči.

Potrdite delujočo konfiguracijo, ne tiste na disku. Datoteka, shranjena a ne naložena, ali povezava, znova prebrana iz drugega include, bosta ustvarili neskladje, ki ga nobeno urejanje vidne datoteke ne more popraviti.

Trije dogodki, ki jim vsi rečejo obnova ključa

Obnova ključa asociacije IKE, ponovna avtentikacija IKE in obnova ključa podrejene asociacije so ločene operacije z ločenimi pravili predlogov. Napaka, sporočena pri eni od njih, ne pove ničesar neposredno o drugih, dnevnik, ki jih meša, pa se bere kot ena sama ponavljajoča se okvara, čeprav so tri.

Upoštevajte, kateri dogodek navaja stran, nato preverite predloge le za ta dogodek. Spremenite en seznam, znova naložite in znova vsilite isti dogodek. Če dnevnik navaja ponovno avtentikacijo, je treba brati predlog IKE. Če navaja obnovo ključa podrejene asociacije, pomembno skupino nosi predlog podrejene asociacije.

Izklop obnove ni popravek

Če čas obnove ključa nastavite na nič, se izmenjava, ki spodleti, zatre, in tunel nato preživi, dokler ga ne razstavijo ali se stran znova zažene. Kar ste kupili, je dlje živeč ključ in neskladje, ki vas bo znova srečalo med selitvijo, revizijo ali posodobitvijo dobavitelja. Enako velja za življenjske dobe, raztegnjene daleč prek politike, ki jo pričakuje druga stran.

Namesto tega uskladite predloge. Izberite skupino, ki jo izvajata obe strani, jo vstavite v predlog podrejene asociacije na obeh koncih in politiko obnove držite v obsegu, ki ga organizacija resnično zahteva.

Dokažite to z izmenjavo, ki je spodletela

Skrajšajte čas obnove ključa podrejene asociacije v vzdrževalnem oknu, da dogodek pride v minutah in ne v urah, ali sprožite ročno obnovo. Nato spremljajte uspešno obnovo in potrdite, da promet še naprej teče skozi njo, ker nov rokovanje, ki namesti podrejeno asociacijo, a spusti tok aplikacije je druga napaka.

Nato obnovite običajno življenjsko dobo in ohranite oba zapisa dogodkov, neuspešnega in uspešnega. Dokaz, ki ga želite, je, da povezava preživi svoj življenjski cikel, ne da je preživela ping.