在去年，因为众所周知的因素影响，项目的甲方主动提出延缓设备的交付。作为乙方，尽管项目延缓是甲方提出的，但依旧希望按期交付，这样才能回款，熬过一年。其实，2022年初，几类传感器、压控温控阀等已经安装到位，弱电也已经通到了交换机。遗留工作，主要是新控制软件的现场调试。由于设备工作在甲方车间现场的LAN中，而甲方车间并没有连接互联网，这使得乙方的技术人员无法连接到现场LAN开展调试（一些细节和时间事件，如液体、压力无法准确模拟）。为了尽快完成升级改造，乙方请到我来协助解决远程调试的问题，还发给我一个工卡，职务是“特聘现场工程师”，关于这个头衔，文章后面有题外话。先直奔主题。

1.PCAPHub与云IP实现异地LAN工业联测

接到这个项目，马上想到使用云虚拟机（静态公网IP）为中继，在甲方临时配置一个互联网连接，而后使用SSH端口映射（-L,-R）把要调试的端口带到云虚机，从而完成乙方、甲方的联调。相关技术参考：《ssh服务器重定向功能在家庭宽带动态ip资源发布中的应用》

但是，这种方式只能映射固定的端口到云虚机，而且必须是TCP协议的。详细了解乙方的软件，存在大量的UDP数据，以及广播、组播，所以不适用。如果只映射远程桌面（VNC，Linux），是可以连接到控制台的Arm器件的，但只能配置运行，若要支持乙方远程基于真实车间条件开展断点调试，还是要搞定局域网UDP的转接，把甲方的整个局域网带给乙方。

最终，我选择直接改造基于PCAP的软Hub，加入以太网隧道，一劳永逸的解决调试问题。这个技术已经在前面专门介绍，参考《EthernetOnTCP–基于Qt QSslSocket 套接字在PCAP 集线器上实现以太网隧道》

需要注意的是，通过手机连接云虚机进行数据交换，适用于临时搭建的窄带传感器网络，对宽带实时视频这种，可能需要专用的公网IP连接。另外，网络的安全性交给了SSH服务器。我们为了安全，没有在云虚机上开放SSH以外的端口，而是使用乙方的SSH连接，把云虚机本地的端口带回乙方本地。这样操作，无法登入云虚机的用户将无法连接调试网络。

1.1 连接关系

连接关系如下图所示：
链接关系

1.2 工作原理

其工作原理等效为在甲乙双方的交换机上插接一个直连网线。
等效原理乙方就像身临其境一般直接进行LAN以太网操作，甚至可以直接获取甲方网内的DHCP服务，ZigBee-LAN-Wifi等甲方设备的管理页面也可以直接操作。

为了完成这种连接，我们从右往左叙述过程。

（1）甲方

甲方设备都可以通过车间交换机访问。传感器、Zig-Bee中继器、Wifi中继的管理端也连接在交换机上。
车间交换机匀出一个口，连接便携计算机。
便携计算机通过手机热点Wifi或者USB热点，连接到云虚拟机。
便携计算机运行PCAPHub，工作在服务器模式，在TCP:12377监听。一方面，乙方的数据通过TCP:12377传过来，通过便携计算机LAN口抵达车间交换机；另一方面，车间交换机的数据会经由LAN口抓包发给乙方。
由于甲方没有固定的公网IP，便携计算机上需要安装一个Git，利用 ssh -R，把本地12377端口带到云虚机上。

甲方PCAPHub设施：

云虚机端口映射指令（在甲方git bash下运行）：

ssh -o "StrictHostKeyChecking no"  -R 12377:127.0.0.1:12377 debug@123.234.243.132
如果强调本地监听（更安全），则为
ssh -o "StrictHostKeyChecking no"  -R 127.0.0.1:12377:127.0.0.1:12377 debug@123.234.243.132

（为保护乙方权益，IP地址为示意地址）

为了安全起见，云虚机并没有设置12377端口为可见。 也就是说，如果从其他位置连接 123.234.243.132:12377，是连不上的。这是因为我们没有为PCAPHub加入认证策略。如果贸然把端口12377暴露在公网，可能会被恶意连接，或者插入一个智子程序（三体人？）干扰我们的实验。

（2）云虚机

云虚机运行着Debain系统，在甲方计算机完成ssh连接后，12377端口就被-R到云虚机上。
乙方也会运行一个SSH客户端，届时登入时，会继续把云虚机的12377端口-L到乙方本地。
乙方通过连接本机的12377端口，经由两级SSH隧道连接到甲方的PCAPHub本机的12377端口。

