nftables-cgroup-ompad het ook 'n regstelling vir die bronadres nodig

Om een cgroup te merk stuur dit na 'n ander tabel, en die socket hou die adres wat dit reeds gehad het. Klassifiseer, roeteer en vertaal as drie afsonderlike stappe.

Om verkeer van een cgroup te merk is die maklike deel. Drie afsonderlike besluite moet in lyn kom voordat 'n enkele toepassing deur die fisiese koppelvlak uitgaan terwyl alles anders in die tonnel bly: watter socket by die uitsondering hoort, watter roetesoektog deur die merk geaktiveer word, en watter bronadres die pakket dra wanneer dit uitgaan. Die meeste mislukte pogings kry die eerste reg, kry die tweede halfpad reg, en kyk nooit na die derde nie.

Drie besluite, nie een nie

Klassifikasie antwoord wie vrygestel is. Roetering antwoord waarheen die gemerkte pakket eerder gaan. Bronkeuse antwoord wat die verre kant sal sien en waarheen die antwoord moet terugkeer.

Hierdie dinge misluk onafhanklik. 'n Pakket kan geklassifiseer word, na die fisiese koppelvlak herroeteer word, en steeds 'n private adres dra wat geen opstroomroeteerder kan terugstuur nie, wat 'n tydverstryking veroorsaak wat presies soos 'n firewall-blok lyk. Niks in die klassifikasiestap waarsku jou daaroor nie. Niks in die roeteringstap ook nie.

Die volgorde maak ook saak. Klassifikasie gebeur wanneer die pakket gegenereer word, roetering gebeur daarna, en adresvertaling gebeur by die punt van uitgang.

As jy nie kan sê watter van die drie fases stukkend is nie, dan ontfout jy nie, jy herrangskik reëls en hoop.

Pas 'n cgroup wat môre nog sal bestaan

nftables kan 'n socket se cgroup v2-lidmaatskap toets, wat werklik nuttig is omdat dit die proses volg eerder as die bestemming. Die vangplek is die identifiseerder. 'n Werkskermtoepassing wat uit 'n kieslys begin word, woon dikwels in 'n verbygaande scope waarvan die naam by die volgende bekendstelling verander.

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

Om 'n scope-naam uit een sessie te kopieer en hard te kodeer lewer 'n reël wat vandag werk en môre stilweg ophou pas. Plaas die toepassing eerder in 'n doelbewuste, stabiele uitvoeringskonteks, soos 'n toegewyde scope of eenheid wat jy beheer, en pas dit. Die reël oorleef dan herlaai en pakketopdaterings. Dit word ook iets waaroor 'n kollega kan redeneer sonder jou sessiegeskiedenis.

Wees ook presies oor watter meganisme jy gebruik. Cgroup v1 net_cls-klassifikasie en cgroup v2-socketpassing is verskillende dinge, en 'n veld met 'n soortgelyke naam in dokumentasie maak hulle nie uitruilbaar nie.

Dit is 'n roeteketting wat die tweede soektog aktiveer

Vir plaaslik gegenereerde verkeer besluit die kettipe of enigiets ná die merk gebeur. 'n Uitvoerketting van die filtertipe kan 'n pakket merk en die kernel sal aanhou om die roete te gebruik wat hy reeds gekies het. 'n Ketting van die roetetipe is die meganisme wat 'n nuwe soektog vra.

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

Die merk het dan 'n beleidsreël nodig wat dit na 'n tabel stuur, en daardie tabel moet volledig wees: 'n verstekroete, enige plaaslike bestemmings wat die toepassing steeds nodig het, en 'n opstroem-gateway wat werklik antwoord.

Kies die merkwaarde doelbewus. WireGuard gebruik sy eie fwmark vir buitenste vervoerverkeer, en om per ongeluk op dieselfde nommer te beland kan die tonnel se eie roete-uitsondering beïnvloed op maniere wat pynlik is om te diagnoseer.

Die bronadres volg nie die roete nie

'n Socket wat reeds 'n bronadres vir die tonnelpad gekies het, hou daardie adres ná die herroetering. Niks in die roeteverandering skryf dit oor nie, en daarom verlaat die pakket die fisiese koppelvlak met 'n private bron wat die opstroemnetwerk nie kan terugstuur nie.

Die sigbare simptoom is 'n toepassing wat lyk of dit data stuur en nooit 'n antwoord ontvang nie, en 'n firewall-log wat niks wys nie omdat die pakket nooit teruggekom het nie.

Die nou regstelling is 'n adresvertalingsreël wat beperk is tot daardie toepassing se merk en sy werklike uitvoerkoppelvlak, geïntegreer met watter NAT ook al bestaan eerder as om dit te vervang:

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

Vertaal die uitsondering en niks anders nie. 'n Kombers-masquerade-reël regstel die simptoom en vernietig jou vermoë om te sê watter verkeer watter pad gevolg het. Pas op die merk, die werklike uitvoerkoppelvlak en, as jy kan, die toepassing se eie adres. Breë reëls is maklik om te skryf en byna onmoontlik om later te oudit.

Wat steeds aan die uitsondering ontsnap

Naamresolusie kan van 'n aparte resolverproses in 'n ander cgroup kom, so om die blaaier se socket te klassifiseer klassifiseer nie sy soektogte nie. As die resolver se navrae in die tonnel bly terwyl die verbinding daarbuite uitgaan, kan split-horizon-antwoorde nie by die pad pas nie. Daardie wanstrook veroorsaak foute wat soos DNS-bugs lyk en nie is nie.

Kindprocesse erf die cgroup in die meeste opstellings, maar 'n helper wat homself in sy eie scope skuif, doen dit nie. Kontroleer eerder as om aan te neem, veral vir enigiets wat homself weer uitvoer.

Laastens, besluit wat moet gebeur wanneer die tonnel af is. 'n Uitsondering wat stilweg 'n volledige omleiding word, is 'n ander sekuriteitshouding as een wat toe misluk, en net een van hulle is wat jy bedoel het.

Verwante artikels