Início / server / Perguntas / 1166077
Accepted
Ivashka
Asked: 2024-10-03 18:17:03 +0800 CST

Problemas de nat do Iptables com physdev

  • 772

Estou tentando entender o módulo physdev iptables, e estou tendo problemas com a tabela nat, especialmente com a cadeia POSTROUTING. Então meu objetivo é fazer SNAT no tráfego de saída na interface bridge usando o módulo physdev.

Aqui está minha mini configuração de rede: PC1 - (enp6s0f0)BRIDGE(enp6s0f1) - PC2 . PC1 é 192.168.100.1/24 e PC2 é 192.168.100.2/24.

Minha configuração de ponte é:

ifconfig enp6s0f0 down
ifconfig enp6s0f1 down
brctl addbr br0
brctl addif enp6s0f0 br0
brctl addif enp6s0f1 br0
ifconfig enp6s0f0 0.0.0.0 up
ifconfig enp6s0f1 0.0.0.0 up
ifconfig br0 169.254.100.1/32 up

essa configuração de ponte funciona bem e o PC1 e o PC2 podem se comunicar entre si e não com a ponte, como esperado.

Agora, por exemplo, quero configurar a comunicação entre os PCs e a BRIDGE de tal forma que o PC1 veja a BRIDGE como 192.168.100.100 e o PC2 veja a BRIDGE como 192.168.100.200.

Então adiciono a rota:

route add -net 192.168.100.0/24 dev br0

e agora se eu fizer ping da BRIDGE para qualquer um dos PCs, posso ver o tráfego de saída da bridge com o IP de origem 169.254.100.1, conforme esperado.

Agora é tudo sobre iptables. Minhas regras:

iptables -t nat -A POSTROUTING -s 169.254.100.1 -m physdev --physdev-out enp6s0f0 -j SNAT --to-source 192.168.100.100
iptables -t nat -A POSTROUTING -s 169.254.100.1 -m physdev --physdev-out enp6s0f1 -j SNAT --to-source 192.168.100.200

Depois disso, espero que todo o tráfego de saída da ponte seja SNATed para 192.168.100.100 ou 192.168.100.200 dependendo do physdev-out, MAS isso não acontece. Por quê? Não sei. O que acontece é que as regras são ignoradas. iptables -t nat -vnL mostra que 0 pacotes correspondem à regra e tcpdump -i enp6s0f0 -p arp -n mostra que todas as solicitações arp têm o antigo endereço IP de origem 169.254.100.1.

Também é importante observar que tenho o módulo br-netfilter carregado e o bridge-nf-call-iptables definido como 1.

O sistema operacional que estou usando é o Ubuntu 20.04, mas tentei outros também. Também procurei informações na Internet e sei que há várias outras maneiras de obter o comportamento que desejo, mas quero descobrir por que esse método em particular não funciona.

Também dei uma olhada em https://ebtables.netfilter.org/br_fw_ia/br_fw_ia.html e depois de ler tenho a sensação de que tudo deve funcionar. Por favor me ajude

iptables

1 respostas

  1. Best Answer

    AFAICT, --physdev-outsó pode ser usado tráfegos de correspondência que são "bridged", ou seja, tráfegos que são originados de outro host e entraram na bridge por uma porta de bridge. Tráfegos originados do próprio "host de bridge" e aqueles de outro host, mas estão sendo encaminhados por L3 (ou seja, aqueles que entraram no "host de bridge" de alguma interface e estão saindo pela interface de bridge ), não são considerados "tráfegos em bridge". ( Parece-me que é algum tipo de limitação técnica ou falha de design , em vez de um bug . Você pode ver na página do manual que a INPUTcadeia é mencionada para --physdev-in, enquanto a OUTPUTcadeia não é mencionada para --physdev-out.)

    Não tenho certeza do que exatamente você está tentando fazer aqui, já que normalmente faz pouco ou nenhum sentido ter endereços diferentes em um host para a mesma rede à qual ele se conecta, especialmente quando você está usando uma sub-rede IP e tentando alavancar o NAT de origem para seu objetivo. No entanto, para atingir o que você aparentemente quer, a melhor/única maneira que eu poderia pensar é alavancar netns e um par veth. (Cada netns é considerado uma rede host em termos de rede.)

    Não tenho certeza se mover interfaces ethernet físicas para um novo netns é sempre possível, mas supondo que seja, você pode criar um netns e criar a ponte dentro dele, então mover as interfaces ethernet que você quer fazer portas/escravas de ponte para o netns e definir seu mestre lá. Finalmente, crie um "par" veth e mova uma "extremidade" do "par" (por exemplo, o peer) para o netns e escravize-o para a ponte também. Em vez de configurar o endereço IP e as rotas na ponte, configure-os na "extremidade" do "par" veth que está no netns "padrão" (ou seja, a "extremidade" que não é uma porta/escrava de ponte).

    Obviamente, a regra SNAT deve ser adicionada ao iptables das netns onde a bridge reside.

    Veja também ip-link(8)e ip-netns(8).

    • 0

relate perguntas