Walang tun0? Itugma ang na-decrypt na IPsec sa nftables gamit ang meta ipsec

Inaasahan mo ang isang tunnel interface, hinahanap mo ito, at wala kang maitutugma sa firewall. Normal ito para sa gateway na nakabatay sa patakaran: dumarating ang naka-encrypt na palitan sa pisikal na interface, at ang na-decrypt na panloob na packet na ipinapasa pagkatapos ay nakikita rin na dumarating sa parehong interface. Walang tun0 dahil walang gumawa nito.

Ang panloob na kahilingan ay nananatiling hiwalay na packet na may sariling pinagmulan, destinasyon at serbisyo, at alam ng kernel kung saang asosasyon ng seguridad ito lumabas. Ang kaalamang iyon ang maitutugma ng isang patakaran ng firewall.

Dalawang packet, isang interface

Isipin ang papasok na direksyon. Dumarating ang packet na naka-encapsulate sa ESP o UDP, hinahanap ng kernel ang tugmang patakaran, dine-decrypt ito at ibinibigay ang malinaw na packet sa landas ng pagpapasa. Ang patakarang tumitingin lamang sa pangalan ng interface ay hindi makikilala ang packet na iyon mula sa anumang iba pang trapik na dumarating sa parehong kawad.

Ang nagpapakilala dito ay ang konteksto ng papasok na landas ng seguridad na nakakabit sa packet. Inilalantad ito ng nftables bilang meta ipsec exists, na totoo kapag ang packet ay dumating sa pamamagitan ng landas ng seguridad ng IPsec. Pagsamahin ito sa pool ng kliyente, destinasyon at serbisyo, at ang patakaran ay magiging sapat na tiyak upang maging ligtas.

Ang pag-alis ng konteksto ang karaniwang pagkakamali, at ito ay pagkakamali sa seguridad hindi sa anyo. Ang patakarang tumatanggap ng lahat ng nagmumula sa pool ng kliyente ay tumatanggap din nang kasing-gaan ng isang pekeng packet mula sa lokal na network, dahil ang pinagmulang address ay hindi patunay ng anuman sa sarili nito. Ang konteksto ng landas ng seguridad ang pinakamurang paraan upang gawing makabuluhan ang pinagmulan. Isulat ang patakaran kasama nito mula sa simula sa halip na idagdag ito pagkatapos ng audit.

Isulat ang patakaran sa pagpapasa

Ipagpalagay na may authenticated na IPv4 remote access service na may mga kliyente sa 10.90.0.0/24 at isang aprubadong destinasyon sa 203.0.113.40. Ang tipak ng patakaran para sa daloy na iyon ay ganito ang hitsura.

meta ipsec exists ip saddr 10.90.0.0/24 \
  ip daddr 203.0.113.40 tcp dport 443 \
  oifname "eth0" counter accept

Ang mga address at interface ay mga halimbawang papalitan. Ilagay ang nasuri na katumbas sa patakaran ng pagpapasa bago ang patakarang tatanggihan sana ang daloy, at huwag burahin ang umiiral na set ng patakaran upang i-install ito; ang gateway ay hindi eksperimento sa malinis na silid.

Sulit panatilihin ang terminong oifname. Idinodokumento nito ang desisyon sa paglabas at pinipigilan ang patakaran na tumugma sa direksyong hindi mo sinadya, na mahalaga sa gateway na may ilang landas patungo sa internet. Sa test box na may isang uplink, ang termino ay mukhang kalabisan, at iyon mismo ang dahilan kung bakit ito tinanggal bago magkaroon ng pangalawang uplink ang box.

Ang mga pahintulot para sa panlabas na palitan ay hiwalay. Ang papasok na landas ng gateway ay nangangailangan ng mga port ng IKE at ESP o UDP encapsulation na aktwal nitong ginagamit, at ang mga pahintulot na iyon ay walang pinapayagan tungkol sa na-decrypt na packet sa loob. Ang paghahalo ng dalawa ang paraan kung paanong ang gumaganang tunnel ay nauuwi sa firewall na nagpapasa ng lahat.

Ang konteksto ng papasok ay hindi konteksto ng palabas

