Можда мислите да је IKEv2 веза једна размена која се завршава шифрираним саобраћајем. Њих је најмање две, а прва никога не аутентификује. Стране почињу контролним порукама, договарају криптографске параметре, доказују идентитет и тек онда преговарају о стању које преноси пакете апликације. Тај редослед објашњава неусклађеност о којој људи стално извештавају: пролаз одговара, клијент каже повезан, а приватна апликација и даље прелази време чекања. Ево шта свака фаза заиста ради и шта мора бити тачно после ње.

Мит: ако пролаз одговори, повезани сте

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

Ти неуспеси се дешавају касније и дају различите симптоме. Одбијање сертификата или EAP грешка долази након што је прва размена већ успела, зато ping ка UDP 500 и зелена икона клијента говоре тако мало.

IKE_SA_INIT: договорите параметре, не идентитет

Прва размена носи предлоге за IKE безбедносну асоцијацију: алгоритме шифровања и интегритета, псеудослучајну функцију и Diffie-Hellman групу. Стране размењују и nonce вредности, а свака страна изводи кључни материјал за IKE SA из заједничке тајне коју те вредности стварају. Ништа у овој размени не утврђује која је друга страна. Утврђује само да обе стране могу израчунати исте кључеве и да се слажу око предлога. Одговорник коме се ниједан предлог не свиђа одбија размену овде, зато неусклађеност верзије или алгоритма изгледа као да је сервер пао.

IKE SA створен у овом тренутку штити све касније контролне размене. То је његов посао и то је други посао од заштите ваших пакета.

IKE_AUTH: докажите идентитет, па изградите први CHILD SA

Друга размена носи идентитет. Са сертификатима свака страна потписује својим приватним кључем и представља ланац који друга мора да валидира; са EAP, одговорник изазива иницијатора изабраним методом. Овде се коначно појављују погрешно име сервера, истекао сертификат или одбијена лозинка.

Обично IKE_AUTH преговара и о првом CHILD SA, па се заштита података договара у истом кругу. Иницијатор предлаже селекторе саобраћаја, одговорник их сужава или одбија, а кључеви пута података изводе се из IKE SA. То значи да једна размена може да не успе на два врло различита места: у идентитету или у политици. Читајте обавештење или грешку, а не општи неуспех руковања, јер се једно лечи сертификатом, а друго неусклађеношћу подмреже.

Две SA, два посла

АсоцијацијаШтитиПонашање трајања
IKE SAКонтролне размене: обнављање кључева, брисање, конфигурациона оптерећењаОбнавља се по сопственом распореду; пут података може преживети промену
CHILD SAСаобраћај апликације који одговара селекторима саобраћајаОбнавља се независно, често чешће

Њихово раздвајање објашњава два понашања која личе на грешке. Тунел може изгледати успостављен док обнављање кључева не успева у позадини, а CHILD SA може бити замењен без губитка везе код клијента.

На strongSwan-у референца конфигурације IKEv2 и swanctl --list-sas приказују оба нивоа, а ip xfrm state заједно са ip xfrm policy приказују шта је језгро заиста инсталирало. Поређење та два приказа најбржи је начин да се види да ли је преговор завршен или је само изгледао завршен. Ако демон наведе CHILD SA за коју језгро нема стање, инсталација је тихо пропала. Ако језгро држи стање које демон не зна, гледате остатак ранијег покушаја.

Шта још мора бити тачно после подизања тунела

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

Држите дневник видљивим док дијагностикујете: почетна размена, затим валидација идентитета, затим аутентикација корисника где се примењује, затим инсталација CHILD и на крају саобраћај апликације. Фаза која се зауставља је фаза коју треба поправити, а каснији неуспех рутирања никада није разлог да се попусте провере идентитета које су већ прошле.

Повезани чланци