足不出户，搞定 IoT 设备故障诊断和恢复——实践类

一、背景

随着 IoT 的快速发展，越来越多的设备使用 IoT 能力，实现远程的数据采集、数据分析、设备管理。然而故障诊断、设备配置等运维工作却依然在现场执行。如以下场景：

场景一：扫地机器人不工作，寄回厂家返修，厂家用软件工具检测发现，只是某个传感器沾灰了，擦一下就好了。

场景二：某企业门禁打卡异常，运维人员上门，发现是因异常断电导致配置文件错误，重新配置一下就恢复了。

类似场景还有很多，设备运维目前多数还是依赖现场运维的方式，时效性和经济性都不高，设备厂商付出了很大的成本却没有换来好的客户体验。

如果故障诊断工作能够提前，诊断后能远程操作恢复，将给企业和用户都带来极大的便利。

二、技术难点

IoT 设备和运维 PC 都能连网，为什么运维 PC 不能远程访问 IoT 设备？

图片

• 没有公网 IP：IoT 设备一般没有公网 IP，可通过 NAT 网关连接互联网，但不能被互联网外部设备通过公网 IP 直接访问。

• 没有访问权限：NAT 网关都有自己的安全防护策略，不支持外网直接访问内网设备。

解决内网穿透问题，常见的解决方案有 NAT 穿透或者虚拟专用网络(VPN)。

• NAT 穿透：也叫 P2P 打洞，实现免服务器两个端点对点通信，但由于 NAT 网关类型多穿透过程复杂，以致成功率低，并不可靠;

• 虚拟专用网络(VPN)：VPN 也是一种远程访问技术，通过公网搭建专有网络。IoT 设备一般通过 VPN 网关才能使用 VPN，成本高、依赖外部网络部署。

IoT 设备因运行网络环境碎片化，设备资源有限，以上两种内网穿透方式并不能很好满足 IoT 设备的远程访问需求。

阿里云物联网平台结合自身的消息传输能力，推出了安全隧道功能，提供易用、低成本、安全、可靠的远程访问 IoT 设备的能力。

三、安全隧道介绍

安全隧道：通过物联网平台进行流转，提供给访问端与设备端之间安全可靠的双向数据流传输能力。该数据流同 TCP 的数据流一样，可确保数据是顺序到达的。用户可使用隧道传输任意协议的数据，如 SSH、Telnet、FTP 等 TCP 的应用协议数据，也支持自定义协议数据。

图片

安全隧道会话：安全隧道的底层实现是 TCP 连接，在 TCP/IP 四层模型中，一个 TCP 连接上只有一个应用层，如 HTTP、SSH。为了让单个隧道可被多个应用同时使用，安全隧道在应用层和传输层之间增加了会话层，数据收发以会话作为基本单元。隧道提供多会话管理能力，能让会话能像 TCP 连接一样使用，每个会话承载一个应用，单个隧道最大支持 10 个会话。

注：单个隧道的传输能力有上限，如果会话的数据过多，建议创建多个隧道。

图片

安全隧道与会话的关系，类似于现实中隧道与车道的关系，多个车道共享隧道。

四、安全隧道特性及价值

安全隧道的核心是提供内网穿透的能力，打破用户在运维时的网络限制。除核心能力外，物联网平台安全隧道还具有以下特性，在使用成本、易用性、安全、可扩展等方向上都做了优化。

五、安全隧道关键技术

5.1 隧道创建

安全隧道功能打通了物联网平台的消息服务和隧道服务，通过消息服务可对设备的隧道完成创建、开启/关闭、删除，实现设备只需一套身份即可同时使用两种服务。隧道创建的流程：

图片

1、设备建连：设备使用 MQTT 协议连接消息服务，通过设备认证信息鉴权，完成消息链路搭建。

2、创建隧道：访问端通过云端 api 或者控制台完成隧道创建，返回隧道建连信息。

3、下发隧道建连信息：隧道创建后，物联网平台会给设备发送隧道建连信息，包含隧道令牌(token)，用户自定义信息。

4、设备端隧道连接：设备端收到隧道建连信息后，连接隧道服务，通过隧道令牌(token)鉴权。

5、访问端隧道连接：访问端创建隧道成功后，也获得隧道建连信息，连接隧道服务。

访问端和设备端都连接上隧道服务后，即可使用隧道进行双向通信，以上过程都使用 TLS 加密，确保传输安全。

5.2 会话创建

隧道建立以后，由访问端发起会话，设备端响应会话。会话有个关键属性:会话类型，由用户定义，设备根据会话类型决定该会话数据的传输目的地。

建立会话前，用户需预设置会话类型与设备本地服务 IP 和端口的映射关系，如：[_SSH 会话]-->[127.0.0.1: 22]。

图片

六、安全隧道使用

完成隧道创建及会话创建后，可通过两种方式处理传输的数据，TCP 本地代理方式和自定义处理方式。

• TCP 本地代理方式：会话的数据收发将由本地代理处理，本地代理会对接收到的数据透传给对应 TCP 服务。常见场景：外网通过 TCP 协议访问内网设备的 TCP 服务，设备端作为 server，访问端作为 client。

