Зашто ваш IPsec тунел ради до првог обнављања кључа CHILD SA

Тунел се подигао, ping је одговорио и сви су потписали. Четири сата касније сесија падне, стране забележе грешку у предлогу или размени кључева, а прва претпоставка је да се нешто променило на мрежи. Ништа се није променило. Тунел који преноси саобраћај доказао је да се две стране слажу како да се аутентификују и како да заштите прву подређену асоцијацију, а није доказао ништа о размени кључева коју ће захтевати при обнављању. Неслагање лежи у празнини између та два догађаја.

Повезаност не значи да се PFS подешавања слажу

Уз IKEv2, прва подређена асоцијација настаје током размене аутентификације, а њени кључеви се изводе из материјала који је IKE асоцијација већ произвела. За ту подређену асоцијацију се не одвија засебна Diffie-Hellman размена, па се политика која је захтева при обнављању не проверава при подизању.

Обнављање је друга размена. Када се кључ подређене асоцијације обнови, стране могу извести нову размену кључева са групом наведеном у њиховим предлозима, и то је први тренутак када се подешавања групе пореде. Зато две стране које се не слажу могу да се аутентификују, инсталирају подређену асоцијацију и пропусте саобраћај, а затим не успеју при обнављању.

Где се неслагање крије у низу предлога

У strongSwan-у се група додаје на предлог подређене асоцијације, због чега низ попут aes256gcm16-prfsha256-ecp256 изгледа као избор шифровања, али носи и захтев за размену кључева. Страна која нуди само aes256gcm16-prfsha256 нема такав захтев, а две листе се секу у шифровању док се разилазе у размени.

Читајте предлог подређене асоцијације и IKE предлог као одвојене листе. Група која се појављује у IKE листи не говори ништа о листи подређене асоцијације, а уређивање једне док читате другу уобичајен је начин да се то пропусти.

Читајте неуспех, а не датотеку коју сте уредили

Пронађите notify који је окончао размену. Обнављање кључа подређене асоцијације које враћа „нема прихватљивог предлога“ указује на листе предлога; захтев за обнављање који никада не добије одговор указује на путању или на страну која је престала да слуша. Та два случаја траже различите поправке, а формулација линије у дневнику их раздваја.

Потврдите радну конфигурацију, а не ону на диску. Датотека сачувана али не учитана, или веза поново прочитана из другог include-а, произвешће неслагање које никакво уређивање видљиве датотеке не може исправити.

Три догађаја која сви називају обнављањем кључа

Обнављање кључа IKE асоцијације, поновна аутентификација IKE и обнављање кључа подређене асоцијације одвојене су операције са одвојеним правилима предлога. Неуспех пријављен на једној од њих не говори ништа директно о осталима, а дневник који их меша чита се као један понављајући квар док су три.

Забележите који догађај страна наводи, па проверите предлоге само за тај догађај. Промените једну листу, поново учитајте и поново изазовите исти догађај. Ако дневник наводи поновну аутентификацију, IKE предлог је онај који треба читати. Ако наводи обнављање кључа подређене асоцијације, предлог подређене асоцијације носи групу која је битна.

Искључивање обнављања није поправка

Постављање времена обнављања кључа на нулу потискује размену која не успева, а тунел затим преживи док се не размонтира или страна не рестартује. Оно што сте купили јесте кључ који дуже траје и неслагање које ће вас поново срести током миграције, ревизије или ажурирања добављача. Исто важи и за животне векове развучене далеко изнад политике коју друга страна очекује.

Уместо тога ускладите предлоге. Одаберите групу коју обе стране имплементирају, ставите је у предлог подређене асоцијације на оба краја и држите политику обнављања унутар распона који организација заиста захтева.

Докажите то разменом која није успела

Скратите време обнављања кључа подређене асоцијације у прозору за одржавање да догађај стигне за неколико минута, а не сати, или покрените ручно обнављање. Затим пазите на успешно обнављање и потврдите да саобраћај пролази кроз њега, јер ново руковање које инсталира подређену асоцијацију али испусти ток апликације је друга грешка.

После вратите нормални животни век и сачувајте оба записа о догађајима, неуспели и успешни. Доказ који желите јесте да веза преживи сопствени животни циклус, а не да је преживела ping.