Bypass cgroup v nftables potrebuje aj opravu zdrojovej adresy

Označenie jednej cgroup ju pošle do inej tabuľky a socket si ponechá adresu, ktorú už mal. Klasifikácia, smerovanie a preklad ako tri samostatné kroky.

Označenie prevádzky z jednej cgroup je tá ľahšia časť. Tri samostatné rozhodnutia sa musia zladiť, kým jedna aplikácia vyjde cez fyzické rozhranie, zatiaľ čo všetko ostatné zostane v tuneli: ktorý socket patrí k výnimke, ktoré hľadanie trasy označenie spustí a akú zdrojovú adresu paket nesie, keď vychádza. Väčšina neúspešných pokusov spraví prvé správne, druhé na polovicu a na tretie sa nikdy nepozrie.

Tri rozhodnutia, nie jedno

Klasifikácia odpovedá, kto je vyňatý. Smerovanie odpovedá, kam označený paket ide namiesto toho. Výber zdroja odpovedá, čo uvidí vzdialený koniec a kam sa má odpoveď vrátiť.

Tieto veci zlyhávajú nezávisle. Paket môže byť klasifikovaný, presmerovaný na fyzické rozhranie a napriek tomu niesť súkromnú adresu, ktorú žiadny nadradený router nedokáže vrátiť, čo vytvorí časový limit, ktorý vyzerá presne ako blokovanie firewallu. Nič v kroku klasifikácie vás na to neupozorní. Nič v kroku smerovania tiež nie.

Aj poradie je dôležité. Klasifikácia nastane, keď sa paket vytvorí, smerovanie potom a preklad v bode výstupu.

Ak nedokážete pomenovať, ktorá z troch fáz je pokazená, neladíte, ale preskupujete pravidlá a dúfate.

Priraďte cgroup, ktorá bude existovať aj zajtra

nftables dokáže otestovať príslušnosť socketu k cgroup v2, čo je naozaj užitočné, pretože nasleduje proces a nie cieľ. Háčik je identifikátor. Desktopová aplikácia spustená z menu často žije v prechodnom scope, ktorého názov sa pri ďalšom spustení zmení.

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

Skopírovanie názvu scope z jednej relácie a jeho pevné zapísanie vytvorí pravidlo, ktoré dnes funguje a zajtra ticho prestane zodpovedať. Namiesto toho umiestnite aplikáciu do zámerného, stabilného kontextu vykonávania, napríklad do vyhradeného scope alebo unitu, ktorý ovládate, a priraďte ten. Pravidlo potom prežije reštarty a aktualizácie balíkov. Stane sa aj niečím, o čom kolega dokáže uvažovať bez vašej histórie relácií.

Buďte tiež presní v tom, ktorý mechanizmus používate. Klasifikácia net_cls v cgroup v1 a párovanie socketov v cgroup v2 sú rozdielne veci a podobne pomenované pole v dokumentácii ich nezameniteľnými nerobí.

Druhé hľadanie spúšťa reťaz route

Pre lokálne generovanú prevádzku typ reťaze rozhoduje, či sa po nastavení označenia niečo stane. Reťaz output typu filter môže označiť paket a jadro bude ďalej používať trasu, ktorú už vybralo. Reťaz typu route je mechanizmus, ktorý žiada nové hľadanie.

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

Označenie potom potrebuje pravidlo politiky, ktoré ho pošle do tabuľky, a tá tabuľka musí byť úplná: predvolená trasa, lokálne ciele, ktoré aplikácia ešte potrebuje, a nadradená brána, ktorá skutočne odpovedá.

Hodnotu označenia vyberte zámerne. WireGuard používa vlastný fwmark pre vonkajšiu transportnú prevádzku a náhodné pristátie na rovnakom čísle môže narušiť výnimku smerovania samotného tunela spôsobmi, ktoré sa ťažko diagnostikujú.

Zdrojová adresa nenasleduje trasu

Socket, ktorý si už vybral zdrojovú adresu pre cestu tunela, si ju po presmerovaní ponechá. Nič v zmene trasy ju neprepíše, a preto paket vychádza cez fyzické rozhranie so súkromným zdrojom, ktorý nadradená sieť nedokáže vrátiť.

Viditeľným príznakom je aplikácia, ktorá vyzerá, že odosiela dáta, a nikdy nedostane odpoveď, a log firewallu, ktorý nič neukazuje, pretože paket sa nikdy nevrátil.

Úzka oprava je pravidlo prekladu zdroja obmedzené na označenie tej aplikácie a jej skutočné výstupné rozhranie, integrované s existujúcim NAT namiesto jeho nahradenia:

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

Preložte výnimku a nič iné. Všeobecné pravidlo masquerade opraví príznak a zničí vašu schopnosť povedať, ktorá prevádzka išla ktorou cestou. Priraďte označenie, skutočné výstupné rozhranie a ak môžete, adresu samotnej aplikácie. Široké pravidlá sa ľahko píšu a takmer nedajú neskôr auditovať.

Čo stále uniká výnimke

Rozlišovanie názvov môže prichádzať zo samostatného procesu resolvera v inej cgroup, takže klasifikácia socketu prehliadača neklasifikuje jeho vyhľadávania. Ak otázky resolvera zostanú v tuneli, zatiaľ čo spojenie ide mimo neho, odpovede split-horizon nemusia sedieť s cestou. Ten nesúlad vytvára poruchy, ktoré vyzerajú ako chyby DNS a nie sú.

Podriadené procesy dedia cgroup vo väčšine nastavení, ale pomocník, ktorý sa presunie do vlastného scope, nie. Overujte namiesto predpokladania, najmä pri všetkom, čo sa znova spúšťa.

Nakoniec rozhodnite, čo sa má stať, keď je tunel dole. Výnimka, ktorá sa ticho stane úplným obídením, je iná bezpečnostná pozícia ako tá, ktorá pri zlyhaní zatvára, a len jedna z nich je to, čo ste mysleli.

Súvisiace články