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

iptables: сопоставление только нетегированного трафика на интерфейсе с VLAN

Насколько я знаю, нет возможности различить трафик VLAN в iptables на главном интерфейсе (это интерфейс, к которому интерфейсы виртуальных VLAN добавляются с помощью vconfig или ip link add link; я не знаю, правильный ли это термин, я призываю вас исправить меня).

В общем, это не проблема, поскольку вы можете использовать интерфейс виртуальной VLAN вместо главного интерфейса, например

iptables -A INPUT -i eth0.1 -p tcp -m tcp --dport 22 -j ACCEPT

Это позволит пакетам TCP-порта 22 (SSH) поступать на eth0.1, пакеты, приходящие на eth0 с тегом VLAN-ID 1.

Проблемы возникают, когда вы хотите сопоставить только немаркированный трафик на главном интерфейсе, например

iptables -A INPUT -i eth0 -p tcp -m tcp --dport 53 -j ACCEPT

Наша цель - сопоставить пакеты TCP-порта 53 (DNS), поступающие на eth0 без тега VLAN, что мы и делаем, но мы также сопоставляем пакеты с любым другим тегом VLAN, поступающим на eth0.

Таким образом, возможным обходным решением было бы включить IP-адрес / подсеть главного интерфейса в правило. Предположим, мы используем 10.0.0.0/24 на eth0 и 10.0.1.0/24 на eth0.1:

iptables -A INPUT -i eth0 -d 10.0.0.0/24 -p tcp -m tcp --dport 53 -j ACCEPT

К сожалению, у этого есть два недостатка:

  1. Мы также сопоставляем пакеты с поддельным IP-адресом, ничто не мешает злонамеренным или неправильно настроенным клиентам отправлять пакеты с 10.0.0.0/24 и VLAN-ID 1. В общем, это не должно быть проблемой, потому что ответы на этот пакет пойдут по другому маршруту. и не дойдет до оригинала
  2. Не работает с широковещательным трафиком, например DHCP например, при котором не используется IP-адрес интерфейса.

Особенно меня беспокоит последняя проблема. Например, следующее имеет нежелательные побочные эффекты:

iptables -A INPUT -i eth0 -p udp -m udp --dport 67 -j ACCEPT

Это правило будет соответствовать любому входящему трафику DHCP на eth0, независимо от того, какой тег VLAN имеет пакет. Если мы хотим исключить трафик DHCP с VLAN-ID 1, мы потерялись.

Какие-либо предложения?

Я не думаю, что ваша проблема в iptables. У меня есть несколько устройств, действующих как маршрутизаторы между VLAN, и я сопоставляю немаркированный трафик, как вы объяснили, вы пытаетесь обойтись без каких-либо проблем.

Я только что протестировал, я могу DROP весь трафик на немаркированном интерфейсе, не затрагивая трафик помеченного интерфейса:

# iptables -A FORWARD -i eth0 -j DROP
# ping -nc3 192.168.100.129
PING 192.168.100.129 (192.168.100.129) 56(84) bytes of data.
64 bytes from 192.168.100.129: icmp_seq=1 ttl=64 time=0.180 ms
64 bytes from 192.168.100.129: icmp_seq=2 ttl=64 time=0.176 ms
64 bytes from 192.168.100.129: icmp_seq=3 ttl=64 time=0.153 ms

--- 192.168.100.129 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 0.153/0.169/0.180/0.019 ms

(192.168.100.129 существует в VLAN 10 / eth0.10)

Думаю, в вашей конфигурации либо ошибка, либо где-то ошибка.

iptables работает на слишком высоком уровне в сетевом стеке, чтобы правильно смотреть на vlan, я действительно удивлен, что -i eth0.1 работает :)

Посмотри на ebtables, который работает с кадрами Ethernet и может либо выполнять фильтрацию, либо устанавливать метки, которые будут использоваться iptables.

Что-то вроде этого непроверенного фрагмента должно помочь вам начать:

ebtables -A INPUT --vlan-id ! 1 --jump mark --mark-set 0xff
iptables -A INPUT -i eth0 -p udp -m udp --dport 67 -m mark ! --mark 0xff -j ACCEPT

Я считаю, что вам следует использовать физический интерфейс только как физический уровень. Вы не назначаете этому интерфейсу никакого IP-адреса, но вместо этого вы создаете виртуальные интерфейсы, привязанные к eth0 который позаботится об IP-транспорте.