nftablesin cgroup-ohitus tarvitsee myös lähdeosoitteen korjauksen

Yhden cgroupin merkitseminen lähettää sen toiseen tauluun, ja socket säilyttää osoitteen, joka sillä jo oli. Luokittele, reititä ja käännä kolmena eri vaiheena.

Yhdestä cgroupista tulevan liikenteen merkitseminen on helppo osa. Kolmen erillisen päätöksen on osuttava yhteen ennen kuin yksikään sovellus lähtee fyysisen liitännän kautta, kun kaikki muu pysyy tunnelissa: mikä socket kuuluu poikkeukseen, minkä reitityshaun merkki käynnistää ja minkä lähdeosoitteen paketti kantaa lähtiessään. Useimmat epäonnistuneet yritykset saavat ensimmäisen oikein, toisen puoliksi eivätkä katso kolmatta lainkaan.

Kolme päätöstä, ei yksi

Luokittelu vastaa, kuka on vapautettu. Reititys vastaa, mihin merkitty paketti menee sen sijaan. Lähteen valinta vastaa, mitä kaukopää näkee ja mihin vastauksen pitäisi palata.

Nämä epäonnistuvat toisistaan riippumatta. Paketti voidaan luokitella, reitittää uudelleen fyysiselle liitännälle ja silti se voi kantaa yksityistä osoitetta, jota mikään ylemmän tason reititin ei voi palauttaa, mikä tuottaa aikakatkaisun, joka näyttää täsmälleen palomuurin estolta. Mikään luokitteluvaiheessa ei varoita siitä. Mikään reititysvaiheessakaan.

Myös järjestyksellä on väliä. Luokittelu tapahtuu paketin syntyessä, reititys sen jälkeen ja käännös lähtöpisteessä.

Jos et pysty nimeämään, mikä kolmesta vaiheesta on rikki, et etsi vikaa, vaan järjestelet sääntöjä uudelleen ja toivot parasta.

Sovita cgroup, joka on olemassa vielä huomennakin

nftables voi testata socketin cgroup v2 -jäsenyyttä, mikä on aidosti hyödyllistä, koska se seuraa prosessia eikä kohdetta. Kompastuskivi on tunniste. Valikosta käynnistetty työpöytäsovellus elää usein tilapäisessä scopessa, jonka nimi muuttuu seuraavalla käynnistyskerralla.

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

Scopen nimen kopioiminen yhdestä istunnosta ja kovakoodaaminen tuottaa säännön, joka toimii tänään ja lakkaa huomenna hiljaa täsmäämästä. Sijoita sovellus sen sijaan tarkoituksellisesti vakaaseen suoritusympäristöön, esimerkiksi omaan hallitsemaasi scopeen tai unitiin, ja sovita siihen. Silloin sääntö kestää uudelleenkäynnistykset ja pakettipäivitykset. Siitä tulee myös jotain, josta kollega voi järkeillä ilman istuntohistoriaasi.

Ole myös täsmällinen siitä, mitä mekanismia käytät. Cgroup v1:n net_cls-luokittelu ja cgroup v2:n socket-sovitus ovat eri asioita, eikä samanniminen kenttä dokumentaatiossa tee niistä vaihtokelpoisia.

Juuri route-tyyppinen ketju käynnistää toisen haun

Paikallisesti tuotetun liikenteen kohdalla ketjun tyyppi ratkaisee, tapahtuuko merkin asettamisen jälkeen mitään. filter-tyyppinen lähtöketju voi merkitä paketin, ja ydin jatkaa jo valitsemansa reitin käyttöä. route-tyyppinen ketju on mekanismi, joka pyytää uutta hakua.

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

Merkki tarvitsee sitten politiikkasäännön, joka lähettää sen tauluun, ja sen taulun on oltava täydellinen: oletusreitti, kaikki paikalliset kohteet, joita sovellus vielä tarvitsee, ja ylemmän tason yhdyskäytävä, joka todella vastaa.

Valitse merkin arvo tarkoituksella. WireGuard käyttää omaa fwmarkiaan ulomman siirtoliikenteen merkitsemiseen, ja vahingossa samaan numeroon päätyminen voi häiritä tunnelin omaa reitityspoikkeusta tavoilla, joita on tuskallista diagnosoida.

Lähdeosoite ei seuraa reittiä

Socket, joka on jo valinnut lähdeosoitteen tunnelin polulle, säilyttää sen osoitteen uudelleenreitityksen jälkeen. Mikään reititysmuutoksessa ei kirjoita sitä uudelleen, siksi paketti lähtee fyysiseltä liitännältä yksityisellä lähteellä, jota ylempi verkko ei voi palauttaa.

Näkyvä oire on sovellus, joka näyttää lähettävän dataa eikä koskaan saa vastausta, ja palomuuriloki, joka ei näytä mitään, koska paketti ei koskaan palannut.

Kapea korjaus on lähdeosoitteen käännössääntö, joka on rajattu kyseisen sovelluksen merkkiin ja sen todelliseen lähtöliitäntään, integroituna olemassa olevaan NATiin sen korvaamisen sijaan:

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

Käännä poikkeus eikä mitään muuta. Yleinen masquerade-sääntö korjaa oireen ja tuhoaa kykysi sanoa, mikä liikenne kulki mitä polkua. Sovita merkkiin, todelliseen lähtöliitäntään ja mahdollisuuksien mukaan sovelluksen omaan osoitteeseen. Laajat säännöt on helppo kirjoittaa ja lähes mahdotonta auditoida myöhemmin.

Mikä yhä karkaa poikkeukselta

Nimien selvitys voi tulla erillisestä resolver-prosessista toisessa cgroupissa, joten selaimen socketin luokittelu ei luokittele sen kyselyitä. Jos resolverin kyselyt jäävät tunneliin, kun yhteys lähtee sen ulkopuolelle, split-horizon-vastaukset eivät välttämättä sovi polkuun. Tämä epäsuhta tuottaa vikoja, jotka näyttävät DNS-bugilta eivätkä ole.

Lapsiprosessit perivät cgroupin useimmissa kokoonpanoissa, mutta apuri, joka siirtää itsensä omaan scopeensa, ei. Tarkista sen sijaan että oletat, erityisesti kaikelle, joka suorittaa itsensä uudelleen.

Päätä lopuksi, mitä pitäisi tapahtua, kun tunneli on alas. Poikkeus, joka muuttuu hiljaa täydelliseksi ohitukseksi, on eri turva-asetelma kuin se, joka epäonnistuu suljetusti, ja vain toinen niistä on se, mitä tarkoitit.

Aiheeseen liittyvät artikkelit