AWS VPC + IPtables + NAT: Die Portweiterleitung funktioniert nicht

10

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.

Geben Sie hier die Bildbeschreibung ein

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. )

Slayedbylucifer
quelle
2
Haben Sie die Quell- / Zielprüfung auf Ihrer NAT-Instanz deaktiviert?
Dusan Bajic
Was bedeutet es? Wie überprüfe ich das? Ich habe die gesamte Iptables-Manpage durchsucht, aber es wird nichts über die Überprüfung von Quelle / Ziel gesagt (es sei denn, ich habe etwas Offensichtliches verpasst.)
Slayedbylucifer
Sie müssen dies in der AWS-Webkonsole (oder CLI) tun. docs.aws.amazon.com/AmazonVPC/latest/UserGuide/…
Dusan Bajic
Vielen Dank. Ich finde, dass es bereits Disabledfür die NAT-Instanz ist.
Slayedbylucifer

Antworten:

8

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.

Slayedbylucifer
quelle
Mann danke in einer Million. Hatte das gleiche Problem, das gleiche ... Jeder Schritt war vorhanden ... aber dieses "-o eth0" war auch da. Entfernte es, arbeitete wie Charme. Danke in Millionen.
Neven
Der Grund, warum es funktioniert, ist, dass das "-s 10.0.0.0/16" besagt, dass nur Pakete mit der Quell- IP 10.xxx übersetzt werden sollen. Ich vermute, Ihr Heim-Laptop befand sich in Ihrem Heim-Netzwerk und stammte von einer externen IP, also vom NAT ignorierte die Anfragen Ihres Laptops. Andere möchten möglicherweise "ip r" in der Linux-Befehlszeile ausführen, um festzustellen, ob eth0 wirklich der Name ihres Ethernet-Geräts ist. Wenn nicht, ändern Sie es in den Namen Ihres eth-Geräts (z. B. ens192 oder was auch immer).
Ryan Shillington
Außerdem habe ich das oben genannte gelernt, indem ich die Manpage zu iptables gelesen habe. Es ist wirklich gut und nicht lange zu lesen. Ich empfehle es sehr. Führen Sie "man iptables" an der Eingabeaufforderung aus, um es in seiner ganzen Pracht zu sehen.
Ryan Shillington
7
  • 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

c4urself
quelle
Ihre einzelnen Vorschläge sind bereits vorhanden. Vielen Dank.
Slayedbylucifer
1
Ich habe es aktualisiert, um alle Schritte zu zeigen
c4urself
Vielen Dank. +1 für deine Bemühungen. Ihr MASQUERADEBefehl ist in meinem Fall nicht hilfreich. Vielleicht fehlt mir etwas. Der einzige MASQUERADEBefehl, der mich zum Fliegen bringt, ist der, den ich in meiner Antwort erwähnt habe .
Slayedbylucifer
Dies ist alles ein guter Rat, außer dass dies nicht funktioniert, da Sie in Ihrem ersten iptables-Befehl nur 10.xxx weiterleiten. Er möchte alles aus dem Internet weiterleiten. Siehe die Antwort von OP unten.
Ryan Shillington
2

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
Anirban Sinha
quelle
0

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
Alexandre MCS
quelle