Tcpdump mostrando porta de redirecionamento diferente após adicionar a regra REDIRECT no iptables

Question

Para ser claro: o teste do OP é feito do sistema 192.168.1.100 para ele mesmo, não de um sistema remoto, e essa é a causa do problema. A porta não foi alterada neste caso porque nenhuma regra NAT correspondeu, embora teria correspondido se fosse feita a partir de um sistema remoto.

O esquema abaixo mostra como a ordem das operações é executada em um pacote:

A razão é como o NAT funciona no Linux:tabelas de ipvê um pacote na nattabela apenas para o primeiro pacote de um novo fluxo conntrack (que está, portanto, no estado NEW).

Esta regra funciona bem quando proveniente de um sistema remoto. Neste caso, o primeiro pacote visto será um pacote recebido:

to port 8000 --> AF_PACKET (tcpdump) --> conntrack --> nat/PREROUTING (iptables REDIRECT): to port 30000
--> routing decision --> ... --> local process receiving on port 30000

Todos os pacotes seguintes no mesmo fluxo terão conntrack manipulando diretamente a mudança de porta (ou reversão de porta para respostas) e pularão qualquer regra iptables na nattabela (conforme escrito no esquema: nattabela consultada apenas para NEWconexões). Então, (pulando a parte do pacote de resposta), o próximo pacote recebido passará por isso:

to port 8000 --> AF_PACKET (tcpdump) --> conntrack: to port 30000
--> routing decision --> ... --> local process receiving on port 30000

Para um teste do próprio sistema, o primeiro pacote não é um pacote de entrada, mas um pacote de saída. Em vez disso, isso acontece usando a lointerface de saída:

local process client curl --> routing decision --> conntrack --> nat/OUTPUT (no rule here)
--> reroute check --> AF_PACKET (tcpdump) --> to port 8000

E agora esse pacote é retornado na lointerface, ele reaparece como um pacote que não é mais o primeiro pacote em uma conexão, então segue o segundo caso acima: conntrack sozinho cuida do NAT e não chama nat/PREROUTING. Exceto que não foi instruído na etapa anterior para fazer nenhum NAT:

to port 8000 --> AF_PACKET (tcpdump) --> conntrack
--> routing decision --> ... -->nolocal process receiving on port8000

como não há nada escutando na porta 8000, o sistema operacional envia de volta um TCP RST.

Para que isso funcione no sistema local, uma REDIRECTregra também deve ser colocada na nat/OUTPUTcadeia:

iptables -t nat -I OUTPUT -d 192.168.1.100 -p tcp --dport 8000 -j REDIRECT --to-port 30000

Notas Adicionais

se o caso for para uso remoto, não teste no sistema local: as regras percorridas pelo teste não são as mesmas. Isso faz com que o teste não reflita a realidade.

Basta usar um namespace de rede para criar um sistema remoto de bolso caso nenhum outro sistema esteja disponível. Exemplo que deve funcionar com um sistema tendo apenas nat/PREROUTINGregras e ações do OP curl http://192.168.1.100/(que não requer DNS):
```
ip netns add remotesystem
ip link add name vethremote up type veth peer netns remotesystem name eth0
ip address add 192.0.2.1/24 dev vethremote
ip -n remotesystem address add 192.0.2.2/24 dev eth0
ip -n remotesystem link set eth0 up
ip -n remotesystem route add 192.168.1.100 via 192.0.2.1
ip netns exec remotesystem curl http://192.168.1.100:8000/
```
tcpdumpe NAT

tcpdumpacontece nas AF_PACKETetapas do esquema acima: muito cedo para entrada e muito tarde para saída. Isso significa que para um caso de sistema remoto, ele nunca capturará a porta 30000 mesmo quando estiver funcionando. Para o caso do sistema local, uma vez nat/OUTPUTadicionada a regra, ela capturará a porta 30000.

Só não confie cegamente no endereço/porta exibido ao tcpdumpfazer NAT: depende do caso e de onde acontece a captura.

Answer 1