Que tal
iptables -t nat -A PREROUTING -p 41 -s 72.52.104.74 -j DNAT --to 10.1.0.3
iptables -t nat -A POSTROUTING -j MASQUERADE
Estou tentando encaminhar o protocolo 41 (ipv6-in-ipv4) para um túnel HE através de um WRT54G executando o Tomato 1.28. O Tomato 1.28 está executando um kernel 2.4 que não sabe absolutamente nada sobre o protocolo 41, exceto que ele é chamado de "ipv6". Ter um kernel 2.4 também parece significar que o conntrack não pode simplesmente ser desativado: não há regras "raw" do iptables.
Eu posso configurar regras para que os pacotes recebidos sejam enviados para o host interno correto. Se o host remoto envia algo sobre o túnel primeiro, tudo funciona bem. Os pacotes podem fluir pelo túnel em ambas as direções com o NAT adequado e eu recebo uma entrada /proc/net/ip_conntrack assim:
unknown 41 599 src=72.52.104.74 dst=67.180.229.14 src=10.1.0.3 dst=72.52.104.74 use=1 mark=0
A entrada diz que é para o protocolo desconhecido 41, tem um tempo limite de 599 segundos a mais se não houver mais tráfego recebido e tem um par de endereços de origem e destino no lado inicial (que é o lado da WAN) e outro em o lado de recepção (que é o lado da LAN).
Mas se meu sistema tentar enviar um pacote pelo túnel primeiro, o endereço de origem não será traduzido para o endereço do roteador como deveria, e eu recebo uma entrada conntrack assim:
unknown 41 589 src=10.1.0.3 dst=72.52.104.74 [UNREPLIED] src=72.52.104.74 dst=10.1.0.3 use=1 mark=0
Desde que minha máquina continue tentando usar o encapsulamento, ela mantém viva essa falsa entrada de conexão, e eu posso ver os pacotes deixando meu roteador para o modem a cabo com o endereço de origem interno ainda conectado, fazendo com que eles caiam e nunca chegue onde eles estão indo.
Para fazer meu túnel aparecer, eu tenho que derrubar a interface do túnel no meu final, usar a ferramenta de ping HE para induzir algum tráfego IPv6 a descer pelo pipe e, enquanto o tempo limite de 10 minutos ainda estiver ativo na entrada conntrack correta, traga o fim do túnel novamente - e então garanta que ele nunca fique ocioso por 10 minutos em um trecho. Eu posso fazer isso, mas é muito estúpido.
Neste momento, tenho minhas regras de encaminhamento configuradas assim:
# Send incoming ipv6-in-ipv4 packets to the correct host
iptables -t nat -A PREROUTING -p 41 -s 72.52.104.74 -j DNAT --to 10.1.0.3
# Allow those packets through the firewall
iptables -I FORWARD -p 41 -d 10.1.0.3 -j ACCEPT
# Things I have added to try and solve my problem, which didn't work:
# Remove the default masquerade-everything rule
iptables -t nat -D POSTROUTING 10
# Masquerade only protocols other than 41. Conntrack still gets its bogus entries,
# and if I get the correct entry in it still works.
iptables -t nat -A POSTROUTING -p ! 41 -j MASQUERADE
Eu também tentei criar uma regra SNAT assim:
iptables -t nat -I POSTROUTING -p 41 -s 10.1.0.3 -j SNAT --to 67.180.229.14
Mas até onde eu sabia, isso também não ajudou.
Então, minha pergunta é:
1) Alguém já recebeu o protocolo 41 para avançar em um WRT54G executando Tomato com sucesso? Em caso afirmativo, que regras especiais de firewall você usou?
2) Por que o roteador acha que não precisa fazer tradução de endereço de origem no protocolo de saída 41?
Que tal
iptables -t nat -A PREROUTING -p 41 -s 72.52.104.74 -j DNAT --to 10.1.0.3
iptables -t nat -A POSTROUTING -j MASQUERADE