IPTables -j O DNAT não parece funcionar em um determinado caso

Question

Estou tentando alterar o endereço IP de destino para um pacote de resposta ICMP.

A resposta ICMP insere o roteador do meu túnel IPSEC como tal (não estou totalmente certo do porquê ele é mostrado no tcpdump duas vezes):

14:28:09.562030 IP 35.182.188.86 > 54.76.131.136: ICMP echo request, id 28997, seq 1259, length 64
14:28:09.641595 IP 54.76.131.136 > 35.182.188.86: ICMP echo reply, id 28997, seq 1259, length 64
14:28:09.641645 IP 54.76.131.136 > 35.182.188.86: ICMP echo reply, id 28997, seq 1259, length 64

Eu tento mudar o ip de destino para o ip local (172.31.20.219) na tabela PREROUTING com:

sudo iptables -t nat -A PREROUTING --source 54.76.131.136 --destination 35.182.188.86 -j DNAT --to-destination 172.31.20.219

Portanto, as tabelas são assim:

ubuntu@ip-172-31-23-13:~$ sudo iptables-save -c
# Generated by iptables-save v1.6.0 on Tue Oct  3 14:58:19 2017
*nat
:PREROUTING ACCEPT [33:2711]
:INPUT ACCEPT [32:2627]
:OUTPUT ACCEPT [8:1080]
:POSTROUTING ACCEPT [9:1164]
[0:0] -A PREROUTING -s 54.76.131.136/32 -d 35.182.188.86/32 -j DNAT --to-destination 172.31.20.219
COMMIT
# Completed on Tue Oct  3 14:58:19 2017
# Generated by iptables-save v1.6.0 on Tue Oct  3 14:58:19 2017
*raw
:PREROUTING ACCEPT [2646:283498]
:OUTPUT ACCEPT [998:168846]
[1954:164136] -A PREROUTING -s 54.76.131.136/32 -d 35.182.188.86/32 -j LOG
[821:68964] -A PREROUTING -s 54.76.131.136/32 -d 35.182.188.86/32 -j TRACE
COMMIT
# Completed on Tue Oct  3 14:58:19 2017

No entanto, a alteração ip não ocorre.

Usando

sudo iptables -t raw -A PREROUTING --source 54.76.131.136 --destination 35.182.188.86 -j LOG

Posso ver que a correspondência pode ser feita na tabela bruta:

Oct  3 14:25:20 ip-172-31-23-13 kernel: [  889.588090] IN=eth0 OUT= MAC=02:fc:a0:12:56:64:02:7f:fe:dc:a4:0d:08:00 SRC=54.76.131.135 DST=35.182.188.85 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=64700 PROTO=ICMP TYPE=0 CODE=0 ID=28997 SEQ=1091

Mas parece que não combina com a tabela nat.

Alguém pode oferecer conselhos sobre por que o ip de destino não foi alterado ou como depurar isso ainda mais? Parece muito estranho.

Estou usando o Ubuntu 16.04. O tráfego de entrada está chegando em uma configuração de túnel IPSEC com StrongSwan.

Obrigado

    

Answer 1

Um pacote de resposta do ICMP Echo faz parte de um fluxo estabelecido. Isso significa que, quando o kernel recebeu tal pacote em um caso normal, ele já estava esperando (após a requisição de eco ICMP inicial), então conntrack, o bloco base necessário para nat, já criou uma entrada de expectativa para ele. Nesse caso, a tabela nat entrará em curto-circuito e nem será executada para este pacote de resposta.

referência: link (NAT)

This table is slightly different from the 'filter' table, in that only the first packet of a new connection will traverse the table: the result of this traversal is then applied to all future packets in the same connection.

Para verificar esse comportamento, use o comando conntrack (do pacote conntrack) no modo do monitor de eventos. Aqui está um exemplo com um ping para o Google:

# conntrack -E
    [NEW] icmp     1 30 src=192.168.3.2 dst=8.8.8.8 type=8 code=0 id=12837 [UNREPLIED] src=8.8.8.8 dst=198.51.100.5 type=0 code=0 id=12837
 [UPDATE] icmp     1 30 src=192.168.3.2 dst=8.8.8.8 type=8 code=0 id=12837 src=8.8.8.8 dst=198.51.100.5 type=0 code=0 id=12837
[DESTROY] icmp     1 src=192.168.3.2 dst=8.8.8.8 type=8 code=0 id=12837 src=8.8.8.8 dst=198.51.100.5 type=0 code=0 id=12837

O primeiro pacote criará a entrada [NEW] e assim passará a tabela nat dando uma chance de alterar a expectativa (neste exemplo, um SNAT / MASQUERADE clássico). Outros pacotes deste fluxo são manipulados apenas com a expectativa de conntrack até que a entrada seja destruída (30s timeout para este icmp).

O uso de uma regra nat teria funcionado com a solicitação ICMP Ping Echo inicial, porque seria um novo fluxo.

Você não disse o que realmente quer fazer com tudo isso. Se o seu objetivo é copiar o pacote para 172.31.20.219, você deve tentar o alvo TEE (man iptables-extensions).