Назад | Перейти на главную страницу

Мост nftables соответствует локальным пакетам

Я использую Arch linux и установил мост с помощью bridge-utils. Теперь я бы хотел его установить файрволом. Я хотел бы отбросить несколько пакетов, проходящих через этот мост, позволяя этой машине свободно связываться с той, которая находится за мостом. Я обычно обрабатываю такие случаи, сопоставляя iifname lo, но, к сожалению, он не соответствует моим пакетам.

очередной раз, надеюсь, более четко

У меня две машины, master и slave.
master имеет две карты Ethernet. Один подключен к остальной части моей сети, другой - к slave
я хочу master чтобы иметь возможность отправить что-нибудь к slave
Я хочу отфильтровать трафик из остальной сети в slave на master

Я хотел бы сделать это с помощью nftables. У тебя есть идеи?

В lo интерфейс не является интерфейсом Ethernet. У него нет адреса канального уровня, и он определенно не может быть частью моста. Так что нет возможности iifname lo когда-либо будет соответствовать.

Схема моста по-прежнему организована аналогично схеме IP, но при работе на уровне 2: коммутируемые (а не маршрутизируемые) кадры Ethernet поступают в прямую цепочку. Кадры Ethernet, предназначенные для хоста, войдут во входную цепочку, кадры Ethernet, поступающие от хоста, войдут в выходную цепочку.

Предположим, сеть такая:

LAN <--------> eth0 master eth1 <--------> slave
                   (bridge0)

с участием eth0 и eth1 порабощен bridge0.

Таким образом, с одним уникальным мостом на хосте этого "пустого" набора правил nft достаточно, чтобы изолировать slave, позволяя master неограниченный трафик с LAN и slave, просто используя политику отбрасывания с прямой цепочкой.

#!/usr/sbin/nft -f

flush ruleset

table bridge filter {
    chain input {
        type filter hook input priority -200; policy accept;
    }

    chain forward {
        type filter hook forward priority -200; policy drop;
    }

    chain output {
        type filter hook input priority 200; policy accept;
    }
}

Конечно, можно ожидать, что ARP будет работать в обоих направлениях (иначе slave не сможет много сделать на уровне IP):

nft add rule bridge filter forward ether type arp accept

Теперь, если LAN разрешено пинговать slave, но не наоборот:

nft add rule bridge filter forward oif eth1 ip protocol icmp icmp type echo-request accept
nft add rule bridge filter forward iif eth1 ip protocol icmp icmp type echo-reply accept

Обратите внимание, что использование nftables на уровне моста все еще несколько ограничено (но чище) по сравнению с iptables, потому что на сегодняшний день интеграции conntrack нет. Так что, насколько мне известно, нет доступного межсетевого экрана с отслеживанием состояния.

Поэтому некоторые обычно простые задачи могут показаться неудобными, например: разрешить ssh с (возможно, удаленного) IP-адреса. 203.0.113.3. Это превращается в: разрешить трафик в обоих направлениях, за исключением начальной синхронизации, не разрешенной от ведомого устройства к локальной сети:

nft add rule bridge filter forward oif eth1 ip saddr 203.0.113.3 ip protocol tcp tcp dport 22 accept
nft add rule bridge filter forward iif eth1 ip daddr 203.0.113.3 ip protocol tcp tcp sport 22 tcp flags != syn accept

Если подключено более одного моста master, то, возможно, придется адаптировать правила и / или политики по умолчанию.