nftables-en cgroup saihesbideak jatorrizko helbidearen zuzenketa ere behar du

cgroup bat markatzeak beste taula batera bidaltzen du, eta socket-ak lehendik zuen helbidea gordetzen du. Sailkatu, bideratu eta itzuli hiru urrats bereizi gisa.

cgroup batetik datorren trafikoa markatzea da zati erraza. Hiru erabaki berezik bat etorri behar dute aplikazio bakar bat interfaze fisikotik irten aurretik, gainerako guztia tunelean geratzen den bitartean: zein socket dagokion salbuespenari, zein bideratze-bilaketak abiarazten duen marka eta zein jatorrizko helbide daraman paketeak irtetean. Saiakera huts gehienek lehenengoa asmatzen dute, bigarrena erdizka, eta ez diote inoiz hirugarrenari begiratzen.

Hiru erabaki, ez bat

Sailkapenak erantzuten du nor dagoen salbuetsita. Bideratzeak erantzuten du nora doan markatutako paketea horren ordez. Jatorriaren hautaketak erantzuten du zer ikusiko duen urrutiko aldeak eta nora itzuli behar duen erantzunak.

Hauek modu independentean huts egiten dute. Pakete bat sailka daiteke, interfaze fisikora berbidera daiteke eta oraindik goiko router batek itzuli ezin duen helbide pribatu bat eraman dezake, eta horrek suebaki-blokeo baten itxura zehatza duen denbora-muga sortzen du. Sailkapen-urratsean ezerk ez dizu horren berri ematen. Bideratze-urratsean ere ez.

Ordenak ere badu garrantzia. Sailkapena paketea sortzen denean gertatzen da, bideratzea geroago, eta itzultzea irteera-puntuan.

Hiru etapetatik zein dagoen hautsita ezin baduzu izendatu, ez zaude arazorik konpontzen, arauak berrantolatzen eta itxaroten ari zara.

Egin bat bihar ere existituko den cgroup batekin

nftables-ek socket baten cgroup v2 kidetasuna egiaztatu dezake, eta hori benetan erabilgarria da prozesuari jarraitzen diolako, ez helmugari. Tranpa identifikatzailea da. Menutik abiarazitako mahaigaineko aplikazioa sarritan iragaitzazko scope batean bizi da, eta haren izena hurrengo abiaraztean aldatzen da.

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

Scope baten izena saio batetik kopiatu eta gogor kodetzeak gaur funtzionatzen duen eta bihar isilka bat etortzeari uzten dion araua sortzen du. Jarri aplikazioa, horren ordez, nahita egonkorra den exekuzio-testuinguru batean, adibidez kontrolatzen duzun scope edo unit dedikatu batean, eta egin bat harekin. Orduan arauak berrabiarazteei eta pakete-eguneratzei eusten die. Gainera, zure saio-historiarik gabe lankide batek arrazoitu dezakeen zerbait bihurtzen da.

Izan zaitez zehatza zein mekanismo erabiltzen ari zaren. cgroup v1-eko net_cls sailkapena eta cgroup v2-ko socket bat etortzea gauza desberdinak dira, eta dokumentazioan izen antzekoa duen eremu batek ez ditu trukagarri egiten.

route motako kate bat da bigarren bilaketa abiarazten duena

Tokian sortutako trafikoarentzat, kate motak erabakitzen du marka ezarri ondoren zerbait gertatuko den. filter motako irteera-kate batek pakete bat marka dezake eta kernelak jada aukeratu zuen bidea erabiltzen jarraituko du. route motako katea bilaketa berri bat eskatzen duen mekanismoa da.

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

Orduan markak taula batera bidaltzen duen politika-arau bat behar du, eta taula horrek osoa izan behar du: bide lehenetsi bat, aplikazioak oraindik behar dituen tokiko helmuga guztiak eta benetan erantzuten duen goiko atebide bat.

Aukeratu markaren balioa nahita. WireGuard-ek bere fwmark erabiltzen du kanpoko garraio-trafikorako, eta ustekabean zenbaki berera iristeak tuneleko bideratze-salbuespena oztopa dezake diagnostikatzeko mingarriak diren moduetan.

Jatorrizko helbideak ez dio bideari jarraitzen

Tunel-biderako jatorrizko helbide bat jada aukeratu duen socket batek helbide horri eusten dio berbideratzearen ondoren. Bideratze-aldaketan ezerk ez du berridazten, horregatik paketeak interfaze fisikoa uzten du goiko sareak itzuli ezin duen jatorri pribatu batekin.

Sintoma ikusgai da datuak bidaltzen ari dela dirudien eta inoiz erantzunik jasotzen ez duen aplikazio bat, eta ezer erakusten ez duen suebaki-erregistro bat, paketea ez baitzen inoiz itzuli.

Konponketa estua aplikazio horren markara eta haren benetako irteera-interfazera mugatutako jatorri-itzulpen araua da, lehendik dagoen NAT-arekin integratuta hura ordezkatu beharrean:

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

Itzuli salbuespena eta besterik ez. masquerade arau orokor batek sintoma konpontzen du eta zein trafikok zein bide hartu zuen esateko gaitasuna suntsitzen du. Egin bat markarekin, benetako irteera-interfazearekin eta, ahal baduzu, aplikazioaren beraren helbidearekin. Arau zabalak erraz idazten dira eta ia ezinezkoak dira geroago auditatzeko.

Zerk egiten dio ihes oraindik salbuespenari

Izen-ebazpena beste cgroup bateko resolver prozesu bereizi batetik etor daiteke, beraz nabigatzailearen socket-a sailkatzeak ez ditu haren kontsultak sailkatzen. Resolverraren kontsultak tunelean geratzen badira konexioa handik kanpora ateratzen den bitartean, split-horizon erantzunak ez datoz bat bidearekin. Desadostasun horrek DNS erroreak diruditen baina ez diren hutsegiteak sortzen ditu.

Prozesu seme-alabek cgroup heredatzen dute konfigurazio gehienetan, baina bere burua bere scope propiora eramaten duen laguntzaile batek ez. Egiaztatu, ez suposatu, bere burua berriz exekutatzen duen edozerrentzat bereziki.

Azkenik, erabaki zer gertatu behar den tunela behera dagoenean. Isilka saihesbide oso bihurtzen den salbuespena itxita huts egiten duenaren segurtasun-jarrera desberdina da, eta bien arteko bat baino ez da zuk nahi zenuena.

Erlazionatutako artikuluak