strongSwan trap режим: зошто IPsec тунелот чека сообраќај

Неактивен IPsec тунел по барање не прикажува CHILD SA додека пакетот не се совпадне со неговата trap политика. Прочитајте ја состојбата, проверете го тригерот и знајте кога start е соодветен.

Во статусниот излез не се појавува CHILD SA, тунелот изгледа мртов, а потоа ping кон далечната подмрежа го крева. Во поставеност на IPsec по барање оваа низа е дизајнот, не дефект. Trap политиката инсталира селектор и чека, и првиот пакет што се совпаѓа со неа ги започнува IKE и преговорите за CHILD SA.

Дел од конфузијата е вокабулар: „up“ се користи за две различни состојби. Конфигурацијата е вчитана и кернел политиката постои, но асоцијацијата на податоци не. Монитор што брои само активни SA ќе пријави здрав сајт како исклучен сѐ додека никој не испраќа сообраќај кон него.

Неактивен тунел по барање нема CHILD SA за прикажување

Trap записот сам по себе не автентицира ништо. Тој бара од кернелот да држи политика за избраниот сообраќај и да крене acquisition кога на пакетот му треба таа политика. Демонот го прима acquisition, го совпаѓа со дефиницијата child и преговара оттаму. До тој момент нема ни IKE SA за прикажување, затоа двете листи можат да бидат празни истовремено.

Токму овој редослед ги прави логовите читливи. Прво доаѓа acquisition, потоа IKE_SA_INIT и IKE_AUTH, потоа CHILD SA. Ако логот заврши веднаш по acquisition, тригерот работел. Преговорите не успеале, а следното прашање е за акредитиви, предлози или достапност, не за trap.

Со Linux кернел 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 од самиот рутер често оди по друг пат и не докажува ништо за политиката што ја штити подмрежата зад него.

Поврзани статии