Encaminhamento de tráfego entre VLANs com iptables

Question

Temos as 4 VLANs a seguir na minha rede, conectadas a uma caixa do Ubuntu Linux com DHCP. Este Linux também deve funcionar como o roteador L3.

VLAN 10  on interface eth1.10  with subnet 10.10.10.0/24
VLAN 20  on interface eth1.20  with subnet 10.10.20.0/24
VLAN 50  on interface eth1.50  with subnet 10.10.50.0/24
VLAN 100 on interface eth1.100 with subnet 10.10.100.0/24

Aqui está o /etc/network/interfaces :

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
        address 192.168.10.169
        netmask 255.255.255.0
        gateway 192.168.10.1

auto eth1
iface eth1 inet static
        address 10.10.0.1
        network 10.10.0.0
        netmask 255.255.255.0
        broadcast 10.10.0.255

auto eth1.100
iface eth1.100 inet static
        address 10.10.100.1
        network 10.10.100.0
        netmask 255.255.255.0
        broadcast 10.10.100.255

auto eth1.10
iface eth1.10 inet static
        address 10.10.10.1
        network 10.10.10.0
        netmask 255.255.255.0
        broadcast 10.10.10.255

auto eth1.20
iface eth1.20 inet static
        address 10.10.20.1
        network 10.10.20.0
        netmask 255.255.255.0
        broadcast 10.10.20.255

auto eth1.50
iface eth1.50 inet static
        address 10.10.50.1
        network 10.10.50.0
        netmask 255.255.255.0
        broadcast 10.10.50.255

Agora, todos os clientes de todas as VLANs devem poder se conectar à Internet pública através da interface eth0 . Essa parte realmente funciona com a regra iptables -A POSTROUTING -o eth0 -j MASQUERADE . O servidor DHCP também está funcionando.

MAS já que a VLAN 100 será a rede para computadores de administração, os clientes da VLAN 100 devem poder acessar todos os outros computadores nas VLANs 10, 20 e 50. E os clientes nas VLANs 10, 20 e 50 só devem poder acessar computadores dentro de suas próprias VLANs.

Eu tentei até agora as seguintes regras iptables juntamente com o MASQUERADE :

-A FORWARD -i eth1.100 -o eth1.10 -j ACCEPT
-A FORWARD -i eth1.100 -o eth1.20 -j ACCEPT
-A FORWARD -i eth1.100 -o eth1.50 -j ACCEPT
-A FORWARD -i eth1.10 -o eth1.100 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth1.20 -o eth1.100 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth1.50 -o eth1.100 -m state --state RELATED,ESTABLISHED -j ACCEPT

Tentei fazer ping em um PC com o endereço IP 10.10.20.100 de um PC com endereço IP 10.10.100.101, mas ele não foi bem-sucedido. Também não consegui fazer o ping de 10.10.50.101 da sub-rede de 100.

AND há um comportamento lateral estranho: A VLAN 20 é por acidente (não sei por quê) agindo como os 100 deveriam. De lá, posso fazer ping de PCs nas VLANs 10 e 100, o que não deve ser possível no final.

Eu tenho o encaminhamento IPv4 ativado no kernel e a Internet externa funciona como esperado.

Aqui está a saída completa de iptables-save :

# Generated by iptables-save v1.6.0 on Thu May 26 09:28:59 2016
*filter
:INPUT ACCEPT [7375:724156]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [3695:415474]
-A FORWARD -i eth1.100 -o eth1.10 -j ACCEPT
-A FORWARD -i eth1.100 -o eth1.20 -j ACCEPT
-A FORWARD -i eth1.100 -o eth1.50 -j ACCEPT
-A FORWARD -i eth1.10 -o eth1.100 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth1.20 -o eth1.100 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth1.50 -o eth1.100 -m state --state RELATED,ESTABLISHED -j ACCEPT
COMMIT
# Completed on Thu May 26 09:28:59 2016
# Generated by iptables-save v1.6.0 on Thu May 26 09:28:59 2016
*nat
:PREROUTING ACCEPT [32796:9980970]
:INPUT ACCEPT [142:30526]
:OUTPUT ACCEPT [1829:211124]
:POSTROUTING ACCEPT [128:29756]
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
# Completed on Thu May 26 09:28:59 2016

