昨日、私は質問を投稿しました here が、私の言葉では十分に明確ではなかったと思います。ところで、この質問は重複していません。
以下のようにAWS VPCセットアップがあります。
GOAL/PROBLEM:インターネットからサーバーAへのSSH。そしてそれは働いていません。
サーバーAはプライベートサブネットにあるため、my NATインスタンスでiptables NATを有効にして、インターネットから直接サーバーAにsshで接続できるようにします。
NATインスタンスで以下のコマンドを実行しました:
NAT# iptables -t nat -A PREROUTING -p tcp --dport 2222 -j DNAT --to-destination 10.0.1.243:22
NATインスタンスでIP転送が有効になっています:
NAT# sysctl -p
net.ipv4.ip_forward = 1
MASQUERADEはNATインスタンスで実行されています:
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セキュリティグループは、このテストケースに必要なさまざまなアクセスを許可するように適切に構成されています。
トラブルシューティング:
NAT=からポート22のサーバーAにtelnetで接続できます。アクセスは良好です。
ラップトップでtelnet 54.213.116.251 2222
を実行すると、NATのtcpdumpに次のエントリが表示されます。
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
つまり、iptablesがパケットを10.0.1.243
にルーティングしていることになります。 (ところで、xxx.xxx.xxx.xxx
は私のラップトップのパブリックIPアドレスです)
しかし、サーバーAでtcpdumpを実行すると、10.0.0.54
から何も送信されません。これは、NAT()の内部/プライベートIPアドレスであり、これが問題だと思います):
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
しかし、NATインスタンスからサーバーAにtelnetすると、サーバーAのtcpdumpに適切なものが表示されます()。これは、私の全体的なPREROUTING
ルールが期待どおりに機能しない):
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
結論:
NATのtcpdump出力から、Iptablesがパケットを正常に転送しているようです。
TCPサーバーAのダンプ、NATからサーバーAへの接続が良好です。
しかし、エンドツーエンドでは、ラップトップからサーバーAに接続できません。
(ところで、SSHトンネルやその他の優れた機能は知っています。しかし、Iptablesだけがこれを手伝ってくれます。)
最後に、私はそれを割った!!!!
NATインスタンスでは、以下のコマンドを変更する必要がありました:
から:
iptables -t nat -A POSTROUTING -o eth0 -s 10.0.0.0/16 -j MASQUERADE
に:
iptables -t nat -A POSTROUTING -j MASQUERADE
そしてそれは働いた!!!!
それで、ServerFaultですぐに新しい質問を作成して、上記の2つのコマンドを使用することの利点と欠点を尋ねます。
2222
からのTCPポート0.0.0.0/0
inboudを許可していることを確認してください10.0.1.0
(プライベート)サブネットには、次のようなルートテーブルルールが必要です:宛先:0.0.0.0/0
、ターゲット: "NATボックス"10.0.0.0
(パブリック)サブネットには、次のようなルートテーブルルールが必要です:宛先:0.0.0.0/0
、ターゲット: "インターネットゲートウェイ"NIC for your NAT box、no NATting fun)のソース/宛先チェックが無効になっていることを確認してくださいそれなしで(私はあなたがすでにこれを持っていることを知っていますが、本当に重要なので、将来の視聴者のために含めます)
送信パケットがどこに行くべきか知っていることを確認してください:
iptables --table nat --append POSTROUTING --source 10.0.0.0/16 --destination 0.0.0.0/0 --jump MASQUERADE
2222
へのinboudパケットが適切に再ルーティングされることを確認します。
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ボックスからソースへのアクセスNAT「ラップトップ」IPから「10.0.0.54」へのアクセスを同時に実行できるようにすることです。 NAT to 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
少し安全:
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