Bypass-i i cgroup në nftables kërkon gjithashtu korrigjim të adresës burimore

Shënimi i trafikut nga një cgroup është pjesa e lehtë. Tre vendime të ndara duhet të përputhen përpara se një aplikacion të dalë përmes ndërfaqes fizike ndërsa gjithçka tjetër mbetet në tunel: cili socket i përket përjashtimit, cila kërkim rrugëtimi aktivizon shenjën dhe cila adresë burimore mbart paketa kur del. Shumica e përpjekjeve të dështuara e bëjnë të parën saktë, të dytën gjysmë dhe nuk e shohin kurrë të tretën.

Tre vendime, jo një

Klasifikimi përgjigjet se kush është i përjashtuar. Rrugëtimi përgjigjet se ku shkon në vend të kësaj paketa e shënuar. Zgjedhja e burimit përgjigjet se çfarë do të shohë skaji i largët dhe ku duhet të kthehet përgjigjja.

Këto dështojnë në mënyrë të pavarur. Një paketë mund të klasifikohet, të ridrejtohet në ndërfaqen fizike dhe të mbajë ende një adresë private që asnjë ruter i sipërm nuk mund ta kthejë, gjë që prodhon një skadim kohe që duket saktësisht si bllokim i firewall-it. Asgjë në hapin e klasifikimit nuk të paralajmëron për këtë. Asgjë në hapin e rrugëtimit gjithashtu.

Rendi gjithashtu ka rëndësi. Klasifikimi ndodh kur paketa gjenerohet, rrugëtimi ndodh pas kësaj, dhe përkthimi ndodh në pikën e daljes.

Nëse nuk mund të emërtosh cila nga tre fazat është prishur, nuk po korrigjim gabime, po rirendit rregullat dhe po shpreson.

Përputh një cgroup që do të ekzistojë edhe nesër

nftables mund të testojë anëtarësimin në cgroup v2 të një socket, gjë që është vërtet e dobishme sepse ndjek procesin dhe jo destinacionin. Gracka është identifikuesi. Një aplikacion desktop i nisur nga menuja shpesh jeton në një scope kalimtar emri i të cilit ndryshon nisjen tjetër.

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

Kopjimi i një emri scope nga një sesion dhe kodimi i tij i ngurtë prodhon një rregull që funksionon sot dhe nesër ndalon në heshtje së përputhuri. Në vend të kësaj, vendos aplikacionin në një kontekst ekzekutimi të qëllimshëm dhe të qëndrueshëm, si një scope ose unit i dedikuar që kontrollon ti, dhe përputhu me atë. Rregulli atëherë i mbijeton rinisjeve dhe përditësimeve të paketave. Bëhet gjithashtu diçka për të cilën një koleg mund të mendojë pa historikun tënd të sesionit.

Ji gjithashtu i saktë për mekanizmin që përdor. Klasifikimi net_cls në cgroup v1 dhe përputhja e socket-eve në cgroup v2 janë gjëra të ndryshme, dhe një fushë me emër të ngjashëm në dokumentacion nuk i bën ato të këmbyeshme.

Zinxhiri route është ai që aktivizon kërkimin e dytë

Për trafikun e gjeneruar lokalisht, lloji i zinxhirit vendos nëse ndodh diçka pasi vendoset shenja. Një zinxhir output i llojit filter mund të shënojë një paketë dhe kerneli do të vazhdojë të përdorë rrugën që ka zgjedhur tashmë. Një zinxhir i llojit route është mekanizmi që kërkon një kërkim të ri.

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

Shenja pastaj ka nevojë për një rregull politike që e dërgon në një tabelë, dhe ajo tabelë duhet të jetë e plotë: një rrugë e parazgjedhur, destinacione lokale që aplikacioni ende i kërkon dhe një portë e sipërme që përgjigjet vërtet.

Zgjidh vlerën e shenjës me qëllim. WireGuard përdor fwmark-un e vet për trafikun e transportit të jashtëm, dhe ulja aksidentale në të njëjtin numër mund të ndërhyjë në përjashtimin e rrugëtimit të vetë tunelit në mënyra që janë të dhimbshme për t'u diagnostikuar.

Adresa burimore nuk ndjek rrugën

Një socket që ka zgjedhur tashmë një adresë burimore për shtegun e tunelit e mban atë adresë pas ridrejtimit. Asgjë në ndryshimin e rrugës nuk e rishkruan atë, prandaj paketa del nga ndërfaqja fizike me një burim privat që rrjeti i sipërm nuk mund ta kthejë.

Simptoma e dukshme është një aplikacion që duket se dërgon të dhëna dhe nuk merr kurrë përgjigje, dhe një regjistër i firewall-it që nuk tregon asgjë sepse paketa nuk u kthye kurrë.

Korrigjimi i ngushtë është një rregull përkthimi burimi i kufizuar në shenjën e atij aplikacioni dhe në ndërfaqen e tij reale të daljes, i integruar me NAT-in që ekziston tashmë në vend që ta zëvendësojë atë:

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

Përkthe vetëm përjashtimin dhe asgjë tjetër. Një rregull masquerade i përgjithshëm e rregullon simptomën dhe shkatërron aftësinë për të thënë se cili trafik mori cilën rrugë. Përputh shenjën, ndërfaqen reale të daljes dhe, nëse mundesh, adresën e vetë aplikacionit. Rregullat e gjera shkruhen lehtë dhe pothuajse nuk auditohen më vonë.

Çfarë ende i shpëton përjashtimit

Zgjidhja e emrave mund të vijë nga një proces resolver i veçantë në një cgroup tjetër, kështu që klasifikimi i socket-it të shfletuesit nuk i klasifikon kërkimet e tij. Nëse pyetjet e resolver-it mbeten në tunel ndërsa lidhja del jashtë tij, përgjigjet split-horizon mund të mos përputhen me shtegun. Ai mospërputhje prodhon dështime që duken si gabime DNS dhe nuk janë.

Proceset fëmijë trashëgojnë cgroup në shumicën e konfigurimeve, por një ndihmës që e zhvendos veten në scope-in e vet nuk e trashëgon. Kontrollo në vend që të supozosh, veçanërisht për çdo gjë që riekzekuton veten.

Së fundi, vendos çfarë duhet të ndodhë kur tuneli është poshtë. Një përjashtim që bëhet në heshtje një bypass i plotë është një qëndrim sigurie i ndryshëm nga ai që mbyllet, dhe vetëm njëri prej tyre është ai që kishit parasysh.