Obecnie najdłużej rozwijaną i najpowszechniej stosowaną zaporą systemu Linux jest iptables. Jednak jej kernelowy backend już dawno został podmieniony w transparentny sposób, a jego pełny potencjał możliwy jest do wykorzystania tylko przez nowe narzędzie nft.

Od ponad 20 lat obsługa sieci w systemie Linux rozwijana jest przez projekt Netfilter. Niewiele krótszą historię ma narzędzie iptables, które jest jedynie programem działającym w przestrzeni użytkownika. Za jego pomocą można wprowadzać zmiany w regułach filtrowania pakietów, które realizowane są przez podsystem jądra i jego moduł o nazwie x_tables. W latach 2009–2013 prowadzono prace nad nowym podsystemem filtrowania pakietów i powstał nf_tables. Ponieważ narzędzie iptables było już w tym czasie bardzo rozpowszechnione, zdecydowano się zrobić to w sposób transparentny dla użytkownika.

W tym celu zmieniono kod narzędzia iptables tak, aby tłumaczył swoje reguły na nowy język reguł modułu nf_tables. Problem polega na tym, że język reguł stosowanych przez iptables nie jest w stanie wykorzystać pełnych możliwości nowego podsystemu filtrowania. Deweloperzy modułu nf_tables od początku projektowali dla niego nowego klienta w postaci narzędzia nft. Jednak silne przywiązanie do iptables wśród społeczności spowodowało, iż więcej pracy poświęcano na jego integrację z nf_tables niż na rozwój nft. Taka sytuacja trwa od niemal siedmiu lat. Jednak obserwując komunikaty deweloperów niektórych dystrybucji systemu Linux, można zauważyć zdecydowaną chęć zmiany tego stanu rzeczy. Dla przykładu w dystrybucjach RHEL 8 i Debian Buster zdecydowano, iż domyślnym silnikiem filtrowania pakietów będzie nftables. Ponadto we wspomnianej wersji Debiana deweloperzy chcą, aby domyślnym narzędziem manipulacji zapory został nft.

> Co nowego w nftables

Od strony jądra nowe podejście do zapory systemu Linux to przede wszystkim integracja i rozszerzenie możliwości. Programiści Netfilter stworzyli nową maszynę wirtualną, która potrafi uruchamiać ustalony kod binarny w jądrze. Takie podejście sprawia, że dokonywanie zmian odbywa się przeważnie poza kodem jądra systemu. Natomiast komunikacja pomiędzy klientem a jądrem odbywa się za pomocą kernelowego protokołu netlink.

Do tej pory użytkownik systemu Linux używał wielu oddzielnych narzędzi {ip,ip6,arp,eb}tables do filtrowania ruchu, w zależności od protokołu. Teraz nft zastępuje je wszystkie. Narzędzia takie jak iptables nie pozwalają zastosować wielu akcji dla jednej reguły. Natomiast wykorzystanie zbioru adresów IP w regułach wymagało stosowania oddzielnego narzędzia ipset. Nftables nie tylko integruje te dwa narzędzia, ale wprowadza kilka typów listy klucz–wartość.

Reguły tworzone przez iptables tworzyły jeden zwarty kawałek kodu binarnego i wgrywały go do przestrzeni jądra. Zatem aktualizacja jednej z reguł wymagała przeładowania całego kodu. Jest to problem już obserwowany w środowisku z wielką liczbą kontenerów. W nftables każda reguła jest oddzielnym elementem w połączonej liście.

W odróżnieniu od iptables w nftables nie ma predefiniowanych tabel ani łańcuchów. Fakt ten stanowi największe wyzwanie w procesie przejścia pomiędzy tymi narzędziami. W zamian nft oferuje tzw. mechanizm podpięć (ang. hooks), które mogą być używane w strategicznych miejscach stosu sieciowego.

> Integracja z systemem

W dystrybucji Debian 11 (Buster) nie musimy niczego dodatkowo instalować, aby korzystać z nftables. Gdyby jednak brakowało nft, wystarczy poniższe polecenie.

# aptitude install nftables

Sama integracja polega na włączeniu usługi nftables.service.

# systemctl enable nftables
# grep Exec /lib/systemd/system/nftables.service
# ExecStart=/usr/sbin/nft -f /etc/nftables.conf
# ExecReload=/usr/sbin/nft -f /etc/nftables.conf
# ExecStop=/usr/sbin/nft flush ruleset

Jak widzimy, obsługuje ona trzy polecenia, a każde z nich odpowiada określonym komendom polecenia nft. Natomiast plik /etc/nftables.conf instalowany jest wraz z systemem i ma minimalną konfigurację.

> Podstawy

Wstępna konfiguracja zapory to dobry punkt wejścia w procesie poznawania składni nft. W rzeczywistości ta konfiguracja nie zawiera żadnych reguł, a jedynie definicje jednej tabeli i trzech łańcuchów. Więcej o najważniejszych elementach zapory nftables przeczytamy w ramce Netfilter hooks, tables i chains.

#!/usr/sbin/nft -f

flush ruleset

table inet filter {
chain input {
type filter hook input priority 0;
}
chain forward {
type filter hook forward priority 0;
}
chain output {
type filter hook output priority 0;
}
}

Pierwsza linia odpowiada za właściwą interpretację komend w powłoce systemowej. Druga z kolei resetuje zaporę poprzez usunięcie wszystkich dotychczasowych wpisów. W linii piątej definiowana jest tabela „filter” typu inet. Linie 6, 9 i 12 to definicje trzech łańcuchów typu filter. Wszystkie trzy są tego samego typu, ale każdy ma inny punkt podpięcia (hook). Na rys. 1 zostały umieszczone wszystkie podpięcia dla protokołu IP.

> Typy tabel

Tabele w nftables dzieli się ze względu na typ protokołu, który obsługują. Dostępne są następujące protokoły: ip, ip6, inet, arp, bridge, netdev. Protokół inet oznacza rodzinę protokołów ip i ip6. Poniższe polecenie tworzy tabelę przeznaczoną do obsługi protokołów IPv4/6 o nazwie „filter_t”.

# nft create table inet filter_t

[...]

Autor zawodowo zajmuje się informatyką. Jest członkiem społeczności open source, prowadzi blog na temat systemu GNU/Linux.