最後に、私はそれをクラックしました!!!!
NAT インスタンスでは、以下のコマンドを変更する必要がありました:
差出人:
iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/16 -j MASQUERADE
宛先:
iptables -t nat -A POSTROUTING -j MASQUERADE
そしてそれは働いた!!!!
そのため、上記の 2 つのコマンドを使用する場合の長所と短所を尋ねる ServerFault に関する新しい質問をすぐに作成します。
- TCP ポート
2222を許可していることを確認してください0.0.0.0/0からの受信 nat ボックスのセキュリティ グループ - VPC の「ルート テーブル」が正しく設定されていることを確認してください。
- 少なくとも 2 つの個別のテーブル (1 つはプライベート サブネットに関連付けられ、もう 1 つはパブリック サブネットに関連付けられています)
- あなたの
10.0.1.0(プライベート) サブネットには次のようなルート テーブル ルールが必要です:Destination:0.0.0.0/0、ターゲット:「ナット ボックス」 - あなたの
10.0.0.0(パブリック) サブネットには次のようなルート テーブル ルールが必要です:Destination:0.0.0.0/0、ターゲット:「インターネット ゲートウェイ」 -
ソース/宛先チェックが無効になっていることを確認してください NAT ボックスの NIC では、それなしでは NATting の楽しみはありません。 (あなたが既にこれを持っていることは知っていますが、本当に 重要なので、将来の視聴者のためにそれを含めてください)
-
アウトバウンド パケットが行き先を認識していることを確認してください:
iptables --table nat --append POSTROUTING --source 10.0.0.0/16 --destination 0.0.0.0/0 --jump MASQUERADE -
受信パケットが
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ボックスが「LAPTOP」IPを「10.0.0.54」にソースNATし、同時に宛先NATを10.0.1.243に実行できるようにすることです。この時点で、プライベート サブネット ボックスは、NAT デバイスからのみ送信される ssh 要求です。このコマンドは、実際にはプライベート サブネット サーバーのセキュリティを低下させています。以下のコマンドを使用して、後述のように ssh および NAT ボックスを介してプライベート サブネット アクセスを微調整することをお勧めします。
iptables --table nat --append POSTROUTING --source "INTERNET IP of the Laptop" --destination 10.0.1.243 --jump MASQUERADE