Ele pode estar bloqueado devido à filtragem de caminho inverso.
Tente desativá-lo: link
Em primeiro lugar, isso não é um problema de roteamento diário. A configuração é bastante complexa, portanto, deixe-me dizer isso antes.
Eu tenho um roteador com, vamos mantê-lo simples, 3 interfaces. eth0, eth1, eth2. eth2 é usado para pppoe. eth0 & eth1 tem os clientes.
Ok, até aí tudo bem, tudo básico .. Agora vem a coisa complicada: Eu crio um monte de interfaces macvlan em cima de eth0 e eth1, o esquema de nomes é:
g1eth0 : g1 for gate1, eth0 indicates on what physical interface its laying on
Isso eu tenho para cada uplink que eu forneço, digamos 3, 1 pppoe e 2 VPNs. Estes são então mesclados em pontes com o nome do portão.
Até agora, obtivemos essas interfaces:
<iface>:<description>
eth0 : our 1st subnet is here
eth1 : our 2nd subnet is here
eth2 : our pppoe is hooked here
ppp0 : our pppoe uplink
tap0 : our vpn1 uplink
tap1 : our vpn2 uplink
g1eth0 : advertised gate over uplink1 on clients in eth0
g1eth1 : advertised gate over uplink1 on clients in eth1
g2eth0 : advertised gate over uplink2 on clients in eth0
g3eth1 : advertised gate over uplink3 on clients in eth1
gate1 : bridge containing g1eth0 and g1eth1
gate2 : bridge containing g2eth0
gate3 : bridge containing g3eth1
Como eu disse, um monte de interfaces ... Observe que um uplink pode ser anunciado através de várias interfaces físicas, é por isso que temos as pontes.
Tudo bem, agora vamos dar uma olhada nas regras de roteamento:
32763: from all fwmark 0x3 lookup 202
32764: from all fwmark 0x2 lookup 201
32765: from all fwmark 0x1 lookup 200
Ok, isso não é tão espetacular, obviamente, ele só verifica o que o FWMARK tem um pacote e o envia para a tabela de acordo.
As tabelas de roteamento:
200:
default via 1.2.3.4 dev ppp0 src 4.3.2.1
201:
default via 5.6.7.8 dev tap0 src 8.7.6.5
202:
default via 9.10.11.12 dev tap1 src 12.11.10.9
Ok, os IPs servem apenas para preencher as lacunas, você deve estar familiarizado com a sintaxe;)
Neste momento temos as tabelas de roteamento, as regras de roteamento e as interfaces - mas estamos perdendo a marcação pkg, então isso está sendo feito no iptables:
iptables -t mangle -A PREROUTING -i gate1 -s 10.0.0.0/16 -j MARK --set-xmark 0x1/0xffffffff
iptables -t mangle -A PREROUTING -i gate2 -s 10.0.0.0/16 -j MARK --set-xmark 0x2/0xffffffff
iptables -t mangle -A PREROUTING -i gate3 -s 10.0.0.0/16 -j MARK --set-xmark 0x3/0xffffffff
Ok, para explicação, marcamos todos os pacotes que estão chegando em nossas pontes com o valor correto para as regras de roteamento.
Agora, também tive que fazer alguns ajustes em arp_announce e arp_ignore para que o MAC correto fosse anunciado para as g*eth* -interfaces. Esta postagem está ficando bastante cheia, então vou pular a descrição, ambas estão definidas para 2 .
A corrente filter:FORWARD está vazia por enquanto, apenas registra os pacotes que obtém.
Agora NAT'ing:
iptables -t nat -A POSTROUTING -s 10.0.0.0/16 -j MASQUERADE .
Todas as políticas padrão para iptables são ACCEPT .
tcpdump mostra que os pkgs de entrada são direcionados para o MAC correto de acordo com as interfaces g*eth* .
mangle:PREROUTING contadores para o incremento de regras como deveriam.
ip_forward verificado como 1 .
filter:FORWARD counters NÃO estão incrementando.
Eu tenho as regras de LOG em todas as cadeias, mas os pacotes parecem desaparecer depois que passam o mangle:PREROUTING .
Alguma ideia do porquê?
Adição I : eu coloquei uma regra TRACE em PREROUTING como o comentário me sugeriu, ironicamente ele não mostra nenhum dos pings que meus clientes estão rodando.
Adição II : Depois de algumas discussões com as regras, rastreamento, promisc ... Percebi que os dados estão chegando em ethX , mas não em gateX . Parece que o brigde-interface está apenas soltando-o, não é de admirar que o kernel não consiga fazê-lo avançar.
Por que minha interface de bridge faz isso?
bridge name bridge id STP enabled interfaces
gate1 8000.dead000200b5 no g1eth0
g1eth1
Ele pode estar bloqueado devido à filtragem de caminho inverso.
Tente desativá-lo: link