Paano gumagana ang IPsec na nakabatay sa ruta sa isang XFRM interface

Ang IPsec na nakabatay sa ruta ay naghahatid sa routing table ng desisyong dating ginagawa ng mga policy selector. Sa Linux, ang bahaging nagpapangyari nito ay ang XFRM interface: isang virtual na device na ang trapiko ay itinutugma sa IPsec state sa pamamagitan ng interface identifier at hindi ng selector. Ang paggawa ng isa ay nangangailangan ng isang utos at wala itong pinapatunayan tungkol sa pagkakaroon ng tunnel. Ang device ay isang sabitan sa pagitan ng routing at security policy, at ang dalawang gilid ng sabitang iyon ay dapat i-configure bago maprotektahan ang anuman.

Ano ang device at ano ang hindi

Ang XFRM interface ay isang hawakan ng routing. Ang mga packet na iruruta papasok dito ay itinutugma sa mga XFRM policy na tumutukoy sa parehong interface identifier, at kung may policy at state, sila ay ini-encapsulate. Kung wala ang mga iyon, umiiral ang interface, hindi gumagalaw ang mga counter, at ang trapiko ay napupunta sa walang saysay na lugar.

Ito ang unang diagnostic na paghahati. Ang ruta papasok sa device ay isang routing fact, ang naka-install na state ay isang security fact, at ang tumataas na counter sa device ay wala sa dalawa. Kapag sinabi ng mga tao na ang tunnel ay up dahil nagpapakita ng UP ang interface, inilalarawan nila ang mga link flag ng isang virtual na device na walang sariling peer. Ang flag ay nangangahulugan na ang device ay ginawa at pinagana, wala nang iba.

Isa pang hangganan: ang interface identifier ay hindi pangalan. Ang dalawang device na may magkatulad na pangalan at magkaibang identifier ay hindi nagbabahagi ng state, at ang koneksyong na-configure sa maling identifier ay nag-iinstall ng state na hindi gagamitin ng anumang ruta.

Gumawa ng isa sa tamang pagkakasunod-sunod

Magsimula sa panlabas na device at sa isang numerong ilalagay mo rin sa configuration ng daemon. Ginagamit ng halimbawa ang eth0 bilang panlabas na interface at 42 bilang identifier, mga address na dapat mong palitan ng sa iyo.

Itaas ang device, pagkatapos ay kumpirmahin ang identifier na naitala ng kernel bago hawakan ang VPN configuration:

sudo ip link add xfrm0 type xfrm dev eth0 if_id 42
sudo ip link set xfrm0 up
ip -d link show xfrm0 | grep -o 'if_id [0-9]*'

Ngayon i-configure ang koneksyon sa strongSwan gamit ang parehong identifier, dahil kailangang mag-install ang daemon ng mga policy at state na tumutukoy dito. Itakda ang lokal at remote na traffic selector sa saklaw na balak mong iruta, pagkatapos ay iruta ang saklaw na iyon papasok sa device. Ang configuration ng daemon at ang routing table ay dapat magkasundo sa identifier at sa mga destinasyon, at wala sa kanila ang nagbibigay ng isa pa.

Panatilihing labas ang IKE at ESP sa ruta ng tunnel

Ang default na ruta na nakaturo papasok sa XFRM device ay humuhuli sa mga naka-encapsulate na packet at sa trapikong dala nila. Ang resulta ay isang loop: sinusubukan ng gateway na ipadala ang sariling ESP sa tunnel na dapat buuin ng ESP.

Ang solusyon ay isang mas tiyak na ruta para sa panlabas na address ng peer sa pamamagitan ng pisikal na interface, na nananalo sa default dahil tumutugma ito sa mas maraming bit. Ang routing na nakabatay sa marka ay gumagawa ng parehong trabaho kapag maraming tunnel ang nagbabahagi ng isang table, at idinodokumento ng strongSwan ang dalawang paraan para sa mga deployment na nakabatay sa ruta.

Anuman ang piliin mo, tiyakin na ang panlabas na packet ay lumalabas na hindi naka-encapsulate. Ang mabilisang pagsusuri ay ang pag-ping sa panlabas na address ng peer pagkatapos umangat ang tunnel; kung nabigo iyon habang up ang interface, maghinala ng paghuli at hindi ng maabot. Ang parehong pangangatwiran ay naaangkop sa IKE port, dahil ang sariling UDP trapiko ng daemon ay hindi dapat iruta papasok sa device na sinusubukan nitong itatag.

Suriin ang mga counter sa dalawang lugar bago sisihin ang encryption

Ang mga counter ng interface at mga counter ng state ay may sinusukat na magkaibang yugto. Ang mga packet na irinuta papasok sa device ay nagpapataas ng device kahit walang tumutugmang state, samantalang ang mga counter ng state ay gumagalaw lamang para sa trapikong aktwal na na-encapsulate.

Basahin ang pareho, pagkatapos ay basahin ang pananaw ng daemon sa child association:

ip -s link show xfrm0
sudo ip xfrm state list | grep -E 'src|proto|mode'
sudo swanctl --list-sas

Ang pagtaas ng mga counter ng device na may walang laman na state output ay nangangahulugan na gumagana ang routing at hindi tumutugma ang policy, karaniwang pagkakamali sa identifier o selector. Ang pagtaas ng mga counter ng state habang walang iniuulat ang malayong panig ay nangangahulugan na lumalabas ang mga packet pero hindi dumarating o nabigo sa authentication, na tumutukoy sa landas o sa configuration ng peer. Ang nakalistang child association na walang trapiko ay problema sa selector sa isang dulo, hindi sirang cipher.

Magpasya kung sino ang mag-iinstall ng mga ruta

Dalawang may-ari para sa isang routing table ang karaniwang pinagmumulan ng flapping. Kung ang daemon ay awtomatikong nag-iinstall ng mga ruta, ang iyong network manager ay hindi rin dapat mag-install ng default na ruta sa parehong device, at ang manu-manong rutang idinagdag ng startup script ay tatanggalin sa susunod na mag-reconfigure ang daemon.

Pumili ng isang may-ari at isulat ito. Kapag pag-aari ng daemon ang mga ruta, panatilihing labas ang startup script sa table at hayaang ilarawan ng connection definition ang mga traffic selector. Kapag pag-aari ito ng network manager, patayin ang awtomatikong pag-install at tanggapin na hindi aayusin ng daemon ang nawawalang ruta sa muling pagkonekta.

Ang mga patakaran sa pagpapasa at firewall ay hiwalay na desisyon sa ibabaw nito, dahil ang gateway na nagpapalusot ng trapiko ng ibang host ay nangangailangan ng dalawa. Ginagawang madali ng IPsec na nakabatay sa ruta na ipahayag ang trapikong iyon gamit ang ordinaryong kasangkapan sa routing; hindi nito ginagawang opsyonal ang policy layer.