AWS VPC + IPtables + NAT:ポート転送が機能していません


10

昨日、ここに質問を投稿しましたが、言葉でははっきりしていなかったと思います。ところで、この質問は重複ではありません。

以下のようにAWS VPCセットアップがあります。

ここに画像の説明を入力してください

目標/問題:インターネットからサーバーAにSSH接続します。そしてそれは働いていません。

サーバーAはプライベートサブネットにあるため、インターネットから直接サーバーAにSSH接続できるように、NATインスタンスでiptables NATを有効にしたい

これこれをフォローています

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セキュリティグループは、このテストケースに必要なさまざまなアクセスを許可するように適切に構成されています。

トラブルシューティング:

ポート22でNATからサーバー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がパケットを正常に転送しているようです。

サーバーAのTCPダンプから、NATからサーバーAへの接続が良好です。

しかし、エンドツーエンドでは、ラップトップからサーバーAに接続できません。

ところで、私はSSHトンネルと他の良いものを知っています。しかし、これを手助けしてくれるのはIptablesだけです。


2
NATインスタンスの送信元/送信先チェックを無効にしましたか?
Dusan Bajic 2014年

どういう意味ですか?それを確認するには?私は、全体のiptablesのmanページを検索するが、送信元/宛先のチェックについての事を言っていないです(私は明らかに何かを逃した場合を除きます。)
slayedbylucifer

AWSウェブコンソール(またはCLI)でそれを行う必要があります。 docs.aws.amazon.com/AmazonVPC/latest/UserGuide/...
斗山Bajic

ありがとう。それはすでにDisabledNATインスタンス用であることがわかりました。
slayedbylucifer 2014年

回答:


8

最後に、私はそれを割った!!!!

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つのコマンドを使用することの利点と欠点を尋ねます。


万人に感謝します。同じ問題がありました。同じです...すべてのステップが整っていました...しかし、この "-o eth0"もありました。それを削除して、魅力のように働きました。百万に感謝します。
2016年

それが機能する理由は、「-s 10.0.0.0/16」がソース IP 10.xxxのパケットのみを変換するように言っているためですあなたのラップトップの要求を無視していた。Linuxのコマンドラインで「ip r」を実行して、eth0が実際にイーサネットデバイスの名前であるかどうかを確認することもできます。そうでない場合は、ethデバイスに指定されている名前(ens192など)に変更してください。
Ryan Shillington

また、iptablesのmanページを読んで上記のことを学びました。それは本当に良いものであり、長い読み物ではありません。私はそれを強くお勧めします。コマンドプロンプトから "man iptables"を実行して、すべての栄光を確認します。
Ryan Shillington

7
  • 2222NAT 0.0.0.0/0ボックスのセキュリティグループからのTCPポート入力を許可していることを確認してください
  • VPCの「ルートテーブル」が正しく設定されていることを確認してください。
  • 少なくとも2つの個別のテーブル(1つはプライベートサブネットに関連付けられ、1つはパブリックサブネットに関連付けられている)
  • あなたの10.0.1.0目的地::(プライベート)サブネットのようなルートテーブルのルールを持っている必要があり0.0.0.0/0、ターゲット:「NAT箱」
  • あなたの10.0.0.0目的地::(パブリック)サブネットのようなルートテーブルのルールを持っている必要があり0.0.0.0/0、ターゲットを:「インターネットゲートウェイ」
  • NATボックスのNICで送信元/送信先チェックが無効になっていることを確認してください。これがないと、NATの楽しみがありません。(私はあなたがすでにこれを持っていることを知っていますが、それは本当に重要なので、将来の視聴者のためにそれを含めます)

  • 発信パケットがどこに行くべきか知っていることを確認してください:

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

  • inboudパケットが2222適切に再ルーティングされることを確認します。

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


あなたのすべての提案はすでに整っています。ありがとう。
slayedbylucifer 2014年

1
すべてのステップを表示するように更新しました
c4urself 2014年

ありがとう。あなたの努力のために+1。あなたのMASQUERADEコマンドは、私の場合は役に立ちません。何かが足りないのかもしれません。MASQUERADE私を飛ばす唯一のコマンドは、私の回答で述べたものです。
slayedbylucifer 2014年

これは、最初のiptablesコマンドで10.xxxをルーティングするだけなので機能しないことを除いて、すべて素晴らしいアドバイスです。彼はインターネットから来るものをルーティングしたいと考えています。以下のOP自身の回答を参照してください。
Ryan Shillington

2

この投稿はAWS NATを理解するのに大いに役立ちました。それで私はiptables -t nat -A POSTROUTING -j MASQUERADEそれがうまくいった理由を調査し始めました。

さて、私が上記のステートメントを見つけた答えは、NATボックスが「10.0.0.54」への「ラップトップ」IPをソースNATすることを許可すると同時に、10.0.1.243への宛先NATを実行することです。現時点では、プライベートサブネットボックスは、NATデバイスからのみ送信されるsshリクエストです。このコマンドは、実際にはプライベートサブネットサーバーのセキュリティを低下させています。以下のコマンドを使用して、sshとNATボックスを介したプライベートサブネットアクセスを微調整することをお勧めします。

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

0

少し安全:

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
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.