AWS VPC + IPtables + NAT: Die Portweiterleitung funktioniert nicht

Gestern habe ich hier eine Frage gestellt , aber ich denke, meine Worte waren nicht klar genug. Übrigens, diese Frage ist kein Duplikat.

Ich habe AWS VPC Setup wie unten.

ZIEL / PROBLEM : SSH zu Server A vom Internet. Und es funktioniert nicht.

Server A befindet sich in einem privaten Subnetz und daher möchte ich iptables NATing auf meiner NAT-Instanz aktivieren, damit ich direkt vom Internet zu SErver A ssh kann

Ich verfolge dies und das

Ich habe den folgenden Befehl auf der NAT-Instanz ausgeführt:

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

Die IP-Weiterleitung ist auf der NAT-Instanz aktiviert:

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

MASQUERADE wird auf einer NAT-Instanz ausgeführt:

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-Sicherheitsgruppen sind gut konfiguriert, um verschiedene Zugriffe zu ermöglichen, die für diesen Testfall erforderlich sind.

Fehlerbehebung:

Ich kann über Port 22 von NAT zu Server A telneten. Der Zugriff ist also gut.

Wenn ich telnet 54.213.116.251 2222auf meinem Laptop laufe , sehe ich den folgenden Eintrag in tcpdump auf 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

Das bedeutet, dass die iptables die Pakete an weiterleiten 10.0.1.243. (Übrigens xxx.xxx.xxx.xxxist die öffentliche IP-Adresse meines Laptops)

Aber wenn ich tcpdump auf Server A ausführe, sehe ich nichts, von 10.0.0.54dem die interne / private IP-Adresse von NAT stammt ( und ich denke, das ist das Problem ):

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 

Wenn ich jedoch von der NAT-Instanz zu Server A telnete, werden in tcpdump auf Server A gute Inhalte angezeigt ( dies bedeutet, dass meine allgemeine PREROUTINGRegel nicht wie erwartet funktioniert ):

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

Fazit:

Aus der tcpdump-Ausgabe auf NAT geht hervor, dass Iptables meine Pakete problemlos weiterleitet.

Vom TCP-Dump auf Server A habe ich eine gute Konnektivität von NAT zu Server A.

In End-to-End kann ich jedoch von meinem Laptop aus keine Verbindung zum Server A herstellen.

( Übrigens kenne ich SSH-Tunnel und andere gute Sachen. Aber ich möchte, dass nur Iptables mir dabei helfen. )

Endlich habe ich es geknackt !!!!

Auf der NAT-Instanz musste ich den folgenden Befehl ändern:

Von:

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

Zu:

iptables -t nat -A POSTROUTING -j MASQUERADE

Und es hat funktioniert!!!!

Daher werde ich in Kürze eine neue Frage zu ServerFault erstellen und fragen, welche Vor- und Nachteile die Verwendung der beiden oben genannten Befehle hat.

• 2222Stellen Sie sicher, dass Sie den TCP- Port 0.0.0.0/0in der Sicherheitsgruppe für Ihre Nat-Box zulassen
• Stellen Sie sicher, dass Ihre VPC "Route Table" ordnungsgemäß eingerichtet ist.
• Mindestens zwei separate Tabellen (eine dem privaten Subnetz und eine dem öffentlichen Subnetz zugeordnet)
• Ihr 10.0.1.0(privates) Subnetz sollte eine Routentabellenregel haben wie: Ziel : 0.0.0.0/0, Ziel: "Nat-Box"
• Ihr 10.0.0.0(öffentliches) Subnetz sollte eine Routentabellenregel haben wie: Ziel : 0.0.0.0/0, Ziel: "Internet-Gateway"

• Vergewissern Sie sich , Quell- / Zielprüfung deaktiviert auf dem NIC für Ihre NAT - Box, ohne NATting Spaß ohne sie. (Ich weiß, dass Sie dies bereits haben, aber es ist wirklich wichtig, also schließen Sie es für einen zukünftigen Betrachter ein)

• Stellen Sie sicher, dass ausgehende Pakete wissen, wohin sie gehen sollen:

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

• Stellen Sie sicher, dass Inboud-Pakete 2222ordnungsgemäß umgeleitet werden:

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

Diese Beiträge haben mir sehr geholfen, AWS NAT zu verstehen. Also begann ich zu untersuchen, warum iptables -t nat -A POSTROUTING -j MASQUERADEes funktionierte.

Nun, die Antwort, die ich in der obigen Anweisung gefunden habe, besteht darin, dass die NAT-Box NAT die 'LAPTOP'-IP auf '10 .0.0.54' quellen kann, während gleichzeitig das Ziel-NAT auf 10.0.1.243 ausgeführt wird. Zu diesem Zeitpunkt ist die private Subnetzbox eine SSH-Anforderung, die nur vom NAT-Gerät kommt. Dieser Befehl verringert tatsächlich die Sicherheit des privaten Subnetzservers. Es wird empfohlen, den folgenden Befehl zu verwenden, um den privaten Subnetzzugriff über ssh und NAT wie unten beschrieben zu optimieren.

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

Ein bisschen sicherer:

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