nftables cgroup apiešanai vajadzīgs arī avota adreses labojums

Vienas cgroup atzīmēšana nosūta to uz citu tabulu, un socket saglabā adresi, kas tam jau bija. Klasificēšana, maršrutēšana un tulkošana ir trīs atsevišķi soļi.

Vienas cgroup datplūsmas atzīmēšana ir vieglā daļa. Trīs atsevišķiem lēmumiem jāsakrīt, pirms viena programma iziet pa fizisko saskarni, kamēr viss pārējais paliek tunelī: kurš socket pieder izņēmumam, kuru maršruta meklēšanu izraisa atzīme un kādu avota adresi pakete nes, kad tā iziet. Lielākā daļa neveiksmīgo mēģinājumu pirmo izdara pareizi, otro — pa pusei, bet trešo nekad neapskata.

Trīs lēmumi, nevis viens

Klasifikācija atbild, kas ir atbrīvots. Maršrutēšana atbild, kur atzīmētā pakete dodas tā vietā. Avota izvēle atbild, ko redzēs tālais gals un kur atbildei jāatgriežas.

Šie mirkļi neizdodas neatkarīgi. Paketi var klasificēt, pārvirzīt uz fizisko saskarni, un tā joprojām nesīs privātu adresi, ko neviens augšupējais maršrutētājs nevar atgriezt, un tas rada taimautu, kas izskatās tieši kā ugunsmūra bloķēšana. Nekas klasifikācijas solī par to nebrīdina. Nekas arī maršrutēšanas solī.

Svarīga ir arī secība. Klasifikācija notiek, kad pakete tiek ģenerēta, maršrutēšana notiek pēc tam, un tulkošana notiek izejas punktā.

Ja nevari nosaukt, kurš no trim posmiem ir salauzts, tu nedebošo, bet pārkārto noteikumus un ceri.

Saskaņo cgroup, kas pastāvēs arī rīt

nftables var pārbaudīt socket cgroup v2 piederību, un tas patiešām ir noderīgi, jo seko procesam, nevis galamērķim. Āķis ir identifikators. No izvēlnes palaista darbvirsmas programma bieži dzīvo pārejošā scope, kura nosaukums mainās nākamajā palaidē.

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

Scope nosaukuma nokopēšana no vienas sesijas un iekodēšana rada noteikumu, kas šodien darbojas un rīt klusi pārstāj atbilst. Tā vietā ievieto programmu apzinātā, stabilā izpildes kontekstā, piemēram, atsevišķā scope vai unit, ko kontrolē, un saskaņo ar to. Tad noteikums pārdzīvo pārstartēšanas un pakotņu atjauninājumus. Tas arī kļūst par kaut ko, par ko kolēģis var domāt bez tavas sesijas vēstures.

Esiet arī precīzi par to, kuru mehānismu izmantojat. cgroup v1 net_cls klasifikācija un cgroup v2 socket atbilstība ir dažādas lietas, un līdzīgi nosaukts lauks dokumentācijā nepadara tās aizstājamas.

Otro meklēšanu izraisa route ķēde

Lokāli ģenerētai datplūsmai ķēdes tips izlemj, vai pēc atzīmes iestatīšanas kaut kas notiks. filter tipa output ķēde var atzīmēt paketi, un kodols turpinās izmantot jau izvēlēto maršrutu. route tipa ķēde ir mehānisms, kas pieprasa jaunu meklēšanu.

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

Pēc tam atzīmei vajag politikas noteikumu, kas to nosūta uz tabulu, un šai tabulai jābūt pilnīgai: noklusējuma maršruts, lokālie galamērķi, kas programmai vēl vajadzīgi, un augšupēja vārteja, kas tiešām atbild.

Atzīmes vērtību izvēlies apzināti. WireGuard ārējai transporta datplūsmai izmanto savu fwmark, un nejauša nonākšana uz to pašu numuru var traucēt paša tuneļa maršruta izņēmumam tā, ka diagnostika ir sāpīga.

Avota adrese neseko maršrutam

Socket, kas jau ir izvēlējies avota adresi tuneļa ceļam, saglabā to arī pēc pārvirzīšanas. Nekas maršruta izmaiņās to nepārraksta, tāpēc pakete iziet pa fizisko saskarni ar privātu avotu, ko augšupējais tīkls nevar atgriezt.

Redzamais simptoms ir programma, kas šķietami sūta datus un nekad nesaņem atbildi, un ugunsmūra žurnāls, kas neko neuzrāda, jo pakete nekad neatgriezās.

Šaurais labojums ir avota tulkošanas noteikums, kas ierobežots ar šīs programmas atzīmi un tās reālo izejas saskarni, integrēts ar jau esošo NAT, nevis to aizstājot:

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

Tulko tikai izņēmumu un neko citu. Vispārīgs masquerade noteikums izlabo simptomu un iznīcina spēju noteikt, kura datplūsma gāja kuru ceļu. Saskaņo pēc atzīmes, reālās izejas saskarnes un, ja iespējams, pašas programmas adreses. Platus noteikumus ir viegli rakstīt un gandrīz neiespējami vēlāk auditēt.

Kas joprojām izbēg no izņēmuma

Nosaukumu izšķiršana var nākt no atsevišķa resolver procesa citā cgroup, tāpēc pārlūka socket klasificēšana neklasificē tā meklējumus. Ja resolver vaicājumi paliek tunelī, bet savienojums iziet ārpus tā, split-horizon atbildes var nesakrist ar ceļu. Šī neatbilstība rada kļūmes, kas izskatās kā DNS kļūdas, bet nav.

Bērnu procesi vairumā konfigurāciju manto cgroup, bet palīgs, kas pārvieto sevi uz savu scope, nemanto. Pārbaudi, nevis pieņem, īpaši visam, kas sevi palaiž no jauna.

Visbeidzot, izlem, kam jānotiek, kad tunelis ir izslēgts. Izņēmums, kas klusi kļūst par pilnīgu apiešanu, ir cita drošības pozīcija nekā tas, kas aizveras, un tikai viens no tiem ir tas, ko tu domāji.

Saistītie raksti