Bakit ang patakaran sa seguridad ng IPsec ay hindi entry sa talahanayan ng ruta

Mag-ping sa 10.20.0.5 sa tunel at walang bumabalik, habang iginiit ng talahanayan ng ruta na maabot ang subnet na iyon. Magkaibang tanong ang sinasagot ng routing at IPsec, at isa lamang sa kanila ang tungkol sa pag-abot. Pumipili ng landas ang pasulong na paghahanap, pagkatapos ay nagpapasya ang database ng patakaran sa seguridad kung ang landas na iyon ay dapat protektahan, iwanan, o tanggihan. Kapag hindi sila magkasundo, tahimik na namamatay ang packet, kaya basahin sila sa ganoong pagkakasunod-sunod.

Magsimula sa paghahanap, hindi sa talahanayan

Tanungin ang kernel kung ano talaga ang gagawin nito: ipinapakita ng ip route get 10.20.0.5 ang napiling ruta, ang palabas na interface at ang source address na gagamitin. Ang prefix, patakaran sa patakaran, marka o ginustong source ay maaaring magbago ng sagot, kaya mas mabuti ang live na paghahanap kaysa pagbasa ng talahanayan sa pamamagitan ng mata.

Subukan ang destinasyon sa loob ng protektadong saklaw, hindi ang address ng gateway. Ang pag-abot sa gateway sa kabilang panig ay nagpapatunay lamang na may ruta; wala itong sinasabi tungkol sa subnet na talagang kailangan mo. Pagkatapos ay kumpirmahin na ang interface na pinili ng paghahanap ay ang inaasahan mong gagamitin ng tunel.

Itugma ang mga tagapili sa magkabilang panig

Ang database ng patakaran ay may sariling mga entry, at bawat isa ay nagpapangalan ng direksyon, source, destinasyon at protocol, pagkatapos ay nagsasabi kung ano ang dapat mangyari sa mga tumutugmang packet. Gamitin ang ip xfrm policy para ilista sila; ipinapakita ng mga flag kung ang aksyon ay protektahan, laktawan o harangan. Ang patakarang mas malawak o mas makitid ang mga tagapili kaysa sa iyong test flow ay hindi tutugma rito, at lalabas ang packet na walang proteksyon. Iyon ang sira na hinahanap mo, hindi ang kulang na ruta.

Ihambing ang aktwal na mga halaga: source, destinasyon, protocol at mga port. Kung naresolba ng paghahanap ang isang pares ng address habang ang entry ng patakaran ay sumasaklaw sa iba, iba ang trapikong inilalarawan ng dalawang view. Patakbuhin muli ang pareho gamit ang parehong tuple bago magbigay ng konklusyon, kung hindi ay i-edit mo ang patakarang hindi kailanman nasa landas.

Ang pagtutugma ng patakaran ay hindi naka-install na estado

Ang tumutugmang patakaran ay nagsasabi lamang na dapat protektahan ang packet; kailangan pa rin ng kernel ng asosasyon sa seguridad para gawin ang proteksyon. Ilarawan sila gamit ang ip xfrm state, o gamit ang swanctl --list-sas kapag strongSwan ang nagsasagawa ng negosasyon, at basahin ang mga tagapili at counter sa bawat entry.

Kapag tumugma ang patakaran at walang asosasyong sumasaklaw sa parehong mga tagapili, itinatapon ang packet sa halip na ipadala sa malinaw na teksto. Iyon ang pagtatapon na dapat hanapin kapag nakaangat ang tunel ngunit nabigo ang isang subnet. Sinasabi ng mga counter ang iba pa: ang asosasyong hindi kailanman dumarami ay hindi kailanman napili, samantalang ang dumarami at nagtatapos pa rin sa pagtatapon ay tumuturo sa malayong panig. Magkaibang pag-aayos ang pagwawasto ng mga tagapili at pag-renew ng mga key, kaya magpasya kung alin ang kailangan mo bago hawakan ang configuration.

Ano ang kailangan pa ng rutang nakabatay sa ruta

Ginagawang parang device na maruruta ang tunel ng XFRM interface, na talagang kapaki-pakinabang. Hindi nito inaalis ang patakaran at estado na nagpapasya kung ano ang mangyayari kapag nakarating doon ang packet. Ang ruta ay nagbibigay ng susunod na hop at wala nang iba.

Kung umiiral ang device at naka-point ang ruta rito habang walang asosasyong tumutugma sa mga panloob na tagapili, itinatapon ang packet, at walang dami ng pag-edit ng ruta ang gumagawa ng mga key o tagapili. Suriin ang interface gamit ang parehong source at destinasyon na ruta mo, pagkatapos ay ihambing iyon sa listahan ng estado.

Linawin ang pagmamay-ari bago mag-edit ng anuman

Nagdaragdag ang firewall ng host ng ikatlong desisyon na hindi alam ng alinman sa dalawang database. Ang tamang ruta at tumutugmang patakaran at naka-install na asosasyon ay maaari pa ring magtapos sa itinapong packet, at ang timeout lamang ang iniuulat ng application. Kumpirmahin na pinapayagan ng firewall ang protektadong trapiko bago sisihin ang IPsec. Ang pag-capture sa device ng tunel at sa pisikal na interface ay nagpapakita kung saang panig ng encryption nawala ang packet.

Ang pagmamay-ari ng configuration ang nagpapasya kung mabubuhay ang iyong pagwawasto pagkatapos ng restart. Maaaring mag-install ng estado ang isang component habang pinamamahalaan ng iba ang mga ruta, at ang manu-manong edit sa pangalawa ay mapapatungan sa susunod na umangat ang tunel. Baguhin ang pagmamay-aring configuration, pagkatapos ay basahin muli ang dalawang view; pinapanatiling magkahiwalay ng RFC 4301 ang dalawang database kapag kailangan mong ipaliwanag ang paghahati sa ibang tao.