Режим trap в strongSwan: защо IPsec тунелът чака трафик

Бездействащ IPsec тунел при поискване не показва CHILD SA, докато пакет не съвпадне с неговата trap политика. Прочетете състоянието, проверете тригера и знайте кога start е подходящ.

В изхода на статуса не се появява CHILD SA, тунелът изглежда мъртъв, а след това ping към далечната подмрежа го вдига. В настройка на IPsec при поискване тази последователност е замисълът, а не дефект. Trap политиката инсталира селектор и чака, а първият пакет, който ѝ съвпадне, е това, което стартира IKE и преговорите за CHILD SA.

Част от объркването е в речника: „up“ се използва за две различни състояния. Конфигурацията е заредена и kernel политиката съществува, а асоциацията за данни — не. Монитор, който брои само активни SA, ще отчита здрав сайт като недостъпен, докато никой не изпраща трафик към него.

Бездействащ тунел при поискване няма CHILD SA за показване

Trap записът сам по себе си не удостоверява нищо. Той иска от ядрото да държи политика за избрания трафик и да вдигне acquisition, когато пакет се нуждае от тази политика. Демонът получава acquisition, съпоставя го с дефиницията на child и преговаря оттам. До този момент няма и IKE SA за показване, затова и двата списъка могат да са празни едновременно.

Именно този ред прави логовете четими. Първо идва acquisition, после IKE_SA_INIT и IKE_AUTH, после CHILD SA. Ако логът свършва веднага след acquisition, тригерът е проработил. Преговорите са се провалили и следващият въпрос е за идентификационни данни, предложения или достижимост, а не за trap.

С Linux kernel backend можете да видите политиката преди да съществува какъвто и да е SA. Изпълнете ip xfrm policy и потърсете селектора с посока out и шаблон, сочещ към връзката. Този запис е състоянието при поискване и наличието му е първото нещо за потвърждаване.

start_action решава дали нещо изобщо ще чака

Всяко child в swanctl.conf носи start_action. start стартира при зареждане на конфигурацията, trap инсталира политиката и чака, а none оставя стартирането на нещо друго. Само trap създава поведението „ping и се вдига“, описано по-горе.

children {
    office-lan {
        local_ts = 192.168.50.0/24
        remote_ts = 192.168.70.0/24
        start_action = trap
    }
}

Двата селектора за трафик определят какво се брои за интересно, а пакет от хост извън тези префикси не задейства trap; той се маршрутизира както обикновено. Разширяването на селекторите, за да стане тригерът по-нетърпелив, разширява и обхвата, който тунелът твърди, че защитава, затова ги извеждайте от трафика, който наистина възнамерявате да шифровате.

Справочникът swanctl.conf изброява приетите стойности, заедно с отделните действия close и DPD, които управляват какво се случва, след като SA съществува.

Разберете дали тригерът е проработил изобщо

Започнете с swanctl --list-conns и потвърдете, че child е зареден с действието, което сте имали предвид. След това изпратете един пакет от хост в local_ts към адрес в remote_ts и наблюдавайте swanctl --list-sas. Ако изходът не се промени, никакъв acquisition не е стигнал до демона.

Две обикновени причини за тих trap: пакетът е бил source-NAT-нат, преди да стигне до политиката, и вече не съвпада с local_ts, или връзката никога не се е заредила заради синтактична грешка или грешка в идентификационните данни. Изпълнете отново swanctl --load-all и прочетете изхода му, преди да пипате селектори. Връзка, която не се е заредила, не инсталира политика, така че няма какво трафикът да задейства.

Посоката също има значение: trap, инсталиран за изходящ трафик, не стартира при входящ пакет. Ако отдалечената страна трябва да вдигне тунела, тя се нуждае от собствен trap, или тази страна се нуждае от start.

Чакането на първия пакет не винаги е правилната размяна

Интерактивните сесии усещат цената на настройката. Първата заявка плаща за IKE обмена и CHILD преговорите, а клиент с кратък краен срок може да се откаже, преди SA да съществува. Проактивният start премахва това закъснение за първия пакет. Но държи тунел вдигнат за трафик, който може никога да не дойде.

Три факта решават избора: колко често се използва пътят, дали първата заявка има тесен краен срок и дали партньорът е достижим при зареждане. Случайният пакетен трафик и партньор, който може да е офлайн при стартиране, и двете благоприятстват trap. Клиент, чувствителен на латентност, и партньор, който винаги е достижим, благоприятстват start. Ако и двете страни могат да инициират, се разберете коя притежава тригера, за да няма дублирани преговори.

Инсталираната политика също не е гаранция срещу изтичане. Ако изискването е fail-closed, защитната стена трябва да отхвърля трафик без SA и това правило живее извън дефиницията на child.

Запишете трите реда, които слагат край на следващия спор

Запишете селекторите, действието при стартиране и изхода от командата, който показва политиката налична без SA. Тези три реда разделят „при поискване и бездействащ“ от „не се зарежда“ следващия път, когато някой докладва тунела като недостъпен. Отнема минута да ги уловите. Без тях същото разследване започва от нула.

Тествайте от хост, който наистина е в селектора. Ping от самия рутер често следва различен път и не доказва нищо за политиката, защитаваща подмрежата зад него.

Подобни статии