E a saída de route :

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.10.1    0.0.0.0         UG    0      0        0 eth0
10.10.0.0       *               255.255.255.0   U     0      0        0 eth1
10.10.10.0      *               255.255.255.0   U     0      0        0 eth1.10
10.10.20.0      *               255.255.255.0   U     0      0        0 eth1.20
10.10.50.0      *               255.255.255.0   U     0      0        0 eth1.50
10.10.100.0     *               255.255.255.0   U     0      0        0 eth1.100
link-local      *               255.255.0.0     U     1000   0        0 eth0
192.168.10.0    *               255.255.255.0   U     0      0        0 eth0

Agradecemos antecipadamente, espero que alguém descubra quais regras do iptables devo usar para conseguir o que eu quero (se esse for o problema).

EDIT:

Como o @Sanael solicitou, fiz mais alguns registros ( -A FORWARD -o eth1+ -p icmp -j LOG --log-prefix "IPTABLES FORWARD: " --log-level 7 ) e aqui estão os resultados:

Ping 10.10.20.101 - > 10.10.50.100 sucedeu com o seguinte log:

May 26 12:14:57 homeserver kernel: IPTABLES FORWARD: IN=eth1.20 OUT=eth1.50 MAC=00:0a:5e:50:7c:c1:c8:0a:a9:e5:f0:bc:08:00:45:00:00:3c SRC=10.10.20.101 DST=10.10.50.100 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=23708 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=96
May 26 12:14:57 homeserver kernel: IPTABLES FORWARD: IN=eth1.50 OUT=eth1.20 MAC=00:0a:5e:50:7c:c1:00:1e:ec:fa:d1:10:08:00:45:00:00:3c SRC=10.10.50.100 DST=10.10.20.101 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=15185 PROTO=ICMP TYPE=0 CODE=0 ID=1 SEQ=96
May 26 12:14:58 homeserver kernel: IPTABLES FORWARD: IN=eth1.20 OUT=eth1.50 MAC=00:0a:5e:50:7c:c1:c8:0a:a9:e5:f0:bc:08:00:45:00:00:3c SRC=10.10.20.101 DST=10.10.50.100 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=23709 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=97
May 26 12:14:58 homeserver kernel: IPTABLES FORWARD: IN=eth1.50 OUT=eth1.20 MAC=00:0a:5e:50:7c:c1:00:1e:ec:fa:d1:10:08:00:45:00:00:3c SRC=10.10.50.100 DST=10.10.20.101 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=15317 PROTO=ICMP TYPE=0 CODE=0 ID=1 SEQ=97
May 26 12:14:59 homeserver kernel: IPTABLES FORWARD: IN=eth1.20 OUT=eth1.50 MAC=00:0a:5e:50:7c:c1:c8:0a:a9:e5:f0:bc:08:00:45:00:00:3c SRC=10.10.20.101 DST=10.10.50.100 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=23710 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=98
May 26 12:14:59 homeserver kernel: IPTABLES FORWARD: IN=eth1.50 OUT=eth1.20 MAC=00:0a:5e:50:7c:c1:00:1e:ec:fa:d1:10:08:00:45:00:00:3c SRC=10.10.50.100 DST=10.10.20.101 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=15349 PROTO=ICMP TYPE=0 CODE=0 ID=1 SEQ=98
May 26 12:15:00 homeserver kernel: IPTABLES FORWARD: IN=eth1.20 OUT=eth1.50 MAC=00:0a:5e:50:7c:c1:c8:0a:a9:e5:f0:bc:08:00:45:00:00:3c SRC=10.10.20.101 DST=10.10.50.100 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=23711 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=99
May 26 12:15:00 homeserver kernel: IPTABLES FORWARD: IN=eth1.50 OUT=eth1.20 MAC=00:0a:5e:50:7c:c1:00:1e:ec:fa:d1:10:08:00:45:00:00:3c SRC=10.10.50.100 DST=10.10.20.101 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=15597 PROTO=ICMP TYPE=0 CODE=0 ID=1 SEQ=99

Ping 10.10.20.101 - > 10.10.100.100 falhou com o seguinte log:

May 26 12:09:06 homeserver kernel: IPTABLES FORWARD: IN=eth1.20 OUT=eth1.100 MAC=00:0a:5e:50:7c:c1:c8:0a:a9:e5:f0:bc:08:00:45:00:00:3c SRC=10.10.20.101 DST=10.10.100.100 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=18715 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=85
May 26 12:09:11 homeserver kernel: IPTABLES FORWARD: IN=eth1.20 OUT=eth1.100 MAC=00:0a:5e:50:7c:c1:c8:0a:a9:e5:f0:bc:08:00:45:00:00:3c SRC=10.10.20.101 DST=10.10.100.100 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=18716 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=86
May 26 12:09:16 homeserver kernel: IPTABLES FORWARD: IN=eth1.20 OUT=eth1.100 MAC=00:0a:5e:50:7c:c1:c8:0a:a9:e5:f0:bc:08:00:45:00:00:3c SRC=10.10.20.101 DST=10.10.100.100 LEN=60 TOS=0x00 PREC=0x00 TTL=127 ID=18717 PROTO=ICMP TYPE=8 CODE=0 ID=1 SEQ=87

