Značky nftables a směrování VPN: které pravidlo skutečně vyhraje

Značka nastavená v nftables má poslat jednu třídu provozu tunelem, ale provoz dál odchází fyzickým rozhraním. Sada pravidel vypadá izolovaně správně. Obvykle se stalo to, že něco jiného zapsalo stejnou značku, nebo pravidlo směrování odpovídá masce, kterou nová hodnota už nesplňuje.

Kontrola 1: přečtěte pravidlo, se kterým se jádro shoduje

Začněte pravidlem zásad, ne firewallem. Jádro prochází pravidla v pořadí priority a první shoda určuje tabulku. Přečtěte hodnotu fwmark a masku přímo z pravidla a pak potvrďte, že paket se značkou, kterou jste nastavili, mu skutečně odpovídá. Pravidlo očekávající plnou 32bitovou hodnotu se neshodne s paketem nesoucím jediný bit.

Potom potvrďte, kterou tabulku to pravidlo vybírá a co tabulka obsahuje. Pravidlo ukazující na prázdnou tabulku vyvolá selhání vyhledávání, což na mnoha systémech znamená, že paket propadne k dalšímu pravidlu a ven fyzickým rozhraním.

Dva příkazy to vyřeší: seznam pravidel a vyhledání trasy k cíli v této tabulce.

Kontrola 2: značka paketu, nebo značka spojení

nftables umí nastavit značku na paket a značku na záznam sledování spojení, a to jsou různé objekty. Značka paketu žije po dobu průchodu zpracováním paketu, zatímco značka spojení přetrvává pro tok a musí se vědomě kopírovat. Nastavit jednu a očekávat druhou je běžná poloviční oprava.

Pokud pravidlo směrování závisí na značce paketu, obnovení značky spojení později na cestě pro toto rozhodnutí nic neudělá, protože rozhodnutí už proběhlo.

Určete, který objekt vlastní signál směrování, a pak jej nastavte v místě, kde se rozhodnutí o směrování dělá.

Kontrola 3: kdo další tu značku zapisuje

Vlastní nástroje WireGuardu označují své UDP pakety, aby šifrovaný transport nebyl směrován zpět do tunelu, ke kterému patří. Pokud vaše sada pravidel přiřadí stejnému poli nesouvisející hodnotu, toto vyloučení zmizí a vnější provoz tunelu se pokusí vstoupit sám do sebe. Symptomem je tunel, který se naváže a pak přestane propouštět provoz.

Značky používají i další firewallové nástroje, kontejnerové sítě a politické směrování k jiným účelům, takže zápis celého pole dvěma subsystémy je konflikt, i když je každý jednotlivě správný.

Než přidáte dalšího, zapište si zapisovatele.

Kontrola 4: maska rozhoduje, co si ponecháte

Značka je 32bitové pole a masky jsou způsob, jak se o něj dělí více vlastníků. Nastavení hodnoty s maskou zachová bity, které nevlastníte; nastavení celého pole zničí bity všech ostatních. Přečtěte masku v každém pravidle, které se pole dotýká, včetně těch, která jste nenapsali.

Zdokumentujte přidělení bitů vedle sady pravidel.

Jinak další člověk znovu použije hodnotu, která už má vlastníka, a konflikt zde vypadá jako chyba směrování, zatímco jde o chybu adresování. Dokumentace nftables k metadatům paketů popisuje samotné operace se značkami.

Kontrola 5: ověřujte skutečným tokem, ne vyhledáním

Prosté vyhledání trasy nenese značku, takže může ukázat jinou cestu než skutečný paket. Vygenerujte provoz, který vás zajímá, a sledujte čítače, záznam sledování spojení a rozhraní, kterým skutečně odchází. Otestujte zařazenou i vyloučenou třídu, protože příliš široká značka rozbíjí vyloučení, a přitom vypadá úspěšně. Pokud zařazená třída funguje a vyloučená třída také vstoupí do tunelu, značka je příliš široká, ne příliš úzká.

Vyhněte se mazání stavu spojení, abyste vynutili obnovení během živé relace, protože nové a existující toky mohou legitimně jít různými cestami.

Zaznamenejte značku, masku a tabulku na jedno místo a příští úprava bude kontrolovatelná.