nftables-merker og VPN-ruting: hvilken regel vinner egentlig

Et merke som settes i nftables skal sende én klasse trafikk gjennom tunnelen, og trafikken fortsetter å gå ut gjennom det fysiske grensesnittet. Regelsettet ser riktig ut isolert. Det som vanligvis har skjedd, er at noe annet skrev det samme merket, eller at rutingsregelen samsvarer med en maske som den nye verdien ikke lenger oppfyller.

Sjekk 1: les regelen kjernen samsvarer med

Start med policyregelen i stedet for brannmuren. Kjernen går gjennom reglene i prioritetsrekkefølge, og det første treffet avgjør tabellen. Les fwmark-verdien og masken fra selve regelen, og bekreft deretter at en pakke med merket du satte, faktisk samsvarer med den. En regel som forventer en full 32-bits verdi, vil ikke samsvare med en pakke som bare bærer én bit.

Bekreft deretter hvilken tabell regelen velger, og hva tabellen inneholder. En regel som peker på en tom tabell, gir et mislykket oppslag, som på mange systemer betyr at pakken faller gjennom til neste regel og ut av det fysiske grensesnittet.

To kommandoer avgjør dette: regellisten og ruteoppslaget for målet i den tabellen.

Sjekk 2: pakkemerke eller tilkoblingsmerke

nftables kan sette et merke på pakken og et merke på tilkoblingssporingsoppføringen, og det er forskjellige objekter. Pakkemerket lever for pakkens behandlingsrunde, mens tilkoblingsmerket vedvarer for flyten og må kopieres bevisst. Å sette det ene og forvente det andre er en vanlig halv løsning.

Hvis rutingsregelen bygger på pakkemerket, gjør gjenoppretting av tilkoblingsmerket senere i banen ingenting for den beslutningen, fordi beslutningen allerede er tatt.

Avgjør hvilket objekt som eier rutingssignalet, og sett det deretter på punktet der rutingsbeslutningen tas.

Sjekk 3: hvem ellers skriver det merket

WireGuards egne verktøy merker UDP-pakkene sine slik at den krypterte transporten ikke rutes tilbake til tunnelen den tilhører. Hvis regelsettet ditt tildeler en urelatert verdi til det samme feltet, forsvinner den utelukkelsen, og den ytre trafikken til tunnelen prøver å gå inn i seg selv. Symptomet er en tunnel som etableres og deretter slutter å føre trafikk.

Merker brukes også av andre brannmurverktøy, av containernettverk og av policyruting til andre formål, så to delsystemer som skriver hele feltet er en konflikt selv når hvert enkelt er riktig.

List opp skriverne før du legger til enda en.

Sjekk 4: masken avgjør hva du beholder

Et merke er et 32-bits felt, og masker er måten flere eiere deler det på. Å sette en verdi med maske bevarer bitene du ikke eier; å sette hele feltet ødelegger alle andres. Les masken i hver regel som berører feltet, inkludert dem du ikke skrev.

Dokumenter bitfordelingen ved siden av regelsettet.

Ellers vil neste person gjenbruke en verdi som allerede har en eier, og en konflikt her ser ut som en rutingfeil mens den er en adresseringsfeil. nftables-dokumentasjonen om pakkemetadata beskriver selve merkeoperasjonene.

Sjekk 5: verifiser med en ekte flyt, ikke et oppslag

Et vanlig ruteoppslag bærer ikke et merke, så det kan vise en annen vei enn den ekte pakken. Generer trafikken du bryr deg om, og observer tellerne, tilkoblingssporingsoppføringen og grensesnittet den faktisk forlater. Test både den inkluderte klassen og den utelukkede klassen, fordi et for bredt merke ødelegger utelukkelsen mens det ser vellykket ut. Hvis den inkluderte klassen virker og den utelukkede klassen også går inn i tunnelen, er merket for bredt og ikke for smalt.

Unngå å tømme tilkoblingstilstand for å tvinge en oppdatering under en aktiv økt, siden nye og eksisterende flyter lovlig kan ta forskjellige veier.

Noter merket, masken og tabellen på ett sted, så blir neste endring gjennomgåelig.