nftablesi märgised ja VPN-i marsruutimine: milline reegel tegelikult võidab

nftablesis seatud märgis peaks saatma ühe liiklusklassi tunnelist läbi, kuid liiklus jätkab väljumist füüsilisest liidesest. Reeglistik tundub eraldi vaadatuna korrektne. Tavaliselt on juhtunud see, et miski muu kirjutas sama märgise, või et marsruutimisreegel vastab maskile, mida uus väärtus enam ei rahulda.

Kontroll 1: lugege reegel, millega tuum kokku sobib

Alustage poliitikareeglist, mitte tulemüürist. Tuum vaatab reeglid läbi prioriteedi järjekorras ja esimene vaste otsustab tabeli. Lugege fwmarki väärtus ja mask reeglist endast, seejärel kinnitage, et teie seatud märgisega pakett tõesti sellega vastab. Reegel, mis ootab täisväärtust 32 biti ulatuses, ei vasta paketile, mis kannab ainult ühte bitti.

Seejärel kinnitage, millise tabeli see reegel valib ja mida tabel sisaldab. Tühjale tabelile osutav reegel tekitab otsingu nurjumise, mis paljudes süsteemides tähendab, et pakett langeb järgmisele reeglile ja väljub füüsilisest liidesest.

Kaks käsku seda lahendavad: reeglite loend ja sihtkoha marsruudiotsing selles tabelis.

Kontroll 2: paketi märgis või ühenduse märgis

nftables saab seada märgise paketile ja märgise ühenduse jälgimise kirjele ning need on erinevad objektid. Paketi märgis elab paketi töötlemiskäigu jooksul, samas kui ühenduse märgis püsib voolu jaoks ja tuleb teadlikult kopeerida. Ühe seadmine ja teise ootamine on tavaline poolik parandus.

Kui marsruutimisreegel tugineb paketi märgisele, ei tee ühenduse märgise taastamine hiljem teekonnal selle otsuse jaoks midagi, sest otsus on juba tehtud.

Otsustage, milline objekt omab marsruutimissignaali, seejärel seadke see punktis, kus marsruutimisotsus tehakse.

Kontroll 3: kes veel seda märgist kirjutab

WireGuardi enda tööriistad märgistavad oma UDP-paketid, et krüpteeritud transporti ei marsruuditaks tagasi tunnelisse, kuhu see kuulub. Kui teie reeglistik omistab samale väljale mitteseotud väärtuse, kaob see välistus ja tunneli väline liiklus üritab iseendasse siseneda. Sümptomiks on tunnel, mis luuakse ja seejärel lakkab liiklust läbi laskmast.

Märgiseid kasutavad ka teised tulemüüritööriistad, konteinerite võrgundus ja poliitikapõhine marsruutimine muudel eesmärkidel, seega on kogu välja kirjutamine kahe alamsüsteemi poolt konflikt ka siis, kui kumbki eraldi on korrektne.

Loetlege kirjutajad enne, kui lisate veel ühe.

Kontroll 4: mask otsustab, mida te alles hoiate

Märgis on 32-bitine väli ja maskid on viis, kuidas mitu omanikku seda jagavad. Väärtuse seadmine maskiga hoiab alles bitid, mis teile ei kuulu; kogu välja seadmine hävitab kõigi teiste omad. Lugege maski igas reeglis, mis välja puudutab, ka nendes, mida te ei kirjutanud.

Dokumenteerige bittide jaotus reeglistiku kõrval.

Vastasel juhul kasutab järgmine inimene uuesti väärtust, millel on juba omanik, ja konflikt siin näeb välja nagu marsruutimisviga, olles tegelikult aadressimisviga. nftablesi dokumentatsioon paketi metaandmete kohta kirjeldab märgiseoperatsioone endid.

Kontroll 5: kontrollige päris vooluga, mitte otsinguga

Tavaline marsruudiotsing ei kanna märgist, seega võib see näidata teistsugust teed kui tegelik pakett. Looge liiklus, mis teid huvitab, ja jälgige loendureid, ühenduse jälgimise kirjet ja liidest, millest see tegelikult väljub. Testige nii kaasatud kui ka välistatud klassi, sest liiga lai märgis rikub välistuse, nähes samal ajal edukas välja. Kui kaasatud klass töötab ja välistatud klass läheb samuti tunnelisse, on märgis liiga lai, mitte liiga kitsas.

Vältige ühenduse oleku tühjendamist, et sundida värskendust aktiivse sessiooni ajal, kuna uued ja olemasolevad voolud võivad seaduslikult minna erinevaid teid.

Kirjutage märgis, mask ja tabel ühte kohta üles, siis muutub järgmine muudatus ülevaatatavaks.