我正在尝试更改ICMP回复数据包的目标IP地址。
ICMP应答从我的IPSEC隧道进入路由器（我不完全确定它为什么在tcpdump中显示两次）：
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 我尝试在PREROUTING表上将目标ip更改为本地ip（172.31.20.219）：
sudo iptables -t nat -A PREROUTING --source 54.76.131.136 --destination 35.182.188.86 -j DNAT --to-destination 172.31.20.219
所以表格看起来像这样：
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
但是，ip更改不会发生。
运用
sudo iptables -t raw -A PREROUTING --source 54.76.131.136 --destination 35.182.188.86 -j LOG
我可以看到比赛可以在原始桌上进行：
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
但是在nat表上似乎没有匹配。
任何人都可以提供build议，为什么目标IP没有改变或如何进一步debugging？ 看起来很奇怪。
我正在使用Ubuntu 16.04。 传入的stream量正在与StrongSwan进行IPSEC隧道设置。
谢谢
ICMP Echo回复数据包是build立的stream程的一部分。 这意味着，当内核在正常情况下收到这样的数据包时，它已经期待它（在最初的ICMP Echo请求之后），所以conntrack（nat所需的基本数据块）已经为它创build了期望条目。 在这种情况下，nat表将被短路，甚至不会执行这个回复数据包。
参考： https ： //www.netfilter.org/documentation/HOWTO/netfilter-hacking-HOWTO-3.html#ss3.2 （NAT）
这个表与“filter”表略有不同，因为只有新连接的第一个数据包将遍历该表：这个遍历的结果将被应用于同一连接中的所有未来数据包。
要检查此行为，请在事件监视器模式下使用conntrack命令（来自conntrack软件包）。 以下是Google对Google的一个ping的示例：
# 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
第一个数据包将创build[NEW]条目，因此将通过nat表提供改变期望的机会（在这个例子中是经典的SNAT / MASQUERADE）。 这个stream的其他数据包只能用conntrack的期望来处理，直到入口被破坏（这个icmp的30s超时）。
使用nat规则可以和最初的ICMP Ping Echo请求一起工作，因为它会是一个新的stream程。
你没有告诉你实际上想要做什么。 如果你的目标是复制数据包到172.31.20.219，你应该尝试TEE目标（man iptables-extensions）。