【踩坑实录】Windows ICS 共享网络下，国产化盒子 SSH 连接异常的完整分析

一、问题现象回顾

硬件与环境：

• Windows 主机，通过Internet Connection Sharing（ICS）给国产化盒子共享网络
• 盒子有双网口（eth0 / eth1）
• Linux 系统，能正常访问外网
• SSH 服务正常运行（sshd监听0.0.0.0:22）

异常表现：

• ping www.baidu.com正常

• ssh root@192.168.137.175连接超时

• 关闭 Windows 防火墙后依然超时

• 但：

  sshroot@192.168.137.30

  可以成功连接

二、最终结论（先给答案）

问题根因：双网口设备在同一网段下，IP 分配到“非物理连线口”，导致入站流量走错接口

一句话版本：

SSH 连不上不是因为网络不通，而是“你连的是没插网线的那个网口的 IP”

三、关键网络状态还原

盒子网络状态（简化）：

eth0 → 192.168.137.175 （有网线，Link yes） eth1 → 192.168.137.30 （无网线 / 或被当成备用口）

Windows 侧通过 ICS 分配 IP：

• 同一个子网：192.168.137.0/24
• 同一台设备的两个网口，同时被 DHCP 分配了 IP

四、为什么会出现这种“反直觉”现象？

1️⃣ Linux 允许多个网卡处于同一网段

从 Linux 内核角度看：

• eth0、eth1 都是合法接口
• 都在192.168.137.0/24
• DHCP 给谁 IP，内核并不会“判断是否真的插了线”

👉IP 是否可达 ≠ 物理是否连线

2️⃣ SSH 是“入站连接”，必须命中正确的物理接口

当你执行：

sshroot@192.168.137.175

Windows 会做：

1. ARP 查询：192.168.137.175 → MAC ?

2. 发 TCP SYN 到该 MAC

3. 如果该 MAC 在未连线接口（eth1）上：

   • 包直接丢失
   • 表现为：Connection timed out

而你连：

sshroot@192.168.137.30

刚好命中了真正有物理链路的接口，所以成功。

3️⃣ 为什么“能上网但 SSH 失败”？

因为这是两个方向：

出向 OK ≠ 入向 OK
这是调试中最容易误判的一点

五、为什么这个问题在 ICS + 国产盒子上特别常见？

1️⃣ Windows ICS 的特点

• 强制使用192.168.137.0/24
• 自带 DHCP Server
• 不感知对端是单网口还是双网口

2️⃣ 国产化盒子常见硬件形态

• 双网口（管理口 + 业务口）
• 默认都启用
• DHCP 同时生效

👉ICS + 双网口 + 同网段 = 高概率踩坑组合

六、如何快速定位这类问题（实战方法）

✅ 方法一：看物理链路（最关键）

ethtooleth0|grepLinkethtooleth1|grepLink

输出示例：

eth0: Link detected: yes eth1: Link detected: no

Link yes 的那个口，才是你“应该 SSH 的 IP”

✅ 方法二：临时关闭不用的网口（强烈推荐）

假设实际用 eth0：

iplinkseteth1 down

好处：

• 立刻消除 ARP / 路由歧义
• SSH 稳定性显著提升
• 调试阶段非常实用

✅ 方法三：工程化建议（长期）

• 一个网段只留一个接口

• 管理口 / 业务口：

  • 不同网段
  • 或只启用其一

• 禁止“双网口 + 同网段 + DHCP”长期存在

七、为什么“之前能用，现在不行”？

这是这个问题最迷惑人的地方，但原因很工程化：

• 之前：

  • DHCP 给了 eth0 一个 IP
  • 你刚好连对了

• 后来：

  • 重启 / 插拔 / DHCP 重新分配
  • IP 漂移到 eth1

• 行为没变，对象变了

👉这不是偶然，是必然会发生的漂移问题

八、经验总结（工程级）

在嵌入式 / 边缘设备调试中：

• 网络问题 70% 不是“不通”
• 而是“通到了你没意识到的那个接口”

记住三条铁律：

1. SSH 失败，先看Link
2. 双网口，先关一个
3. 同网段 ≈ 高风险状态

九、适用场景

本文结论同样适用于：

• Jetson 系列
• RK3588 / 飞腾 / 海光 / 鲲鹏 盒子
• Windows ICS / Linux DHCP
• Docker + 多网卡环境