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

- 一、问题现象回顾
- 二、最终结论（先给答案）
- 三、关键网络状态还原
- 四、为什么会出现这种"反直觉"现象？
- - [1️⃣ Linux 允许多个网卡处于同一网段](#1️⃣ Linux 允许多个网卡处于同一网段)
  - [2️⃣ SSH 是"入站连接"，必须命中正确的物理接口](#2️⃣ SSH 是“入站连接”，必须命中正确的物理接口)
  - [3️⃣ 为什么"能上网但 SSH 失败"？](#3️⃣ 为什么“能上网但 SSH 失败”？)
- [五、为什么这个问题在 ICS + 国产盒子上特别常见？](#五、为什么这个问题在 ICS + 国产盒子上特别常见？)
- - [1️⃣ Windows ICS 的特点](#1️⃣ Windows ICS 的特点)
  - [2️⃣ 国产化盒子常见硬件形态](#2️⃣ 国产化盒子常见硬件形态)
- 六、如何快速定位这类问题（实战方法）
- - [✅ 方法一：看物理链路（最关键）](#✅ 方法一：看物理链路（最关键）)
  - [✅ 方法二：临时关闭不用的网口（强烈推荐）](#✅ 方法二：临时关闭不用的网口（强烈推荐）)
  - [✅ 方法三：工程化建议（长期）](#✅ 方法三：工程化建议（长期）)
- 七、为什么"之前能用，现在不行"？
- 八、经验总结（工程级）
- 九、适用场景

一、问题现象回顾

硬件与环境：

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 防火墙后依然超时
但：
bash 复制代码
```
ssh root@192.168.137.30
```
可以成功连接

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

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

一句话版本：

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

三、关键网络状态还原

盒子网络状态（简化）：

text 复制代码

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 是"入站连接"，必须命中正确的物理接口

当你执行：

bash 复制代码

ssh root@192.168.137.175

Windows 会做：

ARP 查询：192.168.137.175 → MAC ?
发 TCP SYN 到该 MAC
如果该 MAC 在 未连线接口（eth1） 上：
- 包直接丢失
- 表现为：Connection timed out

而你连：

bash 复制代码

ssh root@192.168.137.30

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

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

因为这是两个方向：

方向	行为
盒子 → 外网	出向，走默认路由（eth0），正常
Windows → 盒子	入向，命中错误接口，失败

出向 OK ≠ 入向 OK

这是调试中最容易误判的一点

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

1️⃣ Windows ICS 的特点

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

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

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

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

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

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

bash 复制代码

ethtool eth0 | grep Link
ethtool eth1 | grep Link

输出示例：

text 复制代码

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

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

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

假设实际用 eth0：

bash 复制代码

ip link set eth1 down

好处：

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

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

一个网段只留一个接口
管理口 / 业务口：
- 不同网段
- 或只启用其一
禁止"双网口 + 同网段 + DHCP"长期存在

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

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

之前：
- DHCP 给了 eth0 一个 IP
- 你刚好连对了
后来：
- 重启 / 插拔 / DHCP 重新分配
- IP 漂移到 eth1
行为没变，对象变了

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

八、经验总结（工程级）

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

网络问题 70% 不是"不通"

而是"通到了你没意识到的那个接口"

记住三条铁律：

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

九、适用场景

本文结论同样适用于：

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