nftables-mærker og VPN-routing: hvilken regel vinder egentlig

Et mærke, der sættes i nftables, skal sende én klasse af trafik gennem tunnelen, og trafikken bliver ved med at forlade systemet via den fysiske grænseflade. Regelsættet ser korrekt ud isoleret set. Det, der normalt er sket, er, at noget andet har skrevet det samme mærke, eller at routingsreglen matcher en maske, som den nye værdi ikke længere opfylder.

Tjek 1: læs den regel, kernen matcher

Start med politikreglen i stedet for firewalla. Kernen gennemgår reglerne i prioritetsrækkefølge, og det første match afgør tabellen. Læs fwmark-værdien og masken fra selve reglen, og bekræft derefter, at en pakke med det mærke, du har sat, faktisk matcher den. En regel, der forventer en fuld 32-bit værdi, matcher ikke en pakke, der kun bærer en enkelt bit.

Bekræft derefter, hvilken tabel reglen vælger, og hvad tabellen indeholder. En regel, der peger på en tom tabel, giver et fejlslagent opslag, hvilket på mange systemer betyder, at pakken falder igennem til den næste regel og ud af den fysiske grænseflade.

To kommandoer afgør det: regellisten og ruteopslaget for destinationen i den tabel.

Tjek 2: pakkemærke eller forbindelsesmærke

nftables kan sætte et mærke på pakken og et mærke på forbindelsessporingsposten, og det er forskellige objekter. Pakkemærket lever i pakkens behandlingsgang, mens forbindelsesmærket består for flowet og skal kopieres bevidst. At sætte det ene og forvente det andet er en almindelig halv løsning.

Hvis routingsreglen bygger på pakkemærket, gør gendannelse af forbindelsesmærket senere i stien intet for den beslutning, fordi beslutningen allerede er taget.

Beslut, hvilket objekt der ejer routingssignalet, og sæt det derefter på det punkt, hvor routingbeslutningen træffes.

Tjek 3: hvem ellers skriver det mærke

WireGuards egne værktøjer mærker sine UDP-pakker, så den krypterede transport ikke bliver routet tilbage i den tunnel, den hører til. Hvis dit regelsæt tildeler en uvedkommende værdi til det samme felt, forsvinder den udelukkelse, og tunnelens ydre trafik forsøger at gå ind i sig selv. Symtomet er en tunnel, der etableres og derefter holder op med at føre trafik.

Mærker bruges også af andre firewallværktøjer, af containernetværk og af politikbaseret routing til andre formål, så to delsystemer, der skriver hele feltet, er en konflikt, selv når hver enkelt er korrekt.

List skriverne, før du tilføjer endnu en.

Tjek 4: masken bestemmer, hvad du beholder

Et mærke er et 32-bit felt, og masker er måden, hvorpå flere ejere deler det. At sætte en værdi med en maske bevarer de bits, du ikke ejer; at sætte hele feltet ødelægger alles andres. Læs masken i hver regel, der rører feltet, inklusive dem, du ikke har skrevet.

Dokumentér bittildelingen ved siden af regelsættet.

Ellers vil den næste person genbruge en værdi, der allerede har en ejer, og en konflikt her ligner en routingfejl, mens den er en adresseringsfejl. nftables-dokumentationen om pakkemetadata beskriver selve mærkeoperationerne.

Tjek 5: verificér med et rigtigt flow, ikke et opslag

Et almindeligt ruteopslag bærer ikke et mærke, så det kan vise en anden vej end den rigtige pakke. Generér den trafik, du er interesseret i, og observer tællerne, forbindelsessporingsposten og den grænseflade, den faktisk forlader. Test både den inkluderede klasse og den udelukkede klasse, fordi et for bredt mærke ødelægger udelukkelsen, mens det ser vellykket ud. Hvis den inkluderede klasse virker, og den udelukkede klasse også går ind i tunnelen, er mærket for bredt og ikke for smalt.

Undgå at tømme forbindelsestilstand for at tvinge en opdatering under en aktiv session, da nye og eksisterende flows lovligt kan tage forskellige veje.

Notér mærket, masken og tabellen ét sted, så bliver den næste ændring gennemskuelig.