nftables-merkinnät ja VPN-reititys: mikä sääntö oikeastaan voittaa

nftablesissa asetetun merkinnän pitäisi lähettää yksi liikenneluokka tunnelin kautta, mutta liikenne jatkaa poistumista fyysisen rajapinnan kautta. Sääntökokonaisuus näyttää erikseen tarkasteltuna oikealta. Yleensä on käynyt niin, että jokin muu kirjoitti saman merkinnän, tai että reitityssääntö vastaa maskia, jota uusi arvo ei enää täytä.

Tarkistus 1: lue sääntö, johon ydin osuu

Aloita käytäntösäännöstä, älä palomuurista. Ydin käy säännöt läpi prioriteettijärjestyksessä ja ensimmäinen osuma ratkaisee taulun. Lue fwmark-arvo ja maski säännöstä itsestään ja varmista sitten, että asettamasi merkinnän sisältävä paketti todella osuu siihen. Sääntö, joka odottaa täyttä 32 bitin arvoa, ei osu pakettiin, joka kantaa vain yhtä bittiä.

Varmista sitten, minkä taulun tämä sääntö valitsee ja mitä taulu sisältää. Tyhjään tauluun osoittava sääntö tuottaa epäonnistuneen haun, mikä monissa järjestelmissä tarkoittaa, että paketti putoaa seuraavalle säännölle ja ulos fyysisestä rajapinnasta.

Kaksi komentoa ratkaisee tämän: sääntöluettelo ja reittihaku kohteen taulussa.

Tarkistus 2: paketin merkintä vai yhteyden merkintä

nftables voi asettaa merkinnän pakettiin ja merkinnän yhteysseurannan tietueeseen, ja ne ovat eri objekteja. Paketin merkintä elää paketin käsittelykierron ajan, kun taas yhteyden merkintä säilyy vuolle ja se on kopioitava tarkoituksella. Toisen asettaminen ja toisen odottaminen on yleinen puolittainen korjaus.

Jos reitityssääntö perustuu paketin merkintään, yhteyden merkinnän palauttaminen myöhemmin polulla ei tee mitään tälle päätökselle, koska päätös on jo tehty.

Päätä, mikä objekti omistaa reitityssignaalin, ja aseta se sitten kohdassa, jossa reitityspäätös tehdään.

Tarkistus 3: kuka muu kirjoittaa tuon merkinnän

WireGuardin omat työkalut merkitsevät UDP-pakettinsa, jotta salattu siirto ei reitity takaisin siihen tunneliin, johon se kuuluu. Jos sääntökokonaisuutesi antaa samalle kentälle asiaankuulumattoman arvon, se poissulkeminen katoaa ja tunnelin ulompi liikenne yrittää mennä itseensä. Oireena on tunneli, joka muodostuu ja lakkaa sitten välittämästä liikennettä.

Merkintöjä käyttävät myös muut palomuurityökalut, konttiverkotus ja käytäntöpohjainen reititys muihin tarkoituksiin, joten kahden alijärjestelmän koko kentän kirjoittaminen on ristiriita, vaikka kumpikin olisi erikseen oikeassa.

Listaa kirjoittajat ennen kuin lisäät vielä yhden.

Tarkistus 4: maski ratkaisee, mitä pidät

Merkintä on 32 bitin kenttä, ja maskit ovat tapa, jolla useat omistajat jakavat sen. Arvon asettaminen maskin kanssa säilyttää bitit, jotka eivät ole sinun; koko kentän asettaminen tuhoaa kaikkien muiden bitit. Lue maski jokaisesta säännöstä, joka koskettaa kenttää, mukaan lukien ne, joita et kirjoittanut.

Dokumentoi bittien jako sääntökokonaisuuden viereen.

Muuten seuraava henkilö käyttää uudelleen arvoa, jolla on jo omistaja, ja ristiriita näyttää tässä reititysbugilta, vaikka se on osoitteistusbugi. nftablesin dokumentaatio paketin metatiedoista kuvaa itse merkintätoiminnot.

Tarkistus 5: varmista oikealla vuolla, älä haulla

Tavallinen reittihaku ei kanna merkintää, joten se voi näyttää eri polun kuin todellinen paketti. Tuota liikenne, joka sinua kiinnostaa, ja tarkkaile laskureita, yhteysseurannan tietuetta ja rajapintaa, josta se todella poistuu. Testaa sekä sisällytetty luokka että poissuljettu luokka, koska liian laaja merkintä rikkoo poissulkemisen näyttäen silti onnistuneelta. Jos sisällytetty luokka toimii ja poissuljettu luokka menee myös tunneliin, merkintä on liian laaja eikä liian kapea.

Vältä yhteyksien tilan tyhjentämistä päivityksen pakottamiseksi kesken aktiivisen istunnon, koska uudet ja olemassa olevat vuot voivat laillisesti kulkea eri polkuja.

Kirjaa merkintä, maski ja taulu yhteen paikkaan, niin seuraava muutos on tarkistettavissa.