AWS VPC + IPtables + NAT: การส่งต่อพอร์ตไม่ทำงาน

เมื่อวานนี้ฉันโพสต์คำถามที่นี่แต่ฉันคิดว่าไม่ชัดเจนเพียงพอในคำพูดของฉัน BTW คำถามนี้ไม่ซ้ำกัน

ฉันมีการติดตั้ง AWS VPC ดังนี้

เป้าหมาย / ปัญหา : SSH ไปยังเซิร์ฟเวอร์ A จากอินเทอร์เน็ต และมันไม่ทำงาน

เซิร์ฟเวอร์ A อยู่ในซับเน็ตส่วนตัวและด้วยเหตุนี้ฉันต้องการเปิดใช้งาน iptables NATing บนอินสแตนซ์ NAT ของฉันเพื่อที่ฉันจะสามารถ ssh ไปยัง SErver A ได้โดยตรงจากอินเทอร์เน็ต

ฉันกำลังติดตามสิ่งนี้และสิ่งนี้

ฉันรันคำสั่งด้านล่างในตัวอย่าง NAT:

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

การส่งต่อ IP ถูกเปิดใช้งานบนอินสแตนซ์ NAT:

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 ได้รับการปรับแต่งเพื่อให้สามารถใช้งานได้หลากหลายสำหรับกรณีทดสอบนี้

การแก้ไขปัญหา:

ฉันสามารถเทลเน็ตจาก NAT ไปยังเซิร์ฟเวอร์ A บนพอร์ต 22 ได้ดังนั้นการเข้าถึงก็ดี

เมื่อฉันใช้งานtelnet 54.213.116.251 2222แล็ปท็อปฉันเห็นรายการด้านล่างใน tcpdump บน NAT:

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เป็นเส้นทางที่จะแพ็คเก็ต (BTW xxx.xxx.xxx.xxxเป็นที่อยู่ IP สาธารณะของแล็ปท็อปของฉัน)

แต่เมื่อฉันรัน tcpdump บนเซิร์ฟเวอร์ A ฉันไม่เห็นสิ่งใดที่มาจาก10.0.0.54ที่อยู่ IP ภายใน / ส่วนตัวของ NAT ( และฉันคิดว่านี่เป็นปัญหา ):

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 ฉันเห็นสิ่งดีๆใน tcpdump บนเซิร์ฟเวอร์ A ( ซึ่งหมายความว่า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

สรุป:

จากเอาต์พุต tcpdump บน NAT ดูเหมือนว่า Iptables กำลังส่งต่อแพ็กเก็ตของฉันได้ดี

จากการถ่ายโอนข้อมูล TCP บนเซิร์ฟเวอร์ A ฉันมีการเชื่อมต่อที่ดีจาก NAT ไปยังเซิร์ฟเวอร์ A

แต่ใน End-to-end ฉันไม่สามารถเชื่อมต่อกับเซิร์ฟเวอร์ A จากแล็ปท็อปของฉันได้

( BTW ฉันรู้อุโมงค์ 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 ถามว่าข้อดีและข้อเสียในการใช้สองคำสั่งข้างต้นคืออะไร

• ตรวจสอบให้แน่ใจว่าคุณจะช่วยให้พอร์ต TCP 2222Inboud จาก0.0.0.0/0กลุ่มรักษาความปลอดภัยสำหรับกล่อง NAT ของคุณ
• ตรวจสอบให้แน่ใจว่าคุณตั้งค่า "ตารางเส้นทาง" ของ VPC อย่างถูกต้อง
• อย่างน้อยสองตารางที่แยกจากกัน (หนึ่งที่เกี่ยวข้องกับเครือข่ายย่อยส่วนตัวหนึ่งที่เกี่ยวข้องกับเครือข่ายสาธารณะย่อย)
• 10.0.1.0เครือข่ายย่อย (ส่วนตัว) ของคุณควรมีกฎตารางเส้นทางเช่น: ปลายทาง: 0.0.0.0/0, เป้าหมาย: "กล่อง Nat"
• 10.0.0.0ซับเน็ตของคุณ(สาธารณะ) ควรมีกฎตารางเส้นทางเช่น: ปลายทาง: 0.0.0.0/0, เป้าหมาย: "เกตเวย์อินเทอร์เน็ต"

• ตรวจสอบให้แน่ใจว่าคุณได้ปิดใช้งานการตรวจสอบแหล่งที่มา / ปลายทางบน NIC สำหรับกล่อง NAT ของคุณไม่สนุกโดยไม่มี NAT (ฉันรู้ว่าคุณมีสิ่งนี้อยู่แล้ว แต่มันมีความสำคัญจริงๆ

• ตรวจสอบให้แน่ใจว่าแพ็คเก็ตขาออกทราบว่าจะไปที่ไหน:

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

• ตรวจสอบให้แน่ใจว่าแพ็กเก็ต inboud ทำการ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 ไปยังแหล่ง NAT 'LAPTOP' IP เป็น '10 .0.0.54 'ในขณะเดียวกันกับที่ทำ NAT ปลายทางเป็น 10.0.1.243 ในตอนนี้กล่อง subnet ส่วนตัวเป็นการร้องขอ ssh ที่มาจากอุปกรณ์ NAT เท่านั้น คำสั่งนี้ลดความปลอดภัยของเซิร์ฟเวอร์ซับเน็ตส่วนตัว ขอแนะนำให้ใช้คำสั่งด้านล่างเพื่อปรับการเข้าถึงซับเน็ตส่วนตัวผ่านกล่อง 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