【踩坑实录】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 防火墙后依然超时
-
但：
bashssh 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.175Windows 会做：
-
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: noLink 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 + 多网卡环境