iptables: corresponde apenas ao tráfego não marcado em uma interface com VLANs

4

Até onde sei, não há como distinguir o tráfego da VLAN em iptables na interface principal (que é a interface à qual as interfaces da VLAN virtual são adicionadas com vconfig ou ip link add link; não sei se esse é o termo correto, eu encorajo você a me corrigir).

Em geral, isso não é problema, pois você pode fazer a correspondência usando a interface VLAN virtual em vez da interface principal, por exemplo,

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

Isso permitirá que os pacotes da porta TCP 22 (SSH) cheguem em eth0.1 , que são pacotes que chegam em eth0 marcados com VLAN-ID 1.

Surgem problemas quando você deseja corresponder apenas ao tráfego não marcado na interface principal, por exemplo,

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

Nossa intenção é combinar os pacotes TCP 53 (DNS) que chegam na eth0 sem uma tag VLAN, o que fazemos, mas também combinamos pacotes com qualquer outra tag VLAN chegando em eth0 .

Portanto, uma possível solução alternativa seria incluir o endereço IP / sub-rede da interface principal na regra. Vamos supor que estamos usando 10.0.0.0/24 em eth0 e 10.0.1.0/24 em eth0.1 :

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

Infelizmente, isso tem dois inconvenientes:

  1. Também estamos combinando pacotes com endereço IP falso, nada impede que clientes mal-intencionados ou mal configurados enviem pacotes com 10.0.0.0/24 e VLAN-ID 1. Em geral, isso não deve ser um problema, porque as respostas a esse pacote serão outro caminho de volta e não vai chegar ao original
  2. Ele não funciona com tráfego de transmissão, como DHCP , por exemplo, que não usa o endereço IP da interface.

Especialmente o último problema me incomoda. Por exemplo, o seguinte tem efeitos colaterais indesejados:

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

Esta regra corresponderá a qualquer tráfego DHCP recebido em eth0, independentemente de qual tag VLAN um pacote tenha. Se quisermos excluir o tráfego DHCP com VLAN-ID 1, estamos perdidos.

Alguma sugestão?

    
por Sebastian Schrader 04.05.2013 / 21:26

3 respostas

2

Eu não acho que o seu problema seja iptables. Eu tenho várias caixas atuando como roteadores entre VLAN e eu correspondi ao tráfego não marcado como você explicou que está tentando fazer sem problemas.

Acabei de testar, posso DROP todo o tráfego na interface não marcada sem afetar o tráfego da interface marcada:

# 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 existe na VLAN 10 / eth0.10)

Acho que há um erro em sua configuração ou um bug em algum lugar.

    
por 10.05.2013 / 02:42
1

iptables funciona em uma camada muito alta na pilha de rede para observar corretamente as vlans, estou realmente surpreso que -i eth0.1 funcione:)

Dê uma olhada em ebtables , que funciona em quadros Ethernet e pode fazer a própria filtragem ou definir marcas a serem usadas pelo iptables.

Algo como este snippet não testado deve começar:

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
    
por 06.05.2013 / 21:56
0

Acho que você deve usar a interface física apenas como uma camada física. Você não atribui nenhum endereço IP a essa interface, mas cria interfaces virtuais limitadas a eth0 , que cuidará do transporte IP.

    
por 04.05.2013 / 22:33

Tags