Ping 10.10.50.100 - > 10.10.20.101 falhou com o seguinte log:

May 26 12:11:28 homeserver kernel: IPTABLES FORWARD: IN=eth1.50 OUT=eth1.20 MAC=00:0a:5e:50:7c:c1:00:1e:ec:fa:d1:10:08:00:45:00:00:54 SRC=10.10.50.100 DST=10.10.20.101 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=54378 DF PROTO=ICMP TYPE=8 CODE=0 ID=1903 SEQ=1
May 26 12:11:29 homeserver kernel: IPTABLES FORWARD: IN=eth1.50 OUT=eth1.20 MAC=00:0a:5e:50:7c:c1:00:1e:ec:fa:d1:10:08:00:45:00:00:54 SRC=10.10.50.100 DST=10.10.20.101 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=54495 DF PROTO=ICMP TYPE=8 CODE=0 ID=1903 SEQ=2
May 26 12:11:30 homeserver kernel: IPTABLES FORWARD: IN=eth1.50 OUT=eth1.20 MAC=00:0a:5e:50:7c:c1:00:1e:ec:fa:d1:10:08:00:45:00:00:54 SRC=10.10.50.100 DST=10.10.20.101 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=54693 DF PROTO=ICMP TYPE=8 CODE=0 ID=1903 SEQ=3

Ping 10.10.50.100 - > 10.10.100.100 falhou com o seguinte log:

May 26 12:12:24 homeserver kernel: IPTABLES FORWARD: IN=eth1.50 OUT=eth1.100 MAC=00:0a:5e:50:7c:c1:00:1e:ec:fa:d1:10:08:00:45:00:00:54 SRC=10.10.50.100 DST=10.10.100.100 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=8069 DF PROTO=ICMP TYPE=8 CODE=0 ID=1905 SEQ=1
May 26 12:12:25 homeserver kernel: IPTABLES FORWARD: IN=eth1.50 OUT=eth1.100 MAC=00:0a:5e:50:7c:c1:00:1e:ec:fa:d1:10:08:00:45:00:00:54 SRC=10.10.50.100 DST=10.10.100.100 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=8269 DF PROTO=ICMP TYPE=8 CODE=0 ID=1905 SEQ=2
May 26 12:12:26 homeserver kernel: IPTABLES FORWARD: IN=eth1.50 OUT=eth1.100 MAC=00:0a:5e:50:7c:c1:00:1e:ec:fa:d1:10:08:00:45:00:00:54 SRC=10.10.50.100 DST=10.10.100.100 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=8375 DF PROTO=ICMP TYPE=8 CODE=0 ID=1905 SEQ=3

Ping 10.10.100.100 - > 10.10.20.101 failed MAS não criou nenhuma saída de log.

Ping 10.10.100.100 - > 10.10.50.100 bem sucedido MAS não criou nenhuma saída de log.

    

Answer 1

O problema agora está pelo menos parcialmente resolvido (estou bem com isso).

Eu estava testando a rede com clientes Windows no começo, e os dois PCs tinham a atualização do Windows 10 ultimamente. O problema em si foi realmente estúpido: o Windows não respondeu aos pings, pois há uma nova segurança ativada por padrão no Windows 10. Quando adicionei um laptop Linux à rede, cheguei a uma situação em que todos os outros podiam fazer ping no laptop Linux ( a política padrão era ALLOW ), mas o Linux não conseguia pingar mais nada (o Windows não respondeu ao ping). Então eu tentei o desktop remoto para os PCs com Windows nas VLANs 10 e 50, do Linux PC na VLAN 100 e boom - funcionou!

Portanto, não houve nenhum problema com as regras do iptables / netfilter.

Muito obrigado por todas as respostas e comentários!

Aqui está minha configuração final, funcional e simplificada do iptables:

