It omsilen fan cgroup yn nftables hat ek in korreksje fan it boarneadres nedich

It markearjen fan ien cgroup stjoert it nei in oare tabel, en de socket hâldt it adres dat er al hie. Klassifisearje, rûte en oersette as trije aparte stappen.

It markearjen fan ferkear fan ien cgroup is it maklike part. Trije aparte besluten moatte op ien line komme foardat ien applikaasje troch de fysike ynterface nei bûten giet wylst al it oare yn 'e tunnel bliuwt: hokker socket by de útsûndering heart, hokker rûtesykjen de marke aktivearret, en hokker boarneadres it pakket draacht as it nei bûten giet. De measte mislearre besykjen krije de earste goed, krije de twadde heal, en sjogge nea nei de tredde.

Trije besluten, net ien

Klassifikaasje antwurdet wa't frijsteld is. Rûte antwurdet wêr't it markearre pakket ynstee hinne giet. Boarnekar antwurdet wat de fiere kant sjocht en wêr't it antwurd weromkomme moat.

Dizze mislearje ûnôfhinklik. In pakket kin klassifisearre wurde, nei de fysike ynterface omrûte wurde, en dochs in privee adres drage dat gjin upstream-router weromstjoere kin, wat in timeout opleveret dy't der krekt as in firewall-blokkade útsjocht. Neat yn 'e klassifikaasjestap warskôget dêrfoar. Neat yn 'e rûtestap ek.

De folchoarder makket ek út. Klassifikaasje bart as it pakket makke wurdt, rûte bart dêrnei, en oersetting bart op it punt fan útgeän.

As jo net neame kinne hokker fan 'e trije fazen stikken is, dan debugge jo net, jo sette regels oars en hoopje.

Kies in cgroup dy't der moarn noch is

nftables kin it cgroup v2-lidmaatskip fan in socket testen, wat echt nuttich is om't it de prosedueres folget en net de bestimming. De fâle is de identifier. In desktop-applikaasje dy't fan in menu start wurdt, libbet faak yn in tydlike scope wêrfan de namme by de folgjende start feroaret.

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

In scopenamme út ien sesje kopiearje en hurd kodearje jout in regel dy't hjoed wurket en moarn stil ophâldt te passen. Set de applikaasje ynstee yn in bewust stabile útfieringskontekst, lykas in tawijde scope of unit dy't jo beheare, en pas dêrop. Dan oerlibbet de regel werynstallaasjes en pakketfernijings. It wurdt ek eat dêr't in kollega oer neitinke kin sûnder dyn sesjeskiednis.

Wês ek presys oer hokker meganisme jo brûke. Cgroup v1 net_cls-klassifikaasje en cgroup v2-socketpassing binne ferskillende dingen, en in fjild mei in likense namme yn dokumintaasje makket se net útwikselber.

It is in keatling fan it type route dy't it twadde sykjen aktivearret

Foar lokaal generearre ferkear beslút it keatlingtype oft der nei it setten fan 'e marke wat bart. In útgongsketting fan it type filter kin in pakket markearje en de kernel sil de rûte dy't er al keas bliuwe brûken. In keatling fan it type route is it meganisme dat in nij sykjen freget.

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

De marke hat dan in beliedsregel nedich dy't it nei in tabel stjoert, en dy tabel moat folslein wêze: in standertrûte, alle lokale bestimmings dy't de applikaasje noch nedich hat, en in upstream-gateway dy't echt antwurdet.

Kies de markewearde bewust. WireGuard brûkt syn eigen fwmark foar ferkear bûten de tunnel, en by ûngelok op itselde nûmer belâne kin de eigen rûte-útsûndering fan 'e tunnel bemuoie op manieren dy't pynlik binne om te diagnostisearjen.

It boarneadres folget de rûte net

In socket dy't al in boarneadres foar it tunnelpaad keas, hâldt dat adres nei it omrûten. Neat yn 'e rûteferoaring skriuwt it oer, dêrom ferlit it pakket de fysike ynterface mei in privee boarne dy't it upstream-netwurk net weromstjoere kin.

It sichtbere symptoom is in applikaasje dy't liket data te stjoeren en nea in antwurd krijt, en in firewall-log dy't neat toant om't it pakket nea weromkaam.

De smelle korreksje is in boarne-oersettingsregel beheind ta de marke fan dy applikaasje en syn echte útgongsynterface, yntegrearre mei hokker NAT dan ek al bestiet ynstee fan it te ferfangen:

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

Oerset de útsûndering en neat oars. In algemiene masquerade-regel reparearret it symptoom en ferneatiget jo fermogen om te sizzen hokker ferkear hokker paad naam. Pas op 'e marke, de echte útgongsynterface en, as jo kinne, it eigen adres fan 'e applikaasje. Brede regels binne maklik te skriuwen en hast net te auditearjen letter.

Wat noch altyd oan 'e útsûndering ûntkomt

Namme-oplossing kin fan in apart resolver-proses yn in oare cgroup komme, dat it klassifisearjen fan 'e socket fan 'e browser klassifisearret syn sykjen net. As de fragen fan 'e resolver yn 'e tunnel bliuwe wylst de ferbining derbûten giet, kinne split-horizon-antwurden net by it paad passe. Dy misferhâlding makket flaters dy't as DNS-bugs lykje en it net binne.

Bernprosessen ervje de cgroup by de measte opsetningen, mar in helper dy't himsels yn syn eigen scope set, docht dat net. Kontrolearje ynstee fan oannimme, benammen foar alles dat himsels opnij útfiert.

Beslút úteinlik wat der barre moat as de tunnel del is. In útsûndering dy't stil in folsleine omgong wurdt, is in oare feiligenshâlding as ien dy't ticht falt, en mar ien fan beide is wat jo bedoelden.

Relatearre artikelen