Зошто вашиот IPsec тунел работи до првото обновување на клучот CHILD SA
Тунел што пренесува сообраќај ги докажа IKE поставките, а не размената на клучеви што се користи при обновувањето. Погледнете каде се крие несовпаѓањето на PFS и како да го извлечете.
Тунелот се крена, ping одговори и сите потпишаа. Четири часа подоцна сесијата паѓа, страните забележуваат грешка во предлогот или во размената на клучеви, и првата претпоставка е дека нешто се сменило на мрежата. Ништо не се смени. Тунелот што пренесува сообраќај докажа дека двете страни се согласни како да се автентицираат и како да се заштити првата подредена асоцијација, и не докажа ништо за размената на клучеви што ќе ја бараат при обновувањето. Несовпаѓањето лежи во празнината меѓу тие два настана.
Поврзаноста не значи дека PFS поставките се совпаѓаат
Со IKEv2, првата подредена асоцијација се создава за време на размената за автентикација, а нејзините клучеви се изведуваат од материјалот што IKE асоцијацијата веќе го произвела. За таа подредена асоцијација не се случува посебна Diffie-Hellman размена, така што политиката што бара таква при обновувањето не се проверува при кревањето.
Обновувањето е друга размена. Кога клучот на подредена асоцијација се обновува, страните можат да извршат нова размена на клучеви со групата наведена во нивните предлози, и тоа е првиот момент кога поставките на групата се споредуваат. Затоа две страни што не се согласуваат можат да се автентицираат, да инсталираат подредена асоцијација и да пропуштат сообраќај, а потоа да не успеат при обновувањето.
Каде се крие несовпаѓањето во низата на предлогот
Во strongSwan групата се додава на подредениот предлог, затоа низа како aes256gcm16-prfsha256-ecp256 изгледа како избор на шифрирање, но носи и барање за размена на клучеви. Страна што нуди само aes256gcm16-prfsha256 нема такво барање, и двете листи се сечат во шифрирањето, но се разидуваат во размената.
Читајте го подредениот предлог и IKE предлогот како одделни листи. Група што се појавува во IKE листата не кажува ништо за подредената листа, а уредувањето на едната додека ја читате другата е вообичаениот начин ова да се пропушти.
Читајте го неуспехот, не датотеката што ја уредувавте
Најдете го notify што ја заврши размената. Обновување на клуч на подредена асоцијација што враќа „нема прифатлив предлог“ покажува на листите со предлози; барање за обновување што никогаш не добива одговор покажува на патеката или на страна што престана да слуша. Овие две бараат различни поправки, и формулацијата на редот во дневникот ги разделува.
Потврдете ја конфигурацијата што работи, а не таа на дискот. Датотека што е зачувана но не е вчитана, или врска што е повторно прочитана од друг include, ќе создадат несовпаѓање што некое уредување на видливата датотека не може да го поправи.
Три настани што сите се нарекуваат обновување на клуч
Обновувањето на клучот на IKE асоцијацијата, повторната автентикација на IKE и обновувањето на клучот на подредената асоцијација се одделни операции со одделни правила за предлози. Неуспех пријавен кај една од нив не кажува ништо директно за другите, а дневник што ги меша се чита како еден дефект што се повторува, иако се три.
Забележете кој настан го именува страната, потоа проверете ги предлозите само за тој настан. Сменете една листа, вчитајте повторно и повторно присилете го истиот настан. Ако дневникот именува повторна автентикација, IKE предлогот е тој што треба да се чита. Ако именува обновување на клуч на подредена асоцијација, важната група ја носи подредениот предлог.
Исклучувањето на обновувањето не е поправка
Поставувањето на времето за обновување на клучот на нула ја потиснува размената што не успева, и тунелот потоа преживува додека не се расклопи или страната не се рестартира. Она што го купивте е клуч со подолг живот и несовпаѓање што повторно ќе ве пречека при миграција, ревизија или ажурирање од добавувачот. Истото важи и за роковите истегнати далеку над политиката што ја очекува другата страна.
Наместо тоа, усогласете ги предлозите. Изберете група што ја применуваат двете страни, ставете ја во подредениот предлог на двата краја и држете ја политиката за обновување во опсегот што организацијата навистина го бара.
Докажете го со размената што не успеа
Скратете го времето за обновување на клучот на подредената асоцијација во прозорец за одржување за настанот да дојде за минути, а не за часови, или активирајте рачно обновување. Потоа гледајте успешно обновување и потврдете дека сообраќајот продолжува низ него, бидејќи ново ракување што инсталира подредена асоцијација, но го испушта текот на апликацијата е друг дефект.
Потоа вратете го нормалниот рок и зачувајте ги двата записа од настанот, неуспешниот и успешниот. Доказот што го сакате е дека врската го преживува сопствениот животен циклус, а не дека преживеа ping.