Trap mode ng strongSwan: bakit naghihintay ng trapiko ang IPsec tunnel

Walang CHILD SA na lumilitaw sa output ng status, mukhang patay ang tunnel, at pagkatapos ay pinapataas ito ng ping papunta sa malayong subnet. Sa isang on-demand na IPsec setup, ang pagkakasunod-sunod na iyon ang disenyo, hindi ang sira. Ang trap policy ay nag-i-install ng selector at naghihintay, at ang unang packet na tumutugma rito ang nagpapasimula ng IKE at ng negosasyon ng CHILD SA.

Bahagi ng kalituhan ay bokabularyo: ang “up” ay ginagamit para sa dalawang magkaibang estado. Nakaload ang configuration at umiiral ang kernel policy, ngunit wala ang data association. Ang isang monitor na nagbibilang lamang ng aktibong SA ay mag-uulat ng malusog na site bilang down hangga't walang nagpapadala ng trapiko roon.

Walang CHILD SA na maipapakita ang isang walang galaw na on-demand tunnel

Ang isang trap entry ay walang pinapatunayan nang mag-isa. Hinihiling nito sa kernel na humawak ng policy para sa napiling trapiko at magtaas ng acquisition kapag kailangan ng packet ang policy na iyon. Tinatanggap ng daemon ang acquisition, itinutugma ito sa depinisyon ng child, at nakikipagnegosasyon mula roon. Hanggang sa puntong iyon wala ring IKE SA na maipapakita, kaya maaaring sabay na walang laman ang dalawang listahan.

Ang pagkakasunod-sunod na iyon ang nagpapabasa ng mga log. Una ang acquisition, pagkatapos ang IKE_SA_INIT at IKE_AUTH, pagkatapos ang CHILD SA. Kung nagtatapos ang log agad pagkatapos ng acquisition, gumana ang trigger. Nabigo ang negosasyon, at ang susunod na tanong ay tungkol sa credentials, proposals o maabot, hindi sa trap.

Sa backend ng kernel ng Linux makikita mo ang policy bago pa umiral ang anumang SA. Patakbuhin ang ip xfrm policy at hanapin ang selector na may direksyong out at template na nakaturo sa koneksyon. Ang entry na iyon ang on-demand na estado, at ang presensya nito ang unang dapat kumpirmahin.

Ang start_action ang nagpapasya kung may anumang maghihintay

Bawat child sa swanctl.conf ay may start_action. start na nagsisimula kapag nakaload ang configuration, trap na nag-i-install ng policy at naghihintay, at none na nag-iiwan ng pagsisimula sa iba. Tanging trap lamang ang gumagawa ng pag-uugaling “ping at umaangat” na inilarawan sa itaas.

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

Ang dalawang traffic selector ang tumutukoy kung ano ang itinuturing na kawili-wili, at ang packet mula sa host sa labas ng mga prefix na iyon ay hindi nagpapasiklab ng trap; ito ay niruruta gaya ng dati. Ang pagpapalawak ng mga selector upang maging mas sabik ang trigger ay nagpapalawak din ng saklaw na sinasabing pinoprotektahan ng tunnel, kaya kunin ang mga ito mula sa trapikong talagang nais mong i-encrypt.

Ang sanggunian ng swanctl.conf ay naglilista ng mga tinatanggap na halaga, kasama ang magkahiwalay na close at DPD na aksyon na namamahala sa nangyayari kapag umiiral na ang SA.

Alamin kung nag-trigger ba talaga

Magsimula sa swanctl --list-conns at kumpirmahin na nakaload ang child sa layuning aksyon. Pagkatapos ay magpadala ng isang packet mula sa host sa loob ng local_ts patungo sa address sa loob ng remote_ts at panoorin ang swanctl --list-sas. Kung hindi nagbabago ang output, walang acquisition na nakarating sa daemon.

Dalawang karaniwang dahilan ng tahimik na trap: ang packet ay na-source-NAT bago naabot ang policy at hindi na tumutugma sa local_ts, o hindi kailanman nakaload ang koneksyon dahil sa syntax o credential error. Patakbuhin muli ang swanctl --load-all at basahin ang output bago hawakan ang mga selector. Ang koneksyong hindi nakaload ay walang ini-install na policy, kaya walang mapapasiklab ang trapiko.

Mahalaga rin ang direksyon: ang trap na naka-install para sa papalis na trapiko ay hindi nagsisimula sa papasok na packet. Kung ang malayong panig ang dapat magtaas ng tunnel, kailangan nito ng sariling trap, o kailangan ng panig na ito ng start.

Ang paghihintay sa unang packet ay hindi laging tamang palitan

Nararamdaman ng mga interactive na session ang gastos sa setup. Ang unang kahilingan ay nagbabayad para sa IKE exchange at CHILD negotiation, at ang client na may maikling deadline ay maaaring sumuko bago pa umiral ang SA. Ang proactive na start ay nag-aalis ng pagkaantala sa unang packet. Ngunit pinananatili nitong bukas ang tunnel para sa trapikong maaaring hindi na dumating.

Tatlong katotohanan ang nagpapasya ng pinili: gaano kadalas ginagamit ang landas, kung may mahigpit na deadline ang unang kahilingan, at kung maabot ang peer sa pag-boot. Ang paminsan-minsang batch na trapiko at ang peer na maaaring offline sa pag-boot ay parehong pumapabor sa trap. Ang client na sensitibo sa latency at ang peer na laging maabot ay pumapabor sa start. Kung parehong panig ay makakapagsimula, magkasundo kung kanino ang trigger upang hindi magkaroon ng doble-negosasyon.

Ang naka-install na policy ay hindi rin garantiyang hindi tumatagas. Kung ang kinakailangan ay fail-closed, dapat itapon ng firewall ang trapikong walang SA, at ang panuntunang iyon ay nabubuhay sa labas ng depinisyon ng child.

Isulat ang tatlong linyang magtatapos sa susunod na debate

Isulat ang mga selector, ang aksyon sa pagsisimula, at ang output ng command na nagpapakitang naroon ang policy nang walang SA. Ang tatlong linyang iyon ay naghihiwalay ng “on demand at walang galaw” sa “hindi naglo-load” sa susunod na may mag-ulat na down ang tunnel. Isang minuto ang pagkuha sa mga ito. Kung wala ang mga ito, magsisimula muli ang parehong imbestigasyon sa sero.

Subukan mula sa host na talagang nasa loob ng selector. Ang ping mula sa router mismo ay madalas na dumadaan sa ibang landas at walang pinapatunayan tungkol sa policy na nagpoprotekta sa subnet sa likod nito.