AWS VPC NAT ssh_exchange_identification: 読み取り: ピアによる接続のリセット [閉じる]

AWS VPC サブネットに接続すると、誤解を招く重大なエラーが発生します。 B-> A接続ではエラーが発生しますが、A-> B接続では発生しなかったため、最初はライブラリのバグであることがわかりました。

これは、AWS システムの「デュアルレイヤールーティング」とサブネットの NAT インスタンスが原因で発生し、実際にパケットを間違ったネットワークチャネルにリダイレクトして SSH 接続が失われました.

以下は、元のスレッドから削除された「ケーススタディ」を含む私の投稿のコピーです。

私が知っている限り、これは質問に答えるための試みでもないので、削除します。別の質問がある場合は、@michael-mrozekで簡単に書いてください。

私：

@patrickが提案したように（ssh_exchange_identification：読み取り：ピアによる接続のリセット):

クライアント（サブネットB 172.16.3.76）

ssh 172.16.0.141 -vvv -p23
OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config 
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 172.16.0.141 [172.16.0.141] port 23.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
ssh_exchange_identification: read: Connection reset by peer

サーバー（サブネットA 172.16.0.141）

$(which sshd) -d -p 23
debug1: sshd version OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type ECDSA
debug1: private host key: #2 type 3 ECDSA
debug1: could not open key file '/etc/ssh/ssh_host_ed25519_key': No such file or directory
Could not load host key: /etc/ssh/ssh_host_ed25519_key
debug1: rexec_argv[0]='/usr/sbin/sshd' 
debug1: rexec_argv[1]='-d'
debug1: rexec_argv[2]='-p'
debug1: rexec_argv[3]='23'
Set /proc/self/oom_score_adj from 0 to -1000
debug1: Bind to port 23 on 0.0.0.0.
Server listening on 0.0.0.0 port 23.   
debug1: Bind to port 23 on ::.
Server listening on :: port 23.
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3
debug1: getpeername failed: Transport endpoint is not connected
debug1: get_remote_port failed

https://superuser.com/questions/856989/ssh-error-ssh-exchange-identification-read-connection-reset-by-peer

---

VPCの設定とケースの説明：

VPCで実行されているAWS EC2 Amazonインスタンス（172.16.0.0/16）があります。

• Elastic IPが接続されているパブリックサブネットA（172.16.0.0/24）、NATインスタンスA（172.16.0.200）があります。
• subnetAの他のインスタンスはinstanceAを介してインターネットと通信します（デフォルトは172.16.0.200 dev eth0を介して）。
• サブネットB（172.16.3.0/24）にインスタンスがあります。
• ルーティングテーブルは次のようになります。https://stackoverflow.com/questions/10243833/how-to-connect-to-outside-world-from-amazon-vpc

質問：

• サブネットAとサブネットBの両方のホストが正常にpingできます。
• サブネット A のホストは、サブネット B のホストとして SSH 経由で接続できます。
• サブネット B のホストは、サブネット A のインスタンス A として SSH 経由で接続できます。
• サブネットBのどのホストも、サブネットA（インスタンスAを除く）の他のインスタンスとしてSSHを介して接続できません。エラー：ssh_exchange_identification：read：ピアによる接続のリセットIF_AND_ONLY_IFサブネットAのインスタンスにデフォルトゲートウェイがNAT-InstanceAに設定されています（例：172.16を介したデフォルト値）。 （例：「172.16.0.1 dev eth0によるデフォルト値」）SubnetBhostsからそのインスタンスにSSH経由で接続できます。
• 注：subnetAにNATがない場合、subnetAのインスタンスには発信インターネット接続はありません。

だから...

この問題は、Amazon AWSルーターおよび/またはNAT設定によって発生する可能性があります。

今ではそのような事実にもかかわらず、私の考えではVPCルーティングテーブル次のように設定されます。

Destination Target 
172.16.0.0/16 local
0.0.0.0/0   igw-nnnnn

サブネットAインスタンスは次の場所にあります。

172.16.0.0/24

（編集：問題の原因：ルーティングテーブルは、AWSサイドルーティング：172.16.0.0/16を含むNATインスタンスを介して172.16.0.0/24以外のトラフィックをリダイレクトします。

default via 172.16.0.200 dev eth0 
172.16.0.0/24 dev eth0  proto kernel  scope link  src 172.16.0.60

サブネットBインスタンスは次の場所にあります。

172.16.3.0/24

サブネットBのホストがサブネットA（NATインスタンスAを除く）のインスタンスに接続すると、トラフィックは次のようになります。

172.16.3.X/24  --> 172.16.3.1 --> 172.16.0.Y  
                                      V
                        ???   <-- 172.16.3.200 (NAT) 

ここに問題があります。これを確認する必要tcpdumpがあり、NAT ルールで解決できますが、予想よりも複雑です。

実際、AWS ルーターのルールは

Destination Target 
172.16.0.0/16 local

理論的にはVPC / 16サブネットを含める必要がありますが、インスタンス/ 24サブネット+ NATゲートウェイは "system_level"の機能を隠します。