nftables cgroup-bypass trenger også en korreksjon av kildeadressen

Å merke én cgroup sender den til en annen tabell, og socketen beholder adressen den allerede hadde. Klassifiser, rute og oversett som tre separate trinn.

Å merke trafikk fra én cgroup er den enkle delen. Tre separate beslutninger må stemme før én applikasjon går ut gjennom det fysiske grensesnittet mens alt annet blir i tunnelen: hvilken socket som hører til unntaket, hvilket ruteoppslag merket utløser, og hvilken kildeadresse pakken bærer når den går ut. De fleste mislykkede forsøk treffer den første, halvtreffer den andre, og ser aldri på den tredje.

Tre beslutninger, ikke én

Klassifisering svarer på hvem som er unntatt. Ruting svarer på hvor den merkede pakken går i stedet. Kildevalg svarer på hva den andre enden vil se og hvor svaret skal komme tilbake.

Disse feiler uavhengig. En pakke kan klassifiseres, ruttes om til det fysiske grensesnittet, og fortsatt bære en privat adresse som ingen oppstrøms ruter kan returnere, noe som gir en tidsavbrudd som ser nøyaktig ut som en brannmurblokkering. Ingenting i klassifiseringstrinnet advarer deg om det. Ingenting i rutingtrinnet heller.

Rekkefølgen betyr også noe. Klassifisering skjer når pakken genereres, ruting skjer etter det, og oversettelse skjer ved utgangspunktet.

Hvis du ikke kan navngi hvilket av de tre stadiene som er ødelagt, feilsøker du ikke, du omorganiserer regler og håper.

Match en cgroup som fortsatt finnes i morgen

nftables kan teste en sockets cgroup v2-medlemskap, noe som er virkelig nyttig fordi det følger prosessen og ikke destinasjonen. Haken er identifikatoren. En skrivebordsapplikasjon startet fra en meny lever ofte i en midlertidig scope der navnet endres ved neste oppstart.

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

Å kopiere et scope-navn fra én økt og hardkode det gir en regel som fungerer i dag og stille slutter å samsvare i morgen. Sett applikasjonen i en bevisst, stabil kjøringskontekst i stedet, for eksempel en egen scope eller unit du kontrollerer, og match den. Regelen overlever da omstart og pakkeoppdateringer. Den blir også noe en kollega kan resonnere om uten økthistorikken din.

Vær også presis på hvilken mekanisme du bruker. net_cls-klassifisering i cgroup v1 og socket-matching i cgroup v2 er forskjellige ting, og et likt navngitt felt i dokumentasjonen gjør dem ikke utbyttbare.

Det er rute-kjeden som utløser det andre oppslaget

For lokalt generert trafikk avgjør kjedetypen om noe skjer etter at merket er satt. En output-kjede av filter-typen kan merke en pakke, og kjernen vil fortsette å bruke ruten den allerede har valgt. En kjede av route-typen er mekanismen som ber om et nytt oppslag.

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

Merket trenger da en policyregel som sender det til en tabell, og den tabellen må være komplett: en standardrute, lokale destinasjoner applikasjonen fortsatt trenger, og en oppstrøms gateway som faktisk svarer.

Velg merkeverdien bevisst. WireGuard bruker sin egen fwmark for ytre transporttrafikk, og å lande på samme nummer ved et uhell kan forstyrre tunnelens egen ruteunntak på måter som er vonde å diagnostisere.

Kildeadressen følger ikke ruten

En socket som allerede har valgt en kildeadresse for tunnelbanen, beholder den adressen etter omrutingen. Ingenting i ruteendringen skriver den om, og derfor går pakken ut gjennom det fysiske grensesnittet med en privat kilde som oppstrømsnettet ikke kan returnere.

Det synlige symptomet er en applikasjon som ser ut til å sende data og aldri mottar svar, og en brannmurlogg som ikke viser noe fordi pakken aldri kom tilbake.

Den smale rettelsen er en kildeoversettelsesregel begrenset til den applikasjonens merke og dens faktiske utgangsgrensesnitt, integrert med den NAT-en som allerede finnes i stedet for å erstatte den:

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

Oversett unntaket og ingenting annet. En generell masquerade-regel fikser symptomet og ødelegger evnen din til å si hvilken trafikk som tok hvilken vei. Match på merket, det faktiske utgangsgrensesnittet og, hvis du kan, applikasjonens egen adresse. Brede regler er lette å skrive og nesten umulige å revidere senere.

Hva som fortsatt slipper unna unntaket

Navneoppslag kan komme fra en separat resolverprosess i en annen cgroup, så å klassifisere nettleserens socket klassifiserer ikke oppslagene dens. Hvis resolverens spørringer blir i tunnelen mens tilkoblingen går utenfor den, kan split-horizon-svar ikke stemme med veien. Det misforholdet gir feil som ser ut som DNS-feil og ikke er det.

Barneprosesser arver cgroup i de fleste oppsett, men en hjelper som flytter seg inn i sin egen scope gjør det ikke. Sjekk i stedet for å anta, spesielt for alt som kjører seg selv på nytt.

Til slutt, bestem hva som skal skje når tunnelen er nede. Et unntak som stille blir en full bypass er en annen sikkerhetsstilling enn et som feiler lukket, og bare ett av dem er det du mente.

Relaterte artikler