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

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

опять же, надеюсь, более четко

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

Я хотел бы сделать это с помощью nftables. Есть ли у вас какие-либо идеи?

Источник

1 ответ

Решение

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

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

Давайте предположим, что сеть такая:

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

с eth0 а также eth1 порабощен bridge0,

Таким образом, с одним уникальным мостом на хосте этого "пустого" набора правил nft достаточно, чтобы изолировать slave, позволяя master неограниченный трафик с локальной сетью и 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

Теперь, если локальной сети разрешено пинговать 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тогда правила и / или политики по умолчанию, возможно, придется адаптировать.

Источник
Другие вопросы по тегам