Ang parehong pamilya ng mga ekspresyon ay sumasaklaw sa kabilang direksyon gamit ang rt ipsec, na naglalarawan ng palabas na asosasyon ng seguridad na gagamitin ng isang packet. Sinasagot nito ang ibang tanong: hindi kung saan nanggaling ang packet na ito, kundi kung mapoprotektahan ito sa susunod na bahagi.

Mahalaga ang pagkakaibang iyon sa gateway na nagtatapos ng isang tunnel at nagpapasa sa isa pa nang sabay. Maaaring dumating ang packet na na-decrypt at kailangan pa ring lumabas na naka-encrypt, at ang pagtanggap na isinulat lamang para sa papasok na konteksto ay walang sinasabi tungkol sa pangangailangan sa palabas. Kung hinihiling ng patakaran ang proteksyong iyon, dapat itong ipahayag ng set ng patakaran sa halip na ipagpalagay na ang routing ang bahala.

Panatilihin ang dalawang tanong sa magkahiwalay na patakaran upang makita ng mambabasa kung alin ang ipinapatupad. Ang isang matalinong patakaran na sumusuri sa dalawa ay mas mahirap suriin at mas mahirap i-debug kapag ang isang kalahati nito ay huminto sa pagtugma. Ang dalawang patakarang may counter ay nagsasabi rin kung aling pangangailangan ang nabigo, na hindi kailanman gagawin ng isang pinagsamang patakaran.

Ang NAT ay hindi desisyon ng firewall

Ang trapik patungo sa internet mula sa pribadong pool ng kliyente ay karaniwang nangangailangan ng pagsasalin ng pinagmulan upang mahanap ng sagot ang daan pabalik. Ngunit ang trapik na pinili para sa isa pang palabas na patakaran ng IPsec ay dapat panatilihin ang kinakailangang pagbubukod, at ang pagtatakip sa bawat pribadong pinagmulan nang hindi iniisip ang susunod na desisyon sa proteksyon ay sumisira niyon.

Ang pagtanggap sa loob ng isang chain ng NAT ay hindi rin pangkalahatang pahintulot. Magkaiba ang trabaho ng NAT at ng pagsasala, at hindi sinusuri ng chain ng NAT ang bawat kasunod na packet ng naitatag na daloy, at iyon mismo ang dahilan kung bakit ang pag-asa rito para sa seguridad ay gumagawa ng mga patakarang mukhang gumagana sa test at nabigo sa ilalim ng karga.

Totoo rin ang kabaligtaran at nagpagulat sa mga tao: ang pagtanggap sa isang lugar sa isang base chain ng pagsasala ay walang timbang laban sa kasunod na pagtanggi sa isa pang naaangkop na chain. Ang pagkakasuno-sunod at saklaw ng chain ang nagpapasya sa resulta, hindi ang pagkakaroon ng pagtanggap sa file.

I-verify ang eksaktong panloob na serbisyo

Subukan ang tiyak na destinasyon at port na inaprubahan mo, mula sa tunay na kliyente, at tiyakin na bumabalik ang sagot. Pagkatapos subukan ang isang bagay na hindi mo inaprubahan at tiyakin na hindi ito dumadaan, dahil ang masyadong malawak na patakaran ay pumapasa sa unang test kasing husay ng tamang patakaran. Ang kahilingang hindi kailanman lumalabas sa kliyente ay hindi rin resulta ng firewall, kaya basahin ang mga counter upang makita kung sinuri man ang packet. Dalawang test at isang pagbasa ng counter ang magsasabi sa iyo ng higit pa kaysa sa isang buong hapon ng pagbabasa ng set ng patakaran.

Ang sanggunian ng nftables ay nagdodokumento ng meta ipsec, rt ipsec at ng mga ekspresyong partikular sa direksyon, at doon ang lugar upang suriin ang sintaks laban sa naka-install na bersyon. At panatilihing malinaw ang saklaw: ito ay halimbawa ng IPv4, wala itong sinasabi tungkol sa IPv6, at hindi nito ginagawang bahagi ng serbisyo ng VPN ang di-makatwirang pagpapasa ng pampublikong port.