Ang nftables cgroup bypass ay nangangailangan din ng pagwawasto sa source address

Ang pagmamarka ng trapiko mula sa isang cgroup ay ang madaling bahagi. Tatlong hiwalay na desisyon ang dapat magtugma bago lumabas ang isang aplikasyon sa pisikal na interface habang ang lahat ng iba ay nananatili sa tunnel: aling socket ang kabilang sa eksepsyon, aling paghahanap ng ruta ang pinapagana ng marka, at aling source address ang dinadala ng packet kapag lumabas. Karamihan sa mga nabigong pagtatangka ay tama sa una, kalahati sa pangalawa, at hindi kailanman tinitingnan ang pangatlo.

Tatlong desisyon, hindi isa

Sinasagot ng pag-uuri kung sino ang exempted. Sinasagot ng pagruruta kung saan pumupunta ang minarkahang packet sa halip. Sinasagot ng pagpili ng source kung ano ang makikita ng malayong dulo at saan dapat bumalik ang sagot.

Nagkabigo ang mga ito nang hiwalay. Ang isang packet ay maaaring mauri, muling iruta sa pisikal na interface, at nagdadala pa rin ng pribadong address na walang upstream router ang makapagbabalik, na gumagawa ng timeout na mukhang eksaktong pagharang ng firewall. Wala sa hakbang ng pag-uuri ang nagbababala sa iyo tungkol doon. Wala rin sa hakbang ng pagruruta.

Mahalaga rin ang pagkakasunod-sunod. Nagaganap ang pag-uuri kapag nabuo ang packet, pagkatapos ang pagruruta, at ang pagsasalin sa punto ng paglabas.

Kung hindi mo masabi kung alin sa tatlong yugto ang sira, hindi ka nagde-debug, nag-aayos ka ng mga patakaran at umaasa.

Itugma ang cgroup na mananatili bukas

Maaaring subukan ng nftables ang pagiging miyembro sa cgroup v2 ng isang socket, na tunay na kapaki-pakinabang dahil sinusundan nito ang proseso at hindi ang destinasyon. Ang bitag ay ang identifier. Ang desktop application na inilunsad mula sa menu ay madalas na naninirahan sa isang pansamantalang scope na nagbabago ang pangalan sa susunod na paglunsad.

nft list ruleset
systemctl status session.slice 2>/dev/null
cat /proc/self/cgroup

Ang pagkopya ng pangalan ng scope mula sa isang sesyon at pag-hardcode nito ay gumagawa ng patakarang gumagana ngayon at tahimik na humihinto sa pagtutugma bukas. Sa halip, ilagay ang aplikasyon sa sinadyang, matatag na konteksto ng pagpapatupad, tulad ng dedikadong scope o unit na kinokontrol mo, at itugma iyon. Pagkatapos ay nakakaligtas ang patakaran sa mga reboot at update ng package. Nagiging isang bagay din ito na maiisip ng kasamahan nang walang kasaysayan ng iyong sesyon.

Maging tiyak din sa kung aling mekanismo ang ginagamit mo. Ang net_cls na pag-uuri ng cgroup v1 at ang pagtutugma ng socket ng cgroup v2 ay magkaibang bagay, at ang field na may katulad na pangalan sa dokumentasyon ay hindi ginagawang mapagpapalit ang mga ito.

Ang route chain ang nagpapagana ng ikalawang paghahanap

Para sa trapikong nabuo nang lokal, ang uri ng chain ang nagpapasya kung may mangyayari pagkatapos itakda ang marka. Ang output chain na uri ng filter ay maaaring magmarka ng packet at patuloy na gagamitin ng kernel ang rutang napili na nito. Ang chain na uri ng route ang mekanismong humihingi ng bagong paghahanap.

table inet bypass {
  chain mark {
    type route hook output priority mangle; policy accept;
    socket cgroupv2 level 2 "app.slice" meta mark set 0x1 comment "app bypass"
  }
}
ip rule add fwmark 0x1 lookup 200
ip route add default via 203.0.113.1 dev wlan0 table 200

Pagkatapos ay kailangan ng marka ang patakaran na nagpapadala nito sa isang talahanayan, at ang talahanayang iyon ay dapat kumpleto: default na ruta, mga lokal na destinasyon na kailangan pa ng aplikasyon, at upstream gateway na talagang sumasagot.

Piliin ang halaga ng marka nang sinasadya. Gumagamit ang WireGuard ng sarili nitong fwmark para sa panlabas na trapiko ng transportasyon, at ang aksidenteng paglapag sa parehong numero ay maaaring makagambala sa sariling eksepsyon sa ruta ng tunnel sa mga paraang masakit i-diagnose.

Hindi sumusunod ang source address sa ruta

Ang socket na pumili na ng source address para sa landas ng tunnel ay pinapanatili ang address na iyon pagkatapos ng muling pagruruta. Wala sa pagbabago ng ruta ang nagsusulat muli nito, kaya lumalabas ang packet sa pisikal na interface na may pribadong source na hindi maibabalik ng upstream network.

Ang nakikitang sintomas ay isang aplikasyong mukhang nagpapadala ng data at hindi kailanman tumatanggap ng sagot, at isang log ng firewall na walang ipinapakita dahil hindi kailanman bumalik ang packet.

Ang makitid na pagwawasto ay isang patakaran sa pagsasalin ng source na limitado sa marka ng aplikasyong iyon at sa aktwal na output interface nito, na isinama sa NAT na umiiral na sa halip na palitan ito:

table inet bypass {
  chain postrouting {
    type nat hook postrouting priority srcnat; policy accept;
    meta mark 0x1 oifname "wlan0" masquerade
  }
}

Isalin ang eksepsyon at wala nang iba pa. Ang pangkalahatang patakarang masquerade ay nag-aayos ng sintomas at sinisira ang kakayahan mong sabihin kung aling trapiko ang dumaan sa aling landas. Itugma ang marka, ang aktwal na output interface at, kung kaya mo, ang address ng aplikasyon mismo. Ang malalawak na patakaran ay madaling isulat at halos imposibleng i-audit mamaya.

Ano pa ang nakakawala sa eksepsyon

Ang paglutas ng pangalan ay maaaring magmula sa hiwalay na prosesong resolver sa ibang cgroup, kaya ang pag-uuri sa socket ng browser ay hindi nag-uuri sa mga paghahanap nito. Kung ang mga query ng resolver ay nananatili sa tunnel habang lumalabas ang koneksyon sa labas nito, maaaring hindi magtugma ang mga sagot ng split-horizon sa landas. Ang pagkakaibang iyon ay gumagawa ng mga pagkabigo na mukhang bug ng DNS at hindi naman.

Ang mga child process ay nagmamana ng cgroup sa karamihan ng setup, ngunit ang helper na inililipat ang sarili sa sariling scope ay hindi. Suriin sa halip na ipagpalagay, lalo na para sa anumang muling nagpapatupad sa sarili.

Sa huli, magpasya kung ano ang dapat mangyari kapag bumaba ang tunnel. Ang eksepsyon na tahimik na nagiging buong bypass ay ibang postura sa seguridad kaysa sa isang nabibigong sarado, at isa lamang sa kanila ang iyong sinadya.