La cgroup-ĉirkaŭvojo en nftables ankaŭ bezonas korekton de la fonta adreso

Marki unu cgroup sendas ĝin al alia tabelo, kaj la socket konservas la adreson, kiun ĝi jam havis. Klasifiku, enkursigu kaj traduku kiel tri apartajn paŝojn.

Marki trafikon el unu cgroup estas la facila parto. Tri apartaj decidoj devas kunordiĝi antaŭ ol unu aplikaĵo eliru tra la fizika interfaco dum ĉio alia restas en la tunelo: kiu socket apartenas al la escepto, kiun enkursigan serĉon la marko ekigas, kaj kiun fontan adreson la pako portas kiam ĝi eliras. Plej multaj malsukcesaj provoj pravas pri la unua, duone pri la dua, kaj neniam rigardas la trian.

Tri decidoj, ne unu

Klasifiko respondas, kiu estas esceptita. Enkursigo respondas, kien anstataŭe iras la markita pako. Fontelekto respondas, kion vidos la malproksima flanko kaj kien la respondo devas reveni.

Ĉi tiuj malsukcesas sendepende. Pako povas esti klasifikita, reenkcursigita al la fizika interfaco kaj tamen porti privatan adreson, kiun neniu suprena enkursigilo povas resendi, kio produktas tempolimon, kiu aspektas precize kiel fajroŝirma blokado. Nenio en la klasifika paŝo avertas vin pri tio. Nenio ankaŭ en la enkcursiga paŝo.

Ankaŭ la ordo gravas. Klasifiko okazas kiam la pako estas generata, enkcursigo okazas poste, kaj traduko okazas ĉe la elira punkto.

Se vi ne povas nomi, kiu el la tri stadioj estas rompita, vi ne sencimigas, vi reordigas regulojn kaj esperas.

Kongruigu cgroup, kiu ekzistos ankaŭ morgaŭ

nftables povas testi la membrecon de socket en cgroup v2, kio estas vere utila ĉar ĝi sekvas la procezon, ne la celon. La malfacilaĵo estas la identigilo. Labortabla aplikaĵo lanĉita el menuo ofte loĝas en pasema scope, kies nomo ŝanĝiĝas ĉe la sekva lanĉo.

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

Kopii scope-nomon el unu sesio kaj malmole enkodigi ĝin produktas regulon, kiu funkcias hodiaŭ kaj morgaŭ silente ĉesas kongrui. Anstataŭe metu la aplikaĵon en intence stabilan plenumkuntekston, ekzemple dediĉitan scope aŭ unit, kiun vi kontrolas, kaj kongruigu ĝin. Tiam la regulo postvivas restartojn kaj pakaĵajn ĝisdatigojn. Ĝi ankaŭ fariĝas io, pri kio kolego povas racii sen via sesia historio.

Estu ankaŭ preciza pri tio, kiun mekanismon vi uzas. La klasifiko net_cls en cgroup v1 kaj la socket-kongruigo en cgroup v2 estas malsamaj aferoj, kaj simile nomita kampo en dokumentaro ne igas ilin interŝanĝeblaj.

Ĝuste ĉeno de tipo route ekigas la duan serĉon

Por loke generata trafiko, la ĉena tipo decidas, ĉu io okazas post kiam la marko estas metita. Eliga ĉeno de tipo filter povas marki pakon kaj la kerno daŭre uzos la itineron, kiun ĝi jam elektis. Ĉeno de tipo route estas la mekanismo, kiu petas novan serĉon.

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

La marko tiam bezonas politikan regulon, kiu sendas ĝin al tabelo, kaj tiu tabelo devas esti kompleta: defaŭlta itinero, ĉiuj lokaj celoj, kiujn la aplikaĵo ankoraŭ bezonas, kaj suprena kluzo, kiu efektive respondas.

Elektu la markvaloron konscie. WireGuard uzas sian propran fwmark por la ekstera transporta trafiko, kaj hazarde surteriĝi sur la sama nombro povas ĝeni la propran enkcursigan escepton de la tunelo tiel, ke diagnozo estas dolora.

La fonta adreso ne sekvas la itineron

Socket, kiu jam elektis fontan adreson por la tunela vojo, konservas tiun adreson post la reenkcursigo. Nenio en la enkcursiga ŝanĝo reskribas ĝin, tial la pako forlasas la fizikan interfacon kun privata fonto, kiun la suprena reto ne povas resendi.

La videbla simptomo estas aplikaĵo, kiu ŝajne sendas datumojn kaj neniam ricevas respondon, kaj fajroŝirma protokolo, kiu montras nenion ĉar la pako neniam revenis.

La mallarĝa riparo estas fonta traduka regulo limigita al la marko de tiu aplikaĵo kaj al ĝia reala eliga interfaco, integrita en la ekzistantan NAT anstataŭ anstataŭigi ĝin:

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

Traduku la escepton kaj nenion alian. Ĝenerala masquerade-regulo riparas la simptomon kaj detruas vian kapablon diri, kiu trafiko iris laŭ kiu vojo. Kongruigu la markon, la realan eligan interfacon kaj, se eble, la propran adreson de la aplikaĵo. Larĝaj reguloj estas facile skribeblaj kaj preskaŭ neeble revizieblaj poste.

Kio ankoraŭ eskapas la escepton

Noma rezolucio povas veni de aparta resolver-procezo en alia cgroup, do klasifiki la socket de la retumilo ne klasifikas ĝiajn serĉojn. Se la demandoj de la resolver restas en la tunelo dum la konekto eliras ekster ĝin, split-horizon respondoj povas ne kongrui kun la vojo. Tiu miskongruo produktas paneojn, kiuj aspektas kiel DNS-cimoj kaj ne estas.

Idaj procezoj heredas la cgroup en plej multaj agordoj, sed helpilo, kiu movas sin en sian propran scope, ne. Kontrolu anstataŭ supozi, precipe pri io, kio reekzekutas sin.

Fine, decidu, kio devas okazi kiam la tunelo estas malaktiva. Escepto, kiu silente fariĝas kompleta ĉirkaŭvojo, estas alia sekureca sinteno ol tiu, kiu paneas fermite, kaj nur unu el ili estas tio, kion vi celis.

Rilataj artikoloj