基于SSH端口转发实现内网客户机的远程（续）

使用中发现的问题

半个月前，我基于SSH.NET实现了通过端口转发功能远程内网客户机，并将此功能加入到数采管理中心通讯服务中。在生产环境中试用后，逐渐发现以下问题：

1. 由于不能同时转发到同一个端口，每次使用完后必须下发停止命令关闭端口转发，然而忘记关闭在所难免
2. 端口转发功能集成在通讯服务内部，使得远程更新通讯服务自身相对麻烦
3. 平台上无法查看当前有哪些客户机开启了端口转发，分别占用了哪些端口
4. 平台上无法获取命令的反馈，即下发开启端口转发命令后，不清楚执行结果，远程不了只能尝试更换其它端口

从现场角度出发，前两个问题可以解决，其它问题需要平台配合。

引入超时机制

在下发的命令中增加一个参数AutoCloseAfter以限制开启时长，默认开启60分钟，此时下置的命令就变成如下：

{
	"Start": "True",                                   // true，开启端口转发，false，关闭端口转发
	"Params": {
		"Server": "xxx.xx.xx.xxx",                     // 服务器
        "Port": 22,                                    // 服务器端口，默认端口22，可以省略
		"UserAccount": "xxx",                          // 服务器ssh账户
		"UserPassword": "xxx**..123",                  // 服务器ssh账户密码
		"ForwardPort": 5938,                           // 待转发端口
		"TargetPort": 13389,                           // 转发后的目标端口
        "AutoCloseAfter": 60                           // 超出设定时长（分钟）后自动关闭
	}
}

超时后由现场程序主动断开。

分离端口转发功能

将端口转发功能从通讯服务中分离，封装成独立的服务。通讯服务在收到指令后通过请求该服务提供的Restful接口来启动/关闭端口转发，并且可以通知支持转发多个端口。

定时上报当前转发的端口

通讯服务获调取API获取当前转发的端口，通过MQTT协议上报给数采管理中心。

后记

赤果果地又给自己挖了个坑，需要分别调整现场客户端软件和数采管理中心接口+画面，这工作量可不小。因为不熟悉golang，后端什么时候改完个未知数。

2021年9月2日星期四