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

昨天我在这里发了一个问题,但是我觉得还不够清楚。 顺便说一句,这个问题不是重复的。

我有AWS VPC安装如下。

在这里输入图像描述

目标/问题 :从互联网SSH到服务器A. 它不工作。

服务器A是在私人子网,因此我想启用在我的NAT实例上的iptables NATing,以便我可以ssh到SErver 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安全组configuration良好,以允许此testing用例需要各种访问。

故障排除:

我可以通过端口22从NAT telnet到服务器A.所以Access是好的。

当我在我的笔记本电脑上运行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,我没有看到任何来自NAT的内部/私有IP地址10.0.0.54我认为这是问题 ):

 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实例telnet到服务器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上创build一个新的问题,询问使用上述两个命令有哪些优缺点。

    • 确保你的nat盒子的安全组的0.0.0.0/0是允许TCP端口2222 inboud
    • 确保你的VPC“路由表”设置正确。
    • 至less有两个独立的表(一个与私有子网关联,一个与公有子网关联)
    • 您的10.0.1.0 (私有)子网应该有一个路由表规则,如:目标: 0.0.0.0/0 ,目标:“Nat框”
    • 您的10.0.0.0 (公共)子网应具有如下路由表规则:目标: 0.0.0.0/0 ,目标:“Internet网关”
    • 确保在你的NAT盒子的网卡上禁用了源/目的地检查,没有它,没有NAT的乐趣。 (我知道你已经有了这个,但它真的很重要,所以包括一些未来的观众)

    • 确保出站数据包知道去哪里:

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

    • 确保2222 inboud数据包正确重新路由:

      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工作iptables -t nat -A POSTROUTING -j MASQUERADE

    那么我发现上述语句的答案是允许NAT盒子将“LAPTOP”IP地址转换为“10.0.04”,同时将目标地址转换为10.0.1.243。 这时私人子网是来自NAT设备的ssh请求。 这个命令实际上降低了私有子网服务器的安全性。 build议使用下面的命令通过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