AWS VPC + IPtables + NAT: Chuyển tiếp cổng không hoạt động

Hôm qua, tôi đã đăng một câu hỏi ở đây nhưng tôi nghĩ rằng tôi không đủ rõ ràng trong lời nói của mình. BTW, Câu hỏi này không phải là một bản sao.

Tôi có AWS VPC Setup như bên dưới.

MỤC TIÊU / VẤN ĐỀ : SSH đến Máy chủ A từ internet. Và nó không hoạt động.

Máy chủ A nằm trong mạng con riêng tư và do đó tôi muốn kích hoạt iptables NATing trên phiên bản NAT của mình để tôi có thể ssh đến SErver A trực tiếp từ internet

Tôi sau này và này

Tôi đã chạy bên dưới lệnh trên NAT dụ:

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

Chuyển tiếp IP được bật trên phiên bản NAT:

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

MASQUERADE đang chạy trên NAT dụ:

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

Các nhóm bảo mật AWS được cấu hình tốt để cho phép truy cập khác nhau cần thiết cho trường hợp thử nghiệm này.

Xử lý sự cố:

Tôi có thể telnet từ NAT đến Server A trên cổng 22. Vì vậy, Access rất tốt.

Khi tôi chạy telnet 54.213.116.251 2222trên máy tính xách tay của mình, tôi thấy mục bên dưới trong tcpdump trên 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

Vì vậy, nó có nghĩa là iptables đang định tuyến các gói đến 10.0.1.243. (BTW, xxx.xxx.xxx.xxxlà địa chỉ IP công cộng của máy tính xách tay của tôi)

Nhưng khi tôi chạy tcpdump trên Máy chủ A, tôi không thấy bất cứ thứ gì đến từ 10.0.0.54đó là địa chỉ IP Nội bộ / Riêng tư của NAT ( Và tôi nghĩ đây là vấn đề ):

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 

Nhưng nếu tôi telnet từ NAT dụ đến Máy chủ A, tôi sẽ thấy nội dung tốt trong tcpdump trên Máy chủ A ( Điều này có nghĩa là PREROUTINGQuy tắc chung của tôi không hoạt động như mong đợi ):

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

Phần kết luận:

Từ đầu ra tcpdump trên NAT, có vẻ như Iptables đang chuyển tiếp các gói của tôi tốt.

từ kết xuất TCP trên Máy chủ A, tôi có kết nối tốt từ NAT đến Máy chủ A.

Nhưng trong End-to-end, tôi không thể kết nối với máy chủ A từ máy tính xách tay của mình.

( BTW, tôi biết đường hầm SSH và những thứ tốt khác. Nhưng tôi chỉ muốn Iptables giúp tôi điều này. )

Cuối cùng, tôi đã bẻ khóa nó !!!!

Trong trường hợp NAT, tôi đã phải thay đổi lệnh dưới đây:

Từ:

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

Đến:

iptables -t nat -A POSTROUTING -j MASQUERADE

Va no đa hoạt động!!!!

Vì vậy, tôi sẽ sớm tạo một câu hỏi mới trên ServerFault để hỏi những lợi thế và bất lợi của việc sử dụng hai lệnh trên là gì.

• Đảm bảo rằng bạn đang cho phép cổng tcp 2222inboud từ 0.0.0.0/0nhóm bảo mật cho hộp nat của bạn
• Hãy chắc chắn rằng bạn đã thiết lập VPC "Bảng lộ trình" đúng cách.
• Ít nhất hai bảng riêng biệt (một bảng được liên kết với mạng con riêng tư, một bảng được liên kết với mạng con công cộng)
• 10.0.1.0Mạng con (riêng tư) của bạn phải có quy tắc bảng tuyến đường như: Destination : 0.0.0.0/0, Target: "Nat box"
• Mạng 10.0.0.0con (công khai) của bạn phải có quy tắc bảng tuyến đường như: Đích : 0.0.0.0/0, Mục tiêu: "Cổng Internet"

• Hãy chắc chắn rằng bạn đã vô hiệu hóa kiểm tra Nguồn / đích trên hộp NIC cho hộp NAT của bạn, không có niềm vui NATting nào nếu không có nó. (Tôi biết bạn đã có cái này nhưng nó thực sự quan trọng, vì vậy bao gồm nó cho một số người xem trong tương lai)

• Đảm bảo các gói gửi đi biết đi đâu:

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

• Đảm bảo các gói inboud 2222được định tuyến lại đúng cách:

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

Bài viết này đã giúp tôi rất nhiều trong việc hiểu AWS NAT. Vì vậy, tôi bắt đầu điều tra những gì làm cho iptables -t nat -A POSTROUTING -j MASQUERADEnó hoạt động.

Vâng, câu trả lời tôi tìm thấy tuyên bố trên là cho phép hộp NAT cung cấp cho NAT 'LAPTOP' IP thành '10 .0.0.54 'trong khi cùng lúc thực hiện NAT đích đến 10.0.1.243. Tại thời điểm này, hộp mạng con riêng chỉ yêu cầu ssh đến từ thiết bị NAT. Lệnh này thực sự đang làm giảm tính bảo mật của máy chủ mạng con riêng. Nên sử dụng lệnh dưới đây để tinh chỉnh truy cập mạng con riêng thông qua hộp ssh và NAT như được đề cập dưới đây;

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

An toàn hơn một chút:

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