nftables cgroup-framhjáleið þarf líka leiðréttingu á upprunaneti

Að merkja eitt cgroup sendir það í aðra töflu og sambandið heldur netfanginu sem það hafði þegar. Flokka, beina og þýða sem þrjú aðskilin skref.

Að merkja umferð frá einu cgroup er auðveldi hlutinn. Þrjár aðskildar ákvarðanir þurfa að fara saman áður en eitt forrit fer út um eðlisfræðilega tengið á meðan allt annað er áfram í göngunum: hvaða samband tilheyrir undantekningunni, hvaða leiðarleit merkið kallar fram og hvaða upprunanetfang pakkinn ber þegar hann fer út. Flest mistök fá þá fyrstu rétta, hálfrétta þá aðra og líta aldrei á þá þriðju.

Þrjár ákvarðanir, ekki ein

Flokkun svarar því hver er undanþeginn. Beining svarar því hvert merkti pakkinn fer í staðinn. Val upprunanetfangs svarar því hvað fjarlægi endinn mun sjá og hvert svarið á að fara til baka.

Þessi mistakast óháð. Hægt er að flokka pakka, beina honum á eðlisfræðilega tengið og hann ber samt einkaaðsetur sem enginn uppstreymisbeini getur sent til baka, sem veldur tímannarkmiði sem lítur nákvæmlega út eins og eldveggsblokkun. Ekkert í flokkunarskrefinu varar þig við því. Ekkert í beiningarskrefinu heldur.

Röðin skiptir líka máli. Flokkun gerist þegar pakkinn er búinn til, beining gerist eftir það og þýðing gerist á útgöngupunktinum.

Ef þú getur ekki nefnt hvaða af þremur stigum er bilað, þá ertu ekki að kemba heldur ertu að endurraða reglum og vona.

Passaðu cgroup sem verður enn til á morgun

nftables getur prófað cgroup v2-aðild sambands, sem er raunverulega gagnlegt því það fylgir ferlinu frekar en áfangastaðnum. Gildran er auðkennið. Skjáforrit sem ræst er úr valmynd lifir oft í skammvinnu scope þar sem nafnið breytist við næstu ræsingu.

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

Að afrita scope-nafn úr einni lotu og harðkóða það framleiðir reglu sem virkar í dag og hættir hljóðlega að passa á morgun. Settu forritið í viljandi, stöðugt keyrsluumhverfi í staðinn, svo sem sérstakt scope eða einingu sem þú stýrir, og passaðu við það. Reglan lifir þá endurræsingar og pakkauppfærslur. Hún verður líka eitthvað sem samstarfsmaður getur hugsað um án lotusögu þinnar.

Vertu líka nákvæmur um hvaða fyrirkomulag þú notar. net_cls flokkun cgroup v1 og sambandspössun cgroup v2 eru ólíkir hlutir og samnefnt svið í skjölum gerir þau ekki skiptanleg.

Beiningarkeðja er það sem kallar fram aðra leitina

Fyrir umferð sem mynduð er á staðnum ákveður keðjutegundin hvort eitthvað gerist eftir að merkið er sett. Output-keðja af filter-gerð getur merkt pakka og kjarninn heldur áfram að nota beininguna sem hann valdi þegar. Keðja af route-gerð er fyrirkomulagið sem biður um nýja leit.

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

Merkið þarf þá stefnureglu sem sendir það í töflu, og sú tafla þarf að vera heildstæð: sjálfgefin beining, hver áfangastaður á staðnum sem forritið þarf enn og uppstreymisgátt sem svarar raunverulega.

Veldu merkisgildið af ásetningi. WireGuard notar sitt eigið fwmark fyrir ytri flutningsumferð og að lenda óvart á sama númeri getur truflað beiningarundantekningu gangnanna á þann hátt að erfitt er að greina.

Upprunanetfangið fylgir ekki beiningunni

Samband sem hefur þegar valið upprunanetfang fyrir gönguleiðina heldur því netfangi eftir að beint hefur verið aftur. Ekkert í beiningarbreytingunni endurskrifar það, sem er ástæðan fyrir því að pakkinn fer út um eðlisfræðilega tengið með einkauppruna sem uppstreymisnetið getur ekki sent til baka.

Sýnileg einkenni eru forrit sem virðist senda gögn og fær aldrei svar, og eldveggsskrá sem sýnir ekkert því pakkinn kom aldrei til baka.

Þrönga lausnin er þýðingarregla upprunanetfangs sem takmörkuð er við merki þess forrits og raunverulega úttakstengið þess, samþætt við það NAT sem þegar er til í stað þess að koma í staðinn:

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

Þýddu undantekninguna og ekkert annað. Almenn masquerade-regla lagar einkennin og eyðileggur getu þína til að segja hvaða umferð fór hvaða leið. Passaðu við merkið, raunverulega úttakstengið og ef hægt er við netfang forritsins sjálfs. Breiðar reglur eru auðveldar að skrifa og nánast ómögulegar að endurskoða síðar.

Hvað fer enn fram hjá undantekningunni

Nafnupplausn getur komið frá aðskildu leysiferli í öðru cgroup, þannig að að flokka samband vafrans flokkar ekki leitir hans. Ef fyrirspurnir leysisins vera í göngunum á meðan tengingin fer út fyrir þau geta svör split-horizon misræmst leiðinni. Það misræmi veldur bilunum sem líta út eins og DNS-villur en eru það ekki.

Barnaferlar erfa cgroup í flestum uppsetningum, en hjálpari sem flytur sig í sitt eigið scope gerir það ekki. Athugaðu frekar en að gera ráð fyrir, sérstaklega fyrir allt sem keyrir sig aftur.

Að lokum skaltu ákveða hvað á að gerast þegar göngin eru niðri. Undantekning sem hljóðlega verður algjör framhjáleið er annar öryggisstaða en sú sem lokar sér, og aðeins önnur þeirra er það sem þú meinti.

Tengdir greinar