AWS VPC + IPtables + NAT：端口转发不起作用

昨天，我在这里发表了一个问题，但我认为我的话还不够清楚。顺便说一句，这个问题不是重复的。

我有如下的AWS VPC设置。

目标/问题：从Internet SSH到服务器A。而且它不起作用。

服务器A位于私有子网中，因此我想在NAT实例上启用iptables NAT，以便可以直接从Internet SSH到服务器A

我下面这个和这个

我在NAT实例上运行以下命令：

NAT# iptables -t nat -A PREROUTING  -p tcp --dport 2222 -j DNAT --to-destination 10.0.1.243:22

在NAT实例上启用IP转发：

NAT# sysctl  -p
net.ipv4.ip_forward = 1

MASQUERADE在NAT实例上运行：

NAT# iptables -t nat -vnL POSTROUTING
Chain POSTROUTING (policy ACCEPT 6 packets, 312 bytes)
 pkts bytes target     prot opt in     out     source               destination
  199 16466 MASQUERADE  all  --  *      eth0    10.0.0.0/16          0.0.0.0/0

可以对AWS Security组进行良好配置，以允许该测试用例进行各种访问。

故障排除：

我可以从NAT远程登录到端口22上的服务器A。因此访问是好的。

当我telnet 54.213.116.251 2222在笔记本电脑上运行时，在NAT的tcpdump中看到以下条目：

NAT# tcpdump -n -i eth0 dst 10.0.1.243 and port 22
09:59:13.738316 IP xxx.xxx.xxx.xxx.51709 > 10.0.1.243.ssh: Flags [S], seq 1868541786, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
09:59:16.737009 IP xxx.xxx.xxx.xxx.51709 > 10.0.1.243.ssh: Flags [S], seq 1868541786, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length 0
09:59:22.775567 IP xxx.xxx.xxx.xxx.51709 > 10.0.1.243.ssh: Flags [S], seq 1868541786, win 8192, options [mss 1460,nop,nop,sackOK], length 0

因此，这意味着iptables将数据包路由到10.0.1.243。（顺便说一句，xxx.xxx.xxx.xxx是我的笔记本电脑的公共IP地址）

但是，当我在服务器A上运行tcpdump时，我看不到来自10.0.0.54NAT的内部/专用IP地址的任何信息（而且我认为这是问题所在）：

Server A# tcpdump  -n src 10.0.0.54
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 

但是，如果我从NAT实例远程登录到服务器A，我会在服务器A的tcpdump中看到好东西（这意味着，我的整体PREROUTING规则未按预期工作）：

Server A# tcpdump  -n src 10.0.0.54
05:01:47.500080 IP 10.0.0.54.44627 > 10.0.1.243.ssh: Flags [S], seq 2862522431, win 14600, options [mss 1460,sackOK,TS val 3013083 ecr 0,nop,wscale 7], length 0
05:01:47.501601 IP 10.0.0.54.44627 > 10.0.1.243.ssh: Flags [.], ack 760676524, win 115, options [nop,nop,TS val 3013083 ecr 12074896], length 0
05:01:47.535720 IP 10.0.0.54.44627 > 10.0.1.243.ssh: Flags [.], ack 22, win 115, options [nop,nop,TS val 3013092 ecr 12074928], length 0

结论：

从NAT上的tcpdump输出来看，似乎Iptables很好地转发了我的数据包。

从服务器A上的TCP转储中，我从NAT到服务器A的连接良好。

但是在端到端中，我无法从笔记本电脑连接到服务器A。

（顺便说一句，我知道SSH隧道和其他好东西。但是我只希望有Iptables可以帮助我。）

最后，我破解了！

在NAT实例上，我必须更改以下命令：

从：

iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/16 -j MASQUERADE

至：

iptables -t nat -A POSTROUTING -j MASQUERADE

它的工作！！！

因此，我很快将在ServerFault上创建一个新问题，询问使用以上两个命令的优缺点。

• 确保您在nat盒的安全组上允许tcp端口2222inboud0.0.0.0/0
• 确保正确设置了VPC“路由表”。
• 至少两个单独的表（一个与私有子网关联，一个与公共子网关联）
• 您的10.0.1.0（专用）子网应具有如下路由表规则：目的地：0.0.0.0/0，目标：“ Nat box”
• 您的10.0.0.0（公共）子网应具有如下路由表规则：Destination ：0.0.0.0/0、 Target：“ Internet网关”

• 确保已在NAT框的NIC上禁用了“ 源/目标”检查，没有NATting的乐趣就没有了。（我知道您已经拥有了它，但它确实很重要，因此将其包括给将来的观看者）

• 确保出站数据包知道去向：

  iptables --table nat --append POSTROUTING --source 10.0.0.0/16 --destination 0.0.0.0/0 --jump MASQUERADE

• 确保收录包2222正确路由：

  iptables --table nat --append PREROUTING --protocol tcp --dport 2222 --jump DNAT --to-destination 10.0.1.243:22

这篇文章对我了解AWS NAT有很大帮助。因此，我开始研究是什么iptables -t nat -A POSTROUTING -j MASQUERADE使它起作用。

好吧，我发现上面的陈述的答案是允许NAT框将“ LAPTOP” IP的NAT来源发送到“ 10.0.0.54”，同时将目标NAT执行到10.0.1.243。这时，专用子网框是仅来自NAT设备的ssh请求。该命令实际上降低了专用子网服务器的安全性。建议使用以下命令来微调通过ssh和NAT框进行的私有子网访问，如下所述；

iptables --table nat --append POSTROUTING --source "INTERNET IP of the Laptop" --destination 10.0.1.243 --jump MASQUERADE

安全一点：

iptables -t nat -I PREROUTING -d 52.213.216.251 -j DNAT --to-destination 10.0.1.243:22
iptables -t nat -I POSTROUTING -s 10.0.1.243 -j SNAT --to-source 52.213.216.251