# Generated by iptables-save v1.6.0 on Thu May 26 16:00:55 2016
*filter
:INPUT ACCEPT [359:39449]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [563:89333]
-A FORWARD -i eth1+ -o eth1.100 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth1.100 -o eth1+ -j ACCEPT
-A FORWARD -i eth1+ -o eth0 -j ACCEPT
-A FORWARD -i eth0 -o eth1+ -m state --state RELATED,ESTABLISHED -j ACCEPT
COMMIT
# Completed on Thu May 26 16:00:55 2016
# Generated by iptables-save v1.6.0 on Thu May 26 16:00:55 2016
*nat
:PREROUTING ACCEPT [5650:1147271]
:INPUT ACCEPT [91:14019]
:OUTPUT ACCEPT [325:31088]
:POSTROUTING ACCEPT [44:7161]
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
# Completed on Thu May 26 16:00:55 2016

    

Answer 2

Primeiro, sua política padrão na cadeia FORWARD é ACCEPT, então você não está realmente negando nenhum tráfego. Isso explica porque os 20 - > 50 trabalhos de encaminhamento. Você pode corrigir isso com iptables -P FORWARD DROP .

Em relação aos outros pings, observe que em suas entradas de log, o TTL é 127 ou 63, indicando que o firewall já tomou sua decisão de roteamento e diminuiu o TTL. Além disso, o firewall não está configurado para bloquear tráfego. Isso sugere que o problema está na configuração de roteamento dos clientes. Posso sugerir que você use um sniffer no destinatário do ping para ver se o pacote de ping original está chegando? Certifique-se de que o gateway padrão para os clientes (não o firewall) em 10.10.10.0/24 seja 10.10.10.1, etc. Boa sorte!

E acompanhando o comentário na tabela de roteamento, sua tabela de roteamento está correta, indicando que seu firewall está diretamente conectado às suas redes VLAN.

    

Answer 3

eu. iptables

Você adicionou a linha de registro após suas regras existentes? Se você fez, há o que eu penso sobre o seu problema.

1. -j ACCEPT termina o caminho do pacote na regra. Então, uma linha de registro significa que suas 6 regras não coincidem.
2. As políticas padrão FORWARD são ACCEPT, portanto, os pacotes são aceitos de qualquer maneira quando atingem o final da cadeia FORWARD. Você deve alterar este beahvior adicionando iptables -P FORWARD DROP .
3. Ver registros significa que o pacote seria descartado se você tivesse as políticas padrão corretas. Os 4 pings registrados são de não-100 vlan, que é o comportamento esperado.
4. Não ver log significa que o pacote corresponde a uma regra e foi aceito. Os dois pings são da vlan 100 e correspondem a uma regra, que é mais uma vez o comportamento esperado.

Podemos ver que iptables estão fazendo seu trabalho, você só precisa altere a política padrão.

II. Roteamento

Agora você precisa entender de onde vem o problema. Pode ser o roteamento, por exemplo. Como a política padrão FORWARD é ACCEPT (você pode mantê-la até descobrir a causa raiz do problema), cada ping deve ter sido bem-sucedido. Vamos ver quem não tem:
20 a 100, 50 a 20, 50 a 100, 100 a 20.

Nos logs, podemos verificar o MAC para saber se o roteamento está correto. O formato é <MAC dest (6 bytes)><MAC source (6 bytes)><08:00 & sometimes IP header> .
Os logs que temos são antes do roteamento, então temos <eth1 mac><sender mac><not interesting> .
O que queremos é <receiver mac><eth1 mac><not interesting> , então podemos ver se o pacote é enviado para o lugar certo.
Para fazer isso, poderíamos definir a regra de log na cadeia POSTROUTING:

-A POSTROUTING -o eth1+ -p icmp -j LOG --log-prefix "IPTABLES POSTROUTING: " --log-level 7

O que sabemos no momento é:

• 10.10.20.101: c8: 0a: a9: e5: f0: bc
• 10.10.50.100: 00: 1e: ec: fa: d1: 10
• eth1: 00: 0a: 5e: 50: 7c: c1

Também precisamos conhecer o MAC para 10.10.10.100.
By the way, se você tiver apenas 4 vlans, tente os 12 pings que você pode fazer para fornecer informações suficientes para depurar.
Você pode tentar o 8 ping de (e para) interfaces de roteador? (por exemplo, no roteador: ping -I eth1.100 10.10.100.100 )

III. Causas de terceiros

Verifique novamente o seu Cisco conf (e abra outra pergunta se tiver quase certeza de que o problema é a causa raiz), verifique se cada vlan tem acesso à Internet.

Edit: Eu estou escrevendo muito devagar. Bem feito!