（3）乙方

便携式计算机通过园区wifi直接上网。SSH到云虚机，并把云虚机本机的12377 -L到本机。
便携计算机上的PCAPHub通过127.0.0.1::12377端口，去主动连接甲方，形成通道。
便携式计算机的PCAPHub 一方面把LAN口的本地数据通过12377端口发给甲方，同时，甲方会传送网络数据到本地，通过LAN口发到乙方的调试交换机。
乙方工程师的开发工作站，就可以直接通过局域网地址操作甲方的各类设备，好像自己就插接在甲方的交换机一样。

乙方脚本：

 ssh  -L 12377:127.0.0.1:12377 develop@123.234.243.132
 如果强调本地监听（更安全），则为
 ssh  -L 127.0.0.1:12377:127.0.0.1:12377 develop@123.234.243.132

乙方PCAP-Hub设置：
Client

（4）SSH心跳保活

要注意，在云虚机的SSH服务器上，sshd_config里设置SSH心跳，以便在没有流量的时候保持连接：

AllowAgentForwarding yes
AllowTcpForwarding yes
GatewayPorts yes
ClientAliveInterval 30
ClientAliveCountMax 3

1.3 最终效果

最终效果，就是乙方的工作站“仿佛”真的连接在甲方的车间交换机上，并能够方便的进行在线断点调试。有了这种高大上的模式支持，只用了1周就把各类参数、门限调整完毕，大大节约了时间成本，项目按时验收。

SSH原理如下：

这种完全依靠SSH隧道来递交本地监听的方法，把安全性交给了SSH服务器和证书，可谓非常讨巧。12377端口自始至终不会直接出现在外部网络。

2. 题外话：现场工程师

在传统制造业、互联网，以及所有和工程相关的领域，都会生长着一类非常硬核的攻城狮。他们不仅是行业全栈工程师，又具有非常丰富的现场经验——编程、电气、电子、万用表、电烙铁都能来上两招。当某个问题出现，整个生产流程阻塞时，总能冷静分析原因，并竭尽全力、另辟蹊径利用手头的工具甚至现场创造工具，让系统迅速恢复运转。

具备这种“急诊医生”能力的技术人员，有正规的定义，叫做“现场工程师”。现场工程师是对所在行业具备完整的理论认知与实践经历，能够在系统工作的现场基于有限时间、有限资源、有限人手的情况下，创造性的解决问题的综合性工程技术人员。

现场工程师

2.1 现场工程师的其他案例

除了本文的案例，笔者曾经参加过很多现场填坑，有值得写一写和编程相关的琐碎、案例，都放在了《现场工程师》专栏里。比如文章《机械盘阵高并发——使用ImDisk 与 junction显著提高整体吞吐性能》较好的阐述了现场工程师的工作场景。

其实，和编程关系不大的案例还有很多，但CSDN是计算机相关论坛，所以就不太合适写这些奇怪的杂货。近几年快递很慢，现场工程师的应变能力得到了突出。不仅是行业典型的专业能力，一些“歪门邪道”的跨界应变也非常体现现场处置能力：

IO控制电路中一电阻断裂，使用铅笔芯（石墨）临时制作滑动可变电阻恢复流水线运转。为保证电阻的温变特性，使用食用油（大豆油）浸泡电阻降温。
边远小厂控制盒一9V电源模块烧毁，使用12V电源+2个手电筒灯泡（小卖部买的老式手电）串联降压临时解决问题。
使用工厂木门角铁磨制卡扣，固定后局部淬火暂时修复三角皮带。
温度传感器失效，用摄像头+温度计+图像处理，得到温度值实现串口推送。
震动传感器故障，使用音箱扬声器改装，拆掉纸盆，塑封固定，接入声卡麦口采集波形进行识别。

现场工程师不一定是程序猿，所有工业部位都会有类似特征的工程师。如化工、机械制造。他们所学的职业技能可能不同，但能力的本质又高度一致。

2.2 顶级现场工程师的素质

我认识一个高中学弟，他是一个非常厉害的现场工程师（比我厉害多了，非计算机行业）。他的同事看他有点像看纪录片《病魔缠身》里的主角医师，“一看到他，就稳了”。本来公认要等五六天，花几万块才能解决的问题，他往往下班前几十块钱就解决——甚至还能撸一个小工具出来。这样的人，太厉害了，我了解他的成长过程，非常硬核。