CentOS iptables MASQUERADE 对某些数据包不起作用?

CentOS iptables MASQUERADE 对某些数据包不起作用?

有点奇怪的是,一些数据包在离开 bwgla 接口时,它不会将源 IP 转换为该接口(10.0.12.102),为了显示这一点,请检查以下内容:

这是从 bwgla 接口捕获的数据包,如你所见,所有数据包要么来自 10.0.12.102,要么发送到 10.0.2.102,这是 bwgla 接口的 IP,这就是 MASQUERADE 的工作方式。

[root@box2 ~]# tcpdump -i bwgla -nn
tcpdump:抑制详细输出,使用 -v 或 -vv 进行完整协议解码
监听 bwgla,链接类型为 RAW(原始 IP),捕获大小为 262144 字节
14:37:44.186195 IP 10.0.12.102.19201 > 54.191.53.147.443:标志 [P.],序列号 2178927353:2178927388,ack 90788915,win 16360,长度 35
14:37:44.191087 IP 10.0.12.102.52741 > 216.239.32.116.443:标志 [S],序列 2086226093,win 8192,选项 [mss 1386,nop,nop,nop,nop,nop,nop,nop,nop],长度 0
14:37:44.242792 IP 17.252.204.160.5223 >10.0.12.102.61294:标志 [S.],seq 1671923054,ack 3897542686,win 28960,选项 [mss 1413,sackOK,TS val 3471677459 ecr 685711526,nop,wscale 7],长度 0
14:37:44.342166 IP 17.252.204.93.5223 >10.0.12.102.61292:标志 [S.],seq 2114352723,ack 1911140225,win 28960,选项 [mss 1413,sackOK,TS val 3472692506 ecr 685711127,nop,wscale 7],长度 0
14:37:44.342437 IP10.0.12.102.64752 > 216.239.32.116.443: UDP,长度 1350
14:37:44.442644 IP10.0.12.102.52742 > 216.239.32.116.443:标志 [S],序列 733044423,win 8192,选项 [mss 1386,nop,nop,nop,nop,nop,nop,nop,nop],长度 0
14:37:44.449795 IP 17.252.156.200.5223 >10.0.12.102.49466:标志 [S.],seq 3018115324,ack 3319498389,win 28960,选项 [mss 1413,sackOK,TS val 2255826576 ecr 263793670,nop,wscale 7],长度 0
14:37:44.490598 IP10.0.12.102.49466 > 17.252.156.200.5223:标志 [.],ack 1,win 2061,选项 [nop,nop,TS val 263807784 ecr 2255823391],长度 0
14:37:44.518892 IP10.0.12.102> 10.0.12.2:ICMP 回显请求,id 24094,seq 294,长度 64
14:37:44.519943 IP 17.57.1​​45.102.443 >10.0.12.102.49465:标志 [S.],序列 839710413,ack 616718581,win 29200,选项 [mss 1413],长度 0
14:37:44.658272 IP 13.68.20.25.443 >10.0.12.102.60120:标志 [R],序列号 153298283,win 0,长度 0

但是我开始长距离传输到 54.239.31.91,如下所示,数据包已通过 bwgla 接口发送,但 IP 地址没有转换为 10.0.12.102

[root@box2 ~]# tcpdump -i bwgla icmp and host 54.239.31.91 -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bwgla, link-type RAW (Raw IP), capture size 262144 bytes
14:43:30.544820 IP 219.141.235.xx > 54.239.31.91: ICMP echo request, id 62464, seq 3587, length 40
14:43:35.541710 IP 219.141.235.xx > 54.239.31.91: ICMP echo request, id 62464, seq 3588, length 40
14:43:40.557410 IP 219.141.235.xx > 54.239.31.91: ICMP echo request, id 62464, seq 3589, length 40

下面是我的 iptablers POSTROUTING 的配置,非常简单,对吧?

[root@box2 ~]# iptables -t nat -L -nv 
Chain PREROUTING (policy ACCEPT 21831 packets, 1734K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 8898 packets, 636K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 6173 packets, 470K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 15815 packets, 1234K bytes)
 pkts bytes target     prot opt in     out     source               destination         
17679 1888K MASQUERADE  all  --  *      hphk    0.0.0.0/0            0.0.0.0/0           
 2938  204K MASQUERADE  all  --  *      zptled  0.0.0.0/0            0.0.0.0/0           
16110 1039K MASQUERADE  all  --  *      bwgla   0.0.0.0/0            0.0.0.0/0          

但是为什么到 54.239.31.91 的流量没有转换,是因为某种连接缓存,还是任何错误?

答案1

是的,Linux NAT 有一个连接缓存(连接跟踪),它甚至适用于“无连接”流,例如 UDP 和 ICMP。只有第一个数据包才会真正通过您的 NAT 规则 - 所有后续数据包都只会进行 conntrack 查找并应用相同的转换(如果有)。

您的 tcpdump 显示 ICMP 请求具有非常高的序列号,表明它ping已经运行了很长时间 - 可能是在您添加这些 NAT 规则之前。如果重新启动ping没有帮助,请使用conntrack工具来删除单个状态或刷新整个连接表。

conntrack -L

conntrack -F

conntrack -D -p icmp -d 54.239.31.91

请注意,完全相同连接跟踪系统用于 iptables--state--ctstate过滤规则。因此,如果您当前有通过--state ESTABLISHED或类似方式过滤的连接,则刷新 conntrack 缓存很可能会中断它们。

相关内容