Nftables — свежее осуществление файрвола в ядре Linux, которая призвана поменять iptables. Как и почти все иные конструктивные конфигурации, данный инструмент до сего времени вызывает у юзеров противоречивые ощущения. И ключевой вопрос, естественно же, — какие выдающиеся качества возможно получить от перехода на него?
В заметке «Nftables. Как смотрится будущее опции файрвола в Linux» я рассмотрел основы опции nftables и передвижения с iptables. Комплект правил впоследствии передвижения стал короче. Спасибо свежим фичам nftables вроде переменных и интегрированной помощи групп объектов.Но все же по функциональности он схож со старым и некоторые юзеры вообще сомневаются в целесообразности миграции.
В данный момент мы разберем ряд функций nftables, которые в iptables отсутствуют, и убедимся, собственно что переработку файрвола в Linux создатели затеяли не от элементарной скукотищи.
Трассировка правил
Скорее всего случалось так, собственно,что необходимый трафик неверно блокируется неким правилом, но ты не имеешь возможности взять в толк, каким и как. У nftables для этих случаев есть интегрированное устройство трассировки правил.
Рассмотрим его на очевидном примере. Пусть у тебя правило блокирует весь трафик сети 192.0.2.0/24.
$ sudo nft insert rule inet filter input ip saddr 192.0.2.0/24 drop
Предположим, ты о нем забыл и в упор не видишь его в настройках, а пользователи жалуются, что не проходит трафик с хоста 192.0.2.1. Не беда — мы можем включить трассировку для всех пакетов с адресом источника 192.0.2.1. Это делается опцией nftrace set 1.
$ sudo nft insert rule inet filter input ip saddr 192.0.2.1 meta nftrace set 1
Теперь в выводе команды nft monitor trace мы можем увидеть весь путь этого пакета через наш набор правил.
Ныне мы сможем отыскать необходимое правило розыском по ip saddr 192.0.2.0/24. Это, естественно, очевидный образчик, и правило могло быть куда наименее обычным и бесспорным, но в выводе трассировки ты всякий раз узревается как раз правило, которое откинуло пакет.
$ sudo nft monitor trace trace id 66fdb23e inet filter input packet: iif "eth0" ether saddr ... ether daddr ... ip saddr 192.0.2.1 ip daddr 203.0.113.1 ip dscp cs0 ip ecn not-ect ip ttl 64 ip id 0 ip protocol icmp ip length 84 icmp type echo-request icmp code net-unreachable icmp id 50986 icmp sequence 1 @th,64,96 14560823784192396447041847296 trace id 66fdb23e inet filter input rule ip saddr 192.0.2.1 meta nftrace set 1 (verdict continue) trace id 66fdb23e inet filter input rule ip saddr 192.0.2.0/24 drop (verdict drop)
Как и с tcpdump/Wireshark, выбор аспекта для трассировки — задаток успешной отладки. Трассировка работает лишь только для пакетов, которые попали под правило с nftrace set 1. В случае если условие мало специфично,пакет в него не попадает. Устрой условие очень совокупным, вроде protocol tcp, и ты не сможешь отыскать необходимое в большом размере вывода.
Удаляем ненужное правило
В данный момент мы добавили отладочное правило, и впоследствии окончания сеанса отладки его отлично бы выслать. Как это сделать?В iptables требовалось показать любое условие правила. В nftables несколько по другому.
Поначалу нужно получить номер правила в таблице. Его возможно увидеть в выводе команды nft -a list ruleset (опция важна).
$ sudo nft -a list ruleset
table inet filter { # handle 7
...
chain input { # handle 1
type filter hook input priority filter; policy accept;
ip saddr 192.0.2.0/24 meta nftrace set 1 # handle 25
...
Здесь handle 25 — это и есть номер правила. Теперь мы можем удалить его командой sudo nft delete rule inet filter input handle 25.
В отличие от iptables удаление правил по полному набору опций в nftables не поддерживается. Несколько неудобно, что нельзя больше скопировать правило и поменять -A/-I на -D, но зато и команда для удаления правил стала короче.
Ассоциативные массивы
Старый инструмент IP set разрешал делать различные типы групп объектов, но не умел соотносить объекты с разрешениями — невозможно было в одном правиле допустить один объект, но запретить иной.
В правилах nftables можно ссылаться не на отдельный критерий и решение, а на ассоциативные массивы из них. Синтаксис таких ассоциативных массивов: vmap { объект : разрешение, …}. Здесь vmap — это опция, которая указывает, что последует именно массив из объектов и разрешений, а { ключ : значение, …} — общий синтаксис ассоциативных массивов.
Например, в одном правиле мы можем разрешить зашифрованные варианты SMTP (SMTPS и SMTP/STARTTLS), но запретить обычный на порте 25.
ct state new tcp dport vmap { 465 : accept, 587 : accept, 25 : drop } comment "Secure SMTP only"
Мы также можем определить именованный ассоциативный массив (например, banlist) и сослаться на него в правиле с помощью опции vmap @banlist. Именованный массив может быть и пустым, с расчетом на динамическое редактирование.
table inet filter {
map banlist {
type ipv4_addr : verdict
}
chain input {
type filter hook input priority filter; policy accept;
ip saddr vmap @banlist drop
}
}
Это очень упрощает работу скриптов вроде fail2ban, поскольку массив можно динамически редактировать средствами nftables.
$ sudo nft add element inet filter banlist { 203.0.113.80 : drop}
$ sudo nft delete element inet filter banlist { 192.0.2.98 : drop}
В IP set был встроенный набор типов, но не было возможности создать свои, поэтому разработчики добавили многочисленные варианты вроде hash:ip,port, пытаясь покрыть все возможные случаи. В nftables больше нет такой проблемы — элементы ассоциативных массивов могут быть произвольных типов.
Например, мы можем одним правилом NAT прокинуть порт 80 на адрес 10.0.0.10, а порт 25 — на адрес 10.0.0.20.
$ sudo nft add rule ip nat prerouting dnat tcp dport map { 80 : 10.0.0.10, 25 : 10.0.0.20 }
Даже если синтаксис nftables кажется тебе менее читаемым, в качестве компенсации он позволяет обойтись меньшим числом правил.
Stateless NAT
Когда то давно в ядре Linux был незатейливый NAT, положение соединений не отслеживалось. Устройство их отслеживания (conntrack) устроил жизнь сетевых админов куда чем лучше. Трудные протоколы больше чем с одним соединением прекратили быть неразрешимой задачей. Кроме этого,обработка пакетов стала скорее, потому что основную массу из них довольно сравнить с таблицей соединений (опция state в iptables), и уже не надо прогонять сквозь целый комплект правил.
Тем неменее временами stateless NAT — вправду одно из лучших решений. К примеру, провайдеры хостинга VPS вроде Amazon обширно используют 1:1 NAT, дабы облегчить управление сетью, — у самой виртуалки «серый» адресок, собственно что разрешает развязать наружную и внутреннюю маршрутизацию. Выслеживать направления трафика в данном случае не содержит смысла, потому что заключение для всех пакетов с одним адресом всякий раз однообразное.
В iptables это было возможно только при трансляции сетей IPv6 (NPTv6). В nftables снова появилась «тупая» (а значит, очень быстрая) трансляция адресов.
Например, транслируем внешний адрес 192.0.2.1 во внутренний 10.0.0.1.
table ip raw {
chain prerouting {
type filter hook prerouting priority raw; policy accept;
ip daddr 192.0.2.5 ip daddr set 10.0.0.1 notrack
}
}
В iptables у всякого критерия имеет возможность быть лишь только одно воздействие (оно ориентируется опцией -j). Использовать к 1 пакету некоторое количество различных действий возможно лишь только несколькими правилами.
В nftables у одного правила может быть несколько действий. Например, мы можем логировать пакеты из сети 192.0.2.0/24 и сразу блокировать их.
$ sudo nft insert rule inet filter input ip saddr 192.0.2.0/24 log level err prefix martian-source drop
Правила в этих таблицах обозревают полный трафик, когда он заходит из драйвера сетевой карты в сетевой стек ядра,включая кадры ARP. Это разрешает перекрыть пакеты ещё до того, как ядро начнет их обрабатывать. Создатели рекомендуют использовать эти таблицы для правил обороны от DDoS и аналогичного.
Заключение
Удалять iptables из ядра в обозримое время никто и не намеревается, например собственно мигрировать на nftables или же нет — решать тебе. Предполагаю, данный ликбез несомненно поможет тебе принять информированное и осмысленное решение.
