AWS VPC NAT |ssh_exchange_identification：讀取：對等方重置連接

在 AWS VPC 子網中連接時，我遇到了嚴重的誤導性錯誤。該錯誤確實發生在B->A連接中，並且沒有發生在A->B中，所以一開始我以為是庫錯誤。

它恰好是由 AWS 系統“雙層路由和子網中的 NAT 實例將數據包重定向到錯誤的網路通道引起的，導致 ssh 斷開連接。

下面是我的一篇帶有“案例研究”的文章的副本，該文章已從原始文章中刪除：

據我所知，這甚至沒有試圖回答這個問題，所以我將其刪除。如果您有單獨的問題，請隨時將其作為一個發布 |@michael-mrozek

就我而言：

正如@patrick 建議的那樣（ssh_exchange_identification: read: Connection reset by peer）：

客戶端（子網 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 (172.16.0.0/16) 中執行了 AWS EC2 Amazon 實例

• 有公有子網 A (172.16.0.0/24)，NAT-instanceA (172.16.0.200) 附有彈性 IP
• 子網 A 中的其他實例通過 instanceA 與 Internet 通信（預設通過 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 中的主機可以通過 ssh 連接到子網 B 中的主機
• 子網 B 中的主機可以 ssh 到子網 A 中的實例 A
• 子網 B 中的所有主機都無法通過 ssh 連接到子網 A 中的其他實例（實例 A 除外），出現錯誤：ssh_exchange_identification：讀取：連接由對等方重置 IF_AND_ONLY_IF 子網 A 中的實例已將預設網關設置為 NAT-InstanceA（例如“預設通過172.16.0.200 開發 eth0’）。如果存在帶有 not_changed 預設網關的 instance_in_subnetA（例如“預設通過 172.16.0.1 dev eth0”），那麼您可以從 SubnetBhosts SSH 到該實例
• 評論：如果子網 A 中沒有 NAT，則子網 A 中的實例將沒有傳出網際網路連接

所以…

該問題可能是由 Amazon AWS 路由器和/或 NAT 配置引起的。

目前，我想，儘管事實上，VPC 路由表設置為：

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

subnetA實例位於

172.16.0.0/24

（編輯：問題的根源：路由表通過 NAT 實例重定向 172.16.0.0/24 以外的流量，覆蓋 AWS 側路由：172.16.0.0/16）

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

subnetB實例位於

172.16.3.0/24

當來自 subnetB 的主機連接到 subnetA 中的實例（NAT-instanceA 除外）時，流量如下：

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 子網，但 instance/24 子網 + NAT 網關隱藏了“system_level”上的功能。

在子網 A 中的實例（NAT 實例為 172.16.0.200）上，路由表如下所示：

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

實際上，一個補充：

$ ip r a 172.16.3.0/24 via 172.16.0.1
(or ip r a 172.16.3.0/16 via 172.16.0.1)

修復系統路由表：

default via 172.16.0.200 dev eth0
172.16.0.0/24 dev eth0  proto kernel  scope link  src 172.16.0.141
172.16.3.0/24 via 172.16.0.1 dev eth0

並將 VPC 子網路由轉移到 AWS 路由器

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

引用自：https://unix.stackexchange.com/questions/215037