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. Това означава, че един обмен може да се провали на две много различни места: самоличност или политика. Четете payload на notify или грешката вместо общия отказ на ръкостискането, защото поправката за едното е сертификат, а за другото — несъответствие в подмрежата.
Две SA, две задачи
| Association | Protects | Lifetime behaviour |
|---|---|---|
| IKE SA | Management exchanges: rekeying, delete, configuration payloads | Rekeyed on its own schedule; the data path can survive the change |
| CHILD SA | Application traffic matching the traffic selectors | Rekeyed independently, often more frequently |
Разделянето им обяснява две поведения, които изглеждат като дефекти. Тунелът може да изглежда установен, докато във фонов режим се проваля подмяна на ключове, а CHILD SA може да бъде заменена, без клиентът да загуби връзката.
В strongSwan справката за конфигурация на IKEv2 и swanctl --list-sas показват двете нива, а ip xfrm state плюс ip xfrm policy показват какво всъщност е инсталирало ядрото. Сравняването на тези два изгледа е най-бързият начин да видите дали договарянето е завършило, или само е изглеждало завършено. Ако демонът изброява CHILD SA, за която ядрото няма състояние, инсталирането е тихо провалено. Ако ядрото държи състояние, за което демонът не знае, виждате остатък от предишен опит.
Какво още трябва да е вярно след вдигане на тунела
Селекторите на трафик определят кои адреси са обхванати. Ако клиентът предложи една подмрежа, а сървърът очаква друга, CHILD SA се инсталира, но не носи нищо полезно, и грешката изглежда като проблем с маршрутизацията, а не с договарянето. После локалният стек трябва да съдейства: включено препращане там, където хостът маршрутизира, маршрути към тунела, правила на защитната стена, позволяващи декапсулираните пакети, и вътрешен резолвер, ако участват частни имена. Всяко от тях се проваля отделно и никое не се поправя с рестартиране на демона IKE.
Дръжте журнала видим, докато диагностицирате: първоначалният обмен, после проверката на самоличността, после удостоверяването на потребителя, където е приложимо, после инсталирането на CHILD, после трафикът на приложенията. Етапът, който спира, е етапът за поправка и по-късен проблем с маршрутизацията никога не е причина да се разхлабят проверките на самоличността, които вече са минали.