AWS VPC + IPtables + NAT: Bağlantı Noktası İletme çalışmıyor

Dün burada bir soru yayınladım ama kelimelerimde yeterince net olmadığını düşünüyorum. BTW, Bu soru yinelenmiyor.

AWS VPC Kurulumu aşağıdaki gibidir.

AMAÇ / SORUN : İnternetten Sunucu A'ya SSH. Ve çalışmıyor.

Sunucu A özel alt ağda ve bu yüzden doğrudan Internet'ten SErver A'ya ssh böylece benim NAT örneğinde iptables NATing etkinleştirmek istiyorum

Ben takip ediyorum bu ve bu

NAT örneğinde aşağıdaki komutu çalıştırdım:

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

IP iletimi NAT örneğinde etkinleştirilir:

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

MASQUERADE NAT örneğinde çalışıyor:

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 Güvenlik grupları, bu test senaryosu için gereken çeşitli erişime izin verecek şekilde iyi yapılandırılmıştır.

Sorun giderme:

Bağlantı noktası 22 üzerinde NAT dan sunucu A telnet olabilir. Bu yüzden erişim iyidir.

telnet 54.213.116.251 2222Dizüstü bilgisayarımda çalıştığımda NAT'ta tcpdump'ta aşağıdaki girişi görüyorum:

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

Yani iptables paketleri yönlendiriyor demektir 10.0.1.243. (BTW, xxx.xxx.xxx.xxxdizüstü bilgisayarımın genel IP adresi)

Ancak Sunucu A'da tcpdump çalıştırdığımda 10.0.0.54, NAT'ın İç / Özel IP adresi olan hiçbir şey görmüyorum ( Ve bu sorunun olduğunu düşünüyorum ):

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 

Ancak NAT örneğinden Sunucu A'ya telnet yaparsam, Sunucu A'daki tcpdump'ta iyi şeyler görüyorum ( Bu, Genel PREROUTINGKuralım beklendiği gibi çalışmıyor ):

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

Sonuç:

NAT tcpdump çıktı, Iptables benim paketleri iyi iletiyor gibi görünüyor.

Sunucu A'daki TCP dökümünden, NAT'tan Sunucu A'ya iyi bir bağlantım var.

Ancak uçtan uca, dizüstü bilgisayarımdan A sunucusuna bağlanamıyorum.

( BTW, SSH tüneli ve diğer iyi şeyleri biliyorum. Ama sadece Iptables'ın bana bu konuda yardımcı olmasını istiyorum. )

Sonunda, ben Cracked !!!!

NAT örneğinde aşağıdaki komutu değiştirmek zorunda kaldım:

Gönderen:

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

Kime:

iptables -t nat -A POSTROUTING -j MASQUERADE

Ve ÇALIŞTI !!!!

Bu yüzden, yakında iki komutu kullanmanın avantaj ve dezavantajlarının ne olduğunu soran yeni bir soru oluşturacağım.

• Nat kutunuz için güvenlik grubunda tcp bağlantı noktasına gelen 2222girişe izin verdiğinizden emin olun0.0.0.0/0
• VPC "Rota Tablosu" ayarınızın doğru yapıldığından emin olun.
• En az iki ayrı tablo (biri özel alt ağ ile ilişkili, biri genel alt ağ ile ilişkili)
• Sizin 10.0.1.0Hedef: (özel) alt ağ gibi bir rota tablo kuralımız olmalı 0.0.0.0/0, Hedef: "Nat kutu"
• Sizin 10.0.0.0Hedef: (kamu) alt ağ gibi bir rota tablo kuralımız olmalı 0.0.0.0/0, Hedef: "İnternet ağ geçidi"

• NAT kutunuz için NIC'de Kaynak / hedef kontrolünü devre dışı bıraktığınızdan emin olun , onsuz NATting eğlencesi yoktur. (Bu zaten var biliyorum ama gerçekten önemli, bu yüzden gelecekteki bir izleyici için dahil)

• Giden paketlerin nereye gideceğini bildiğinden emin olun:

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

• 2222Düzgün yeniden yönlendirilmek için gelen paketlerin olduğundan emin olun :

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

Bu gönderiler AWS NAT'ı anlamamda bana çok yardımcı oldu. Böylece neyin iptables -t nat -A POSTROUTING -j MASQUERADEişe yaradığını araştırmaya başladım .

Yukarıdaki ifadeyi bulduğum cevap NAT kutusunun NAT'a 'LAPTOP' IP'sini '10 .0.0.54 'e kaynaklarken, aynı zamanda hedef NAT'ı 10.0.1.243'e gerçekleştirmesine izin vermektir. Şu anda özel alt ağ kutusu yalnızca NAT cihazından gelen ssh isteğidir. Bu komut aslında özel alt ağ sunucusunun güvenliğini azaltır. Aşağıda belirtildiği gibi ssh ve NAT kutusu aracılığıyla özel alt ağ erişimine ince ayar yapmak için aşağıdaki komutu kullanmanız önerilir;

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

Biraz daha güvenli:

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