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

Три чињенице одлучују избор: колико се често путања користи, има ли први захтев тесан рок и да ли је peer доступан при подизању. Повремени батч саобраћај и peer који може бити офлајн при подизању обоје фаворизују trap. Клијент осетљив на латенцију и peer који је увек доступан фаворизују start. Ако обе стране могу да иницирају, договорите се ко поседује окидач да не добијете дупле преговоре.

Инсталирана политика такође није гаранција против цурења. Ако је захтев fail-closed, заштитни зид мора да одбаци саобраћај без SA, а то правило живи изван дефиниције child.

Запишите три реда који завршавају следећу расправу

Запишите селекторе, радњу при покретању и излаз команде који показује да политика постоји без SA. Та три реда раздвајају „на захтев и неактиван“ од „не учитава се“ следећи пут када неко пријави тунел као неисправан. Потребна је минута да их забележите. Без њих иста истрага почиње од нуле.

Тестирајте са хоста који је заиста унутар селектора. Ping са самог рутера често иде другим путем и не доказује ништа о политици која штити подмрежу иза њега.

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