nftables cgroup-möödaviis vajab ka lähteaadressi parandust

Ühest cgroup-ist tuleva liikluse märgistamine on lihtne osa. Kolm eraldi otsust peavad klappima, enne kui üks rakendus väljub füüsilisest liidesest, samal ajal kui kõik muu jääb tunnelisse: milline socket kuulub erandi alla, millise marsruudiotsingu märge käivitab ja millist lähteaadressi pakett väljumisel kannab. Enamik ebaõnnestunud katseid saab esimese õigesti, teise poolenisti ja ei vaata kunagi kolmandat.

Kolm otsust, mitte üks

Klassifikatsioon vastab, kes on vabastatud. Marsruutimine vastab, kuhu märgistatud pakett selle asemel läheb. Lähtevalik vastab, mida näeb kaugem pool ja kuhu peaks vastus tagasi tulema.

Need ebaõnnestuvad üksteisest sõltumatult. Paketti saab klassifitseerida, füüsilisele liidesele ümber suunata ja see võib ikkagi kanda privaatset aadressi, mida ükski ülemvõrgu ruuter ei saa tagasi saata, mis tekitab ajapiirangu, mis näeb täpselt välja nagu tulemüüri blokeering. Miski klassifitseerimise sammus ei hoita sellest. Miski ka marsruutimise sammus.

Ka järjekord on oluline. Klassifikatsioon toimub paketi tekkimisel, marsruutimine pärast seda ja tõlkimine väljumispunktis.

Kui sa ei suuda nimetada, milline kolmest etapist on katki, siis sa ei silu, vaid paigutad reegleid ümber ja loodad.

Sobita cgroup, mis on olemas ka homme

nftables saab kontrollida socketi kuulumist cgroup v2-sse, mis on tõesti kasulik, sest see järgib protsessi, mitte sihtkohta. Konks on identifikaator. Menüüst käivitatud töölauarakendus elab sageli üleminekulises scope'is, mille nimi järgmisel käivitamisel muutub.

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

Scope'i nime ühest sessioonist kopeerimine ja kõvasti kodeerimine annab reegli, mis töötab täna ja lakkab homme vaikselt sobimast. Aseta rakendus hoopis meelega stabiilsesse täitmiskonteksti, näiteks sinu kontrollitavasse spetsiaalsesse scope'i või unit'isse, ja sobita sellega. Siis peab reegel vastu taaskäivitustele ja paketiuuendustele. Sellest saab ka midagi, mille üle kolleeg saab arutleda ilma sinu sessioonide ajaloota.

Ole täpne ka selle suhtes, millist mehhanismi kasutad. Cgroup v1 net_cls klassifitseerimine ja cgroup v2 socketi sobitamine on erinevad asjad ning dokumentatsioonis sarnase nimega väli ei tee neid vahetatavaks.

Teise otsingu käivitab just route-tüüpi ahel

Kohapeal tekitatud liikluse puhul otsustab ahela tüüp, kas pärast märke seadmist midagi juhtub. filter-tüüpi väljundahel võib paketi märgistada ja kernel jätkab juba valitud marsruudi kasutamist. route-tüüpi ahel on mehhanism, mis küsib uut otsingut.

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

Seejärel vajab märge poliitikareeglit, mis saadab selle tabelisse, ja see tabel peab olema täielik: vaikemarsruut, kõik kohalikud sihtkohad, mida rakendus veel vajab, ja ülemvõrgu lüüs, mis tegelikult vastab.

Vali märke väärtus teadlikult. WireGuard kasutab välimise transpordiliikluse jaoks oma fwmark'i, ja juhuslik sattumine samale numbrile võib segada tunneli enda marsruudierandit viisil, mida on valus diagnoosida.

Lähteaadress ei järgi marsruuti

Socket, mis on juba tunnelitee jaoks lähteaadressi valinud, hoiab seda aadressi ka pärast ümbersuunamist. Miski marsruudimuutuses ei kirjuta seda ümber, seepärast väljub pakett füüsilisest liidesest privaatse lähtega, mida ülemvõrk ei saa tagasi saata.

Nähtav sümptom on rakendus, mis näib andmeid saatvat ja ei saa kunagi vastust, ning tulemüüri logi, mis ei näita midagi, sest pakett ei tulnud kunagi tagasi.

Kitsas parandus on lähtetõlkereegel, mis on piiratud selle rakenduse märke ja selle tegeliku väljundliidesega, integreeritud olemasoleva NAT-iga, mitte seda asendades:

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

Tõlgi erand ja mitte midagi muud. Üldine masquerade-reegel parandab sümptomi ja hävitab sinu võime öelda, milline liiklus millist teed läks. Sobita märke, tegeliku väljundliidese ja võimalusel rakenduse enda aadressi järgi. Laiu reegleid on lihtne kirjutada ja hiljem peaaegu võimatu auditeerida.

Mis pääseb erandist ikka mööda

Nimelahendus võib tulla eraldi resolver-protsessist teises cgroup-is, seega brauseri socketi klassifitseerimine ei klassifitseeri selle päringuid. Kui resolveri päringud jäävad tunnelisse, samal ajal kui ühendus väljub sellest väljapoole, ei pruugi split-horizon vastused teega klappida. See lahknevus tekitab tõrkeid, mis näevad välja nagu DNS-vead, aga ei ole seda.

Lapsprotsessid pärivad cgroup-i enamikes seadetes, kuid abiline, mis liigutab end oma scope'i, ei päri. Kontrolli, mitte eelda, eriti kõige puhul, mis käivitab end uuesti.

Lõpuks otsusta, mis peaks juhtuma, kui tunnel on maas. Erand, mis muutub vaikselt täielikuks möödaviisiks, on teistsugune turvahoiak kui see, mis ebaõnnestub suletult, ja ainult üks neist on see, mida sa mõtlesid.