• 自定义处理方式：会话的数据收发将由用户自定义处理。常见场景：UDP 协议使用隧道、串口传输转换为隧道传输。

6.1 TCP 本地代理方式

本地代理为在本地运行的独立进程，分为设备端代理和访问端代理，设备端代理运行在设备端，代理设备侧消息的收发，访问端代理运行在访问端(一般为 PC)，代理访问侧消息的收发。

设备端代理：提供 C 语言实现，集成在物联网平台设备端 SDK 中，详情请参考官网文档。

访问端代理：提供 Java 及 Go 语言两种实现，详情请参考官网文档。

图片

以 SSH 会话建连为示例描述工作流程：

1. 设备端代理：配置会话类型与服务地址的映射关系，连接上物联网平台隧道服务

2. 访问端代理：配置监听端口号与会话类型的映射，连接上物联网平台隧道服务

3. SSH 客户端：连接访问端代理，端口 xxx。

4. 访问端代理：接收端口 xxx 连接请求，根据端口识别为 SSH 会话，发起创建 SSH 类型会话

5.设备端代理：接收到 SSH 类型会话创建请求，根据会话类型找到服务地址[127.0.0.0:22]，连接 SSH 服务，返回会话创建结果。

6. 访问端代理：收到创建结果，反馈给 SSH 客户端

以上过程完成会话创建，后面的数据传输本地代理会透传数据，最终效果就像是 SSH 客户端直连 SSH 服务。

6.2 自定义处理方式

对于非 TCP 协议的应用场景，不能使用本地代理模式。

用户可基于开源协议进行对接，协议说明可点击下方链接访问物联网平台官网获取。

​​https://help.aliyun.com/document_detail/313816.html​​

也可基于 SDK 进行改造，修改 SDK 中关于会话的创建与数据收发的部分代码。近期也将推出自定义处理的使用示例，敬请关注。

图片

七、安全隧道功能扩展--远程登录

安全隧道很好的解决了 IoT 设备的远程访问问题，但用户在运维的时候，还是要先部署访问端，为进一步提高隧道的易用性，阿里云物联网平台针对安全隧道高频使用的场景--SSH 登录设备，扩展了远程登录功能。实现免环境部署，在控制台即可登录设备，同时提供协作及容灾能力，支持远程登录分享、设备主动请求登录的特性。

图片

7.1 控制台远程登录

不需要安装任何软件，在控制台(web 页面)即可通过 SSH 远程登录设备，体验如同局域网登录设备。

图片

7.2 远程登录分享

这个特性是解决登录权限分享问题。

应用场景：IoT 设备的所有者和运维人员可能隶属于不同的公司主体，当设备需要运维的时候，需要协作处理。

例如：设备属于 A 公司，软件模块是 ISV 公司 B 实现的，设备故障时，A 公司可将远程 SSH 登录权限分享给 B 公司，由 B 公司对设备进行登录运维。

远程登录功能不限制分享次数，但最多支持 10 个会话同时登录。

图片

7.3 设备主动请求登录信息

这个特性是为了解决当设备业务故障时，远程登录功能不可用的问题。

远程登录功能为了保持经济性及易用性，支持动态开启/关闭的，按需开启可以节省网络资源的使用，符合低碳的目的。

动态开启/关闭命令使用的物联网平台的消息通道，设备的业务一般也会使用消息通道，设备的业务程序普遍存在频繁使用、频繁更新特征，因此出现故障的概率会更大。

为了避免当业务故障的时(如内存错误)，导致消息通道不可用，不能开启远程登录，推出该特性作为解决方案。

设备主动请求远程登录信息，再将业务功能与运维功能拆分为不同的进程运行，确保业务故障时，运维功能可用。使用流程：

图片

设备端业务功能与运维功能完成进程隔离，业务进程定时请求远程登录信息，保存在本地或传递给运维进程。在登录信息过期前(最长 7 天)，当业务进程故障时，运维进程能继续运行，支持远程登录。如上图所示：业务进程完成过程 1.2.3 后，出现故障，不影响运维进程过程 4.5 的运行。

八、总结

​本文主要介绍阿里云物联网平台的运维功能安全隧道和远程​登录，包括业务背景，功能特性，原理介绍、以及应用场景。

如背景中提到的两个场景：扫地机故障检测，检测工具与扫地机通信使用的是自定义的行业协议，可安全隧道，远程完成故障检测，再指导用户恢复；打卡机的故障，使用远程登录功能连接设备，分析设备日志，定位问题后，再对设备进行配置，完成故障恢复。

物联网平台的运维工具除远程登录和安全隧道外，还有设备日志、设备升级、远程配置等能力，多种能力配合使用，可以更好的满足不同设备的应用场景，更多资料请点击“阅读原文”访问阿里云物联网平台官网进行了解。

​

物联网平台产品介绍详情：​​https://www.aliyun.com/product/iot/iot_instc_public_cn​​

阿里云物联网平台客户交流群