nftables-markeringar och VPN-routing: vilken regel vinner egentligen

En markering som sätts i nftables ska skicka en klass av trafik genom tunneln, och trafiken fortsätter att lämna via det fysiska gränssnittet. Regeluppsättningen ser korrekt ut isolerat. Det som vanligtvis har hänt är att något annat skrev samma markering, eller att routingregeln matchar en mask som det nya värdet inte längre uppfyller.

Kontroll 1: läs regeln som kärnan matchar

Börja med policyregeln i stället för brandväggen. Kärnan går igenom reglerna i prioritetsordning och den första träffen avgör tabellen. Läs fwmark-värdet och masken från själva regeln och bekräfta sedan att ett paket med markeringen du satte faktiskt matchar den. En regel som förväntar sig ett fullt 32-bitars värde matchar inte ett paket som bara bär en enda bit.

Bekräfta sedan vilken tabell regeln väljer och vad tabellen innehåller. En regel som pekar på en tom tabell ger ett misslyckat uppslag, vilket på många system innebär att paketet faller igenom till nästa regel och ut genom det fysiska gränssnittet.

Två kommandon avgör detta: regellistan och ruttuppslaget för destinationen i den tabellen.

Kontroll 2: paketmarkering eller anslutningsmarkering

nftables kan sätta en markering på paketet och en markering på anslutningsspårningsposten, och det är olika objekt. Paketmarkeringen lever under paketets bearbetningsomgång, medan anslutningsmarkeringen består för flödet och måste kopieras medvetet. Att sätta den ena och förvänta sig den andra är en vanlig halv lösning.

Om routingregeln bygger på paketmarkeringen gör återställandet av anslutningsmarkeringen senare i vägen ingenting för det beslutet, eftersom beslutet redan är fattat.

Bestäm vilket objekt som äger routing-signalen och sätt den sedan vid den punkt där routingbeslutet fattas.

Kontroll 3: vem mer skriver den markeringen

WireGuards egna verktyg markerar sina UDP-paket så att den krypterade transporten inte routas tillbaka in i tunneln som den tillhör. Om din regeluppsättning tilldelar samma fält ett orelaterat värde försvinner det undantaget och tunnelns yttre trafik försöker gå in i sig själv. Symtomet är en tunnel som etableras och sedan slutar föra trafik.

Markeringar används också av andra brandväggsverktyg, av containernätverk och av policyrouting för andra ändamål, så att två delsystem skriver hela fältet är en konflikt även när varje enskilt är korrekt.

Lista skrivarna innan du lägger till ännu en.

Kontroll 4: masken avgör vad du behåller

En markering är ett 32-bitars fält, och masker är sättet som flera ägare delar det på. Att sätta ett värde med mask bevarar de bitar du inte äger; att sätta hela fältet förstör allas andras. Läs masken i varje regel som rör fältet, inklusive dem du inte skrev.

Dokumentera bitfördelningen bredvid regeluppsättningen.

Annars återanvänder nästa person ett värde som redan har en ägare, och en konflikt här ser ut som en routingbugg medan den är en adresseringsbugg. nftables-dokumentationen om paketmetadata beskriver själva markeringsoperationerna.

Kontroll 5: verifiera med ett riktigt flöde, inte ett uppslag

Ett vanligt ruttuppslag bär ingen markering, så det kan visa en annan väg än det riktiga paketet. Generera trafiken du bryr dig om och observera räknarna, anslutningsspårningsposten och gränssnittet den faktiskt lämnar. Testa både den inkluderade klassen och den uteslutna klassen, eftersom en för bred markering bryter uteslutningen samtidigt som den ser lyckad ut. Om den inkluderade klassen fungerar och den uteslutna klassen också går in i tunneln är markeringen för bred och inte för smal.

Undvik att tömma anslutningstillståndet för att tvinga fram en uppdatering under en aktiv session, eftersom nya och befintliga flöden lagligt kan ta olika vägar.

Anteckna markeringen, masken och tabellen på ett ställe, och nästa ändring blir granskningsbar.