IKEv2 не е едно ракување: IKE SA, автентикација, потоа CHILD SA
Одговорот на портата докажува достапност, не идентитет. Следете IKE_SA_INIT, IKE_AUTH и првиот CHILD SA, потоа проверете што мора да биде точно пред да потече сообраќајот.
Можеби мислите дека 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 и на крајот апликацискиот сообраќај. Фазата што запира е фазата што треба да се поправи, а подоцнежниот неуспех во рутирањето никогаш не е причина да се олабават проверките на идентитетот што веќе поминале.