nftables-merke og VPN-ruting: kva regel vinn eigentleg

Eit merke som blir sett i nftables skal senda éin klasse trafikk gjennom tunnelen, og trafikken held fram med å gå ut gjennom det fysiske grensesnittet. Regelsettet ser rett ut isolert. Det som vanlegvis har skjedd, er at noko anna skreiv det same merket, eller at rutingsregelen svarar til ei maske som den nye verdien ikkje lenger oppfyller.

Sjekk 1: les regelen kjernen svarar til

Start med policyregelen i staden for brannmuren. Kjernen går gjennom reglane i prioritetsrekkjefølgje, og det første treffet avgjer tabellen. Les fwmark-verdien og maska frå sjølve regelen, og stadfest deretter at ein pakke med merket du sette, faktisk svarar til han. Ein regel som ventar ein full 32-bits verdi, vil ikkje svara til ein pakke som berre ber éin bit.

Stadfest deretter kva tabell regelen vel, og kva tabellen inneheld. Ein regel som peikar på ein tom tabell, gir eit mislukka oppslag, som på mange system betyr at pakken fell gjennom til neste regel og ut av det fysiske grensesnittet.

To kommandoar avgjer dette: regellista og ruteoppslaget for målet i den tabellen.

Sjekk 2: pakkemerke eller tilkoplingsmerke

nftables kan setja eit merke på pakken og eit merke på tilkoplingsoppføringa, og det er ulike objekt. Pakkemerket lever for behandlingsrunden til pakken, medan tilkoplingsmerket varer for flyten og må kopierast medvite. Å setja det eine og venta det andre er ei vanleg halv løysing.

Viss rutingsregelen byggjer på pakkemerket, gjer gjenoppretting av tilkoplingsmerket seinare i banen ingenting for den avgjerda, fordi avgjerda alt er teken.

Avgjer kva objekt som eig rutingssignalet, og set det deretter på punktet der rutingsavgjerda blir teken.

Sjekk 3: kven elles skriv det merket

WireGuard sine eigne verktøy merkjer UDP-pakkane sine slik at den krypterte transporten ikkje blir ruta tilbake til tunnelen han høyrer til. Viss regelsettet ditt gir ein urelatert verdi til det same feltet, forsvinn den utelukkinga, og den ytre trafikken til tunnelen prøver å gå inn i seg sjølv. Symptomet er ein tunnel som blir etablert og deretter sluttar å føra trafikk.

Merke blir også brukte av andre brannmurverktøy, av containernettverk og av policyruting til andre føremål, så to delsystem som skriv heile feltet er ein konflikt sjølv når kvart enkelt er rett.

List opp skrivarane før du legg til endå ein.

Sjekk 4: maska avgjer kva du behheld

Eit merke er eit 32-bits felt, og masker er måten fleire eigarar deler det på. Å setja ein verdi med maske bevarer bitane du ikkje eig; å setja heile feltet øydelegg alle andre sine. Les maska i kvar regel som rører feltet, også dei du ikkje skreiv.

Dokumenter bitfordelinga ved sida av regelsettet.

Elles vil neste person gjenbruka ein verdi som alt har ein eigar, og ein konflikt her ser ut som ein rutingfeil medan han er ein adresseringsfeil. nftables-dokumentasjonen om pakkemetadata skildrar sjølve merkeoperasjonane.

Sjekk 5: stadfest med ein ekte flyt, ikkje eit oppslag

Eit vanleg ruteoppslag ber ikkje eit merke, så det kan visa ein annan veg enn den ekte pakken. Generer trafikken du bryr deg om, og observer teljarane, tilkoplingsoppføringa og grensesnittet han faktisk forlèt. Test både den inkluderte klassen og den utelukka klassen, fordi eit for breitt merke øydelegg utelukkinga medan det ser vellukka ut. Viss den inkluderte klassen verkar og den utelukka klassen også går inn i tunnelen, er merket for breitt og ikkje for smalt.

Unngå å tøma tilkoplingstilstand for å tvinga ein oppdatering under ein aktiv økt, sidan nye og eksisterande flytar lovleg kan ta ulike vegar.

Noter merket, maska og tabellen på eitt stad, så blir neste endring gjennomgåeleg.