视频水尺太难搞！L2TP 异地组网助我远程调试渡口摄像头

文章目录

文章目录

1. 项目技术简介 & 难点介绍
2. 视频水尺安装 & 调试记录
3. 利用工业路由器异地组网

3.1 创建 L2TP 服务器
3.2 电脑端配置 VPN
3.3 配置工业路由器

3.3.1 接口配置
3.3.2 路由配置
3.3.3 防火墙配置
3.3.4 定时任务

4. 写在最后

前段时间，我在某市县实施当地的平安渡运项目智能化部分施工，主要负责水文气象设备前端的安装与调试，我们团队一行几人，我作为总体技术负责人，具体工作涵盖点位勘察、设备选型、线路与供电规划、现场实施协调以及与甲方、总包的技术沟通等。这项目拉拉扯扯搞了很多年，最近终于是落地了！

该项目面向县域内主要河段沿岸的码头和渡口，建设水文及气象监测系统，将实时数据统一上报至中心平台，供相关管理单位查看和研判，作为平安渡运和是否允许通航的重要决策依据，例如水位、降雨量或风力达到设定阈值时，当地渡船（俗称过河船）即需停航。

项目所在河段枯水期与丰水期水位差极大，历史上个别年份甚至出现过二十多米的水位落差，沿河不少房屋和设施都曾被淹没，我们沿线踏勘时也能明显看到这些痕迹，所幸近些年得益于水利工程建设和系统治理，整体情况已明显改善。该县举例我的家乡并不远，但我的老家是没有这么大的河，我也几乎么有乘坐过渡船，因而每到一处见到爬坡上坎又过河的场景时，我便会感叹：这偌大的中国啊，这形形色色的故乡啊！

因为设备的安装点位大多分布在乡镇和偏远村落，通常需要从县道转入乡道，再进入村村通道路，路况好的十来分钟可达，路况差的连小型面包车都难以通行，最折腾的一个点位先是要走几公里布满坑洼的烂路，随后还需乘坐十多分钟快艇才能到达，单程交通耗时接近两个小时。

货物把快艇塞的满满当当，沉重的发电机只能压在船头，感觉随时要翻！
立杆本来安装在了一条路边，装好临走，当地人以种种原因说那地方不行，遂又挪了一下...

1. 项目技术简介 & 难点介绍

从 IT 与系统集成角度看，本项目整体技术路线相对清晰，核心思路是将前端采集到的各类监测要素——包括温度、湿度、大气压、风速、风向、雨量以及水位——通过现场采集终端汇总后，经 RS485 接入 DTU，再利用 4G 网络将数据上传至中心平台，完成存储、展示与预警联动，其中气象六要素很简单，现场只需合理选址立杆、完成供电与通信即可稳定运行，真正决定系统可靠性与运维成本的关键环节，集中体现在水位数据的获取方式上。

对于桥梁以及水位变化幅度不大的明渠河段，或具备明显垂直切面的水库场景，水位数据通常可以直接通过安装雷达水位计获取，本项目中的部分桥梁点位即采用该方式，在桥面下方垂直安装雷达水位计，直接测量水面到设备之间的距离即可换算水位，施工简单、数据稳定，几乎不需要额外调试。

但在水位高差动辄十几米的自然河道场景中，情况就复杂得多，当河道水位处于高位时，水面宽度可能达到两百米，而在枯水期水位接近零位时，河面宽度往往缩减至一百米以内，这种横向变化极大的河道形态，使得必须垂直于水面安装的雷达水位计在低水位或偏移工况下难以稳定获取有效数据。针对这一问题，我们在前期方案论证阶段曾评估过多普勒水位计、电子水尺、雷达水位计等多种技术路线，综合安装条件、测量范围、长期稳定性以及整体成本等因素，最终在各渡口点位选择了“视频水尺摄像机 + 实体标注水尺”的水位监测方案。

2. 视频水尺安装 & 调试记录

下面这两张图展示的是本次项目中安装条件相对最理想的两个站点，现场道路通畅、作业面开阔、基础条件较好，两名施工人员在配合顺利的情况下，用半天时间便完成了全部设备的安装与调试；而其余多数站点则远没有这么“友好”，要么交通条件困难，要么地面硬化不足需另外多层加固，亦或存在植被、构筑物遮挡等问题，往往需要忙碌一整天才能勉强完成安装，且最终效果仍然不尽理想。

如图所示，在大多数站点中，我们将所有前端设备集中部署在同一根约 4 米高的立杆上，包括气象传感器、供电系统、通信设备以及视频水尺摄像机，其中画面中的摄像头正是本项目的核心设备——视频水尺摄像机（下文简称“摄像头”），其工作方式是通过持续拍摄固定在河岸边的实体水尺，并由内置图像识别算法对水尺刻度与数字进行分析，从而实时计算并输出当前水位数据。

右图所示为我们针对本项目定制的一米标准阶梯式水尺，安装时不仅要保证刻度与数字清晰可见、整体画面畸变可控，还要确保水尺在丰水期能够被水面有效覆盖，同时监测站本体又不能在极端水位条件下被淹没，这种相互制约的安装要求，直接导致监测立杆与第一根水尺之间的水平距离往往较远；在条件较好的码头，这一距离尚可控制在数米以内，而在坡度平缓的河岸，一米高程对应的水平距离甚至超过五米，本次项目中最极端的站点，该距离达到了约六十米，使得摄像头的俯仰倾角和变焦倍率都被迫拉到极限。

至于水尺的安装，摄像头厂家的建议文档中有明确的安装规范，但回顾实际情况，我发现许多站点的安装并未完全遵循这些规范，导致后期可能无法正常获取数据。文档中最基本的要求包括：水尺不能被水淹没，视野应通透，周围不能有树枝遮挡，且要避免太阳被遮挡，同时施工工艺要达到一定标准。乍一看这些要求很基础，但实际上，我们遇到的站点大部分都未完全满足这些条件，尤其是在一些远离城区、基础条件较差的地点，真是让人哭笑不得。

这两处掉线的站点都是因为太阳能供电不足。初步分析其中一处是因为遮挡严重充电效率低，一处是摄像头没开节能模式

此外，文档中还提到视频画面和水尺的倾角有一定要求，不能过大，每个水尺之间的距离最好能重合 30cm 左右，并且要求视频画面中仅能显示一根水尺。这些要求，最开始厂家并未明确指出，且也未提供相关的指导文件，结果导致我们在初期安装的两个站点都出现了问题。即使后来我查阅了相关文档，仍然有部分站点无法做到最佳安装效果。例如，一些站点由于周围环境问题，太阳被遮挡、画面中同时出现两到三根水尺的情况经常发生，实在令人头疼。

还有，如下图所示，除了对摄像头进行一系列基础设置外，我们还需要对水尺进行标定。首先，必须在摄像头画面中框选出水尺的区域，然后设定水尺的高程，并根据实际情况调整上下切值。正如我之前提到的，由于外部环境因素（如风吹草动），框选区域可能会发生偏移，这样一来，水尺就可能无法被正确识别，最终导致数据缺失。

因此，必须确保远程调试功能的可用性！考虑到我们平台并不具备这种能力，而之前采购的 DTU 只支持 MQTT 数据透传（且流量不足以支撑频繁调试），我最终只能另行采购工业路由器，并通过 L2TP 实现异地组网。

3. 利用工业路由器异地组网

我购买的塔石 TAS-IT-692 路由器是一款性价比高的工业级设备，具备小巧、低功耗的特点，适合用于项目中的远程接入。它内置了 OpenWRT 系统，提供了较强的路由功能，能够满足基本的网络需求，如设备连接、流量转发等。然而，它的局限性也非常明显，对 VPN 协议的支持较为有限，仅支持安全性较低的 L2TP、PPP VPN 协议。更受欢迎也更安全的 OpenVPN 并不支持，这个限制在需要高安全性远程连接的场景下，可能会带来一定的风险。

💻 参数分类	🛠 参数项	📄 规格说明
产品定位	型号	TAS-IT-692 系列
产品定位	类型	单网口 4G 工业路由器
硬件性能	主芯片	MIPS 24KEc
硬件性能	主频	580 MHz
4G 通信	网络制式	移动 / 联通 / 电信 4G
	下行速率	FDD：10 Mbps / TDD：9 Mbps
	上行速率	FDD：5 Mbps / TDD：3 Mbps
	频段	FDD：B1/B3/B5/B8；TDD：B34/B38/B39/B40/B41
以太网	网口数量	1 × RJ45
	网口速率	10/100 Mbps，自适应
	同时连接数	4
协议支持	网络协议	TCP / UDP / DNS / MQTT / HTTP
管理方式	配置方式	Web 配置、DTU 指令远程配置
物理特性	尺寸	90 × 35.8 × 31.5 mm（含导轨）
	重量	≈118.9 g
	安装方式	导轨

塔石 TAS-IT-692-F2 规格参数

3.1 创建 L2TP 服务器

由于 TAS-IT-692 本身性能有限，无法支撑更高加密强度的 VPN 实现，最终系统仅能稳定支持不加密的 L2TP，因此整体思路也就非常直接：在云服务器上部署一个最基础、最“原生”的 L2TP Server，只要能连得上、路由能通、不中断即可。这里甚至不需要自己查太多资料，对着 ChatGPT 直接一句“给我 Debian 13 安装不加密 L2TP 服务的详细步骤”，基本就能得到一套可执行的流程，我在实际部署过程中根据环境对部分配置做了调整，最终总结如下。

首先是在云服务器（Debian 13）上安装所需组件，核心只涉及两个软件包：xl2tpd 和 ppp，其中 xl2tpd 负责实现 L2TP 协议本身，ppp 则用于点对点链路的拨号、地址分配和认证机制，执行 sudo apt install xl2tpd ppp 即可完成基础环境的安装；安装完成后，需要重点配置 xl2tpd 服务，这是整个 L2TP Server 的核心，其配置文件主要用于定义监听端口、L2TP 隧道参数以及与 PPP 的关联方式，后续所有客户端（包括塔石工业路由器）能否正常拨入，基本都取决于这一部分是否配置正确。修改/etc/xl2tpd/xl2tpd.conf文件如下：

[global]
port = ******

[lns default]
ip range = 10.10.10.101-10.10.10.200
local ip = 10.10.10.1
require chap = yes
refuse pap = no
require authentication = yes
name = l2tpd
ppp debug = yes
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes

L2TP 本身只负责隧道的建立，真正的数据传输、地址分配和链路维护仍然依赖 PPP（Point-to-Point Protocol），因此下一步需要配置 PPP 的相关参数，这里主要修改的是 /etc/ppp/options.xl2tpd 文件，用于定义通过 L2TP 建立的 PPP 会话行为，例如是否进行身份认证、是否启用压缩、是否允许分配 IP 地址等；在本项目中，为了降低复杂度并提高兼容性，我关闭了不必要的认证和压缩选项，仅保留最基础的 PPP 参数配置。

require-mschap-v2
refuse-eap
refuse-pap
refuse-chap
refuse-mschap
name l2tpd

# 不加密（禁用 MPPE）
nomppe

ms-dns 223.5.5.5
ms-dns 114.114.114.114

proxyarp
# 暂时注释下行先跑起来
# lock
nobsdcomp
novj
novjccomp
nologfd

最后一步就是配置 L2TP 的拨号用户，为了后期运维和排障方便，我没有采用“统一账号随机分配 IP”的方式，而是提前为这十几台工业路由器规划好了固定账号与固定地址的对应关系，每一个监测站点都分配一个独立编号，并在 PPP 配置中约定：路由器拨号成功后获取的虚拟网段 IP，其末位数字即为对应的站点编号，这样在服务器侧一眼就能看出当前在线的是哪个点位。

具体实现方式是通过 /etc/ppp/chap-secrets 文件，为每一台路由器单独配置用户名、密码以及绑定的分配 IP 地址，这种做法虽然“原始”，但结构清晰、可控性强，非常适合这种设备数量不多、但需要长期维护的工程场景。

最后一个容易被忽略但非常关键的步骤，是防火墙和转发相关的配置，一方面需要在系统防火墙中放行 L2TP 所需的端口（UDP ******），如果服务器部署在阿里云、百度云这类公有云环境中，还必须同步在云厂商的安全组策略中放开对应端口，否则服务即使正常运行，外部设备也无法接入。

另一方面，由于我的目标是让这些工业路由器通过 VPN 与云服务器、以及我本地电脑处于同一可通信网络中，就必须开启服务器的 NAT 转发能力，通过启用内核 IP 转发（sudo sysctl -w net.ipv4.ip_forward=1），使 VPN 客户端的流量能够被正确转发和路由，否则只能“拨得上号”，却无法真正访问对端设备。

3.2 电脑端配置 VPN

L2TP 服务搭建成功后，可以通过电脑进行连接测试。步骤如下：

Windows 客户端设置：
- 进入设置 -> 网络和 Internet -> VPN -> 添加 VPN
- 在弹出的设置框中输入以下信息：
  - 自定义名称：可以随便命名，方便识别连接。
  - 服务器地址：填写你 Debian 服务器的公网 IP 或域名。
  - 用户名和密码：填入 /etc/ppp/chap-secrets 文件中为每个路由器配置的对应用户名和密码。
- VPN 类型：选择 使用证书的 L2TP/IPsec。虽然没有加密，但要选择该类型，以便正确使用 L2TP 协议。
- 设置完成后，保存并尝试连接。
验证连接：
- 如果连接成功，客户端会分配到 /etc/ppp/chap-secrets 文件中指定的 IP 地址。
- 在 Debian 中，执行以下命令检查是否分配了 IP 地址： ip a | grep ppp
- 如果看到类似 ppp0 的接口信息，且有正确的 IP 地址分配，那么 L2TP 连接已经成功建立。
连通性测试：
- 此时可以进行其他网络连通性测试，确认 L2TP 连接的稳定性和正常访问性（例如，通过 ping 测试连接的目标设备）。

通过这些步骤，你可以确保 L2TP 服务在 Windows 客户端上顺利连接并正常工作。如果一切顺利，后续就可以开始进行设备间的连接和监控了。

3.3 配置工业路由器

在路由器的配置中，主要包括基础配置、接口配置、路由设置、防火墙配置和定时任务设置等内容。基础配置方面，我修改了路由器的编号、名称和密码，以便于多台设备的识别。使用塔石 OpenWRT 的优势在于，修改设备名称后，浏览器访问 Web 控制页面时，页面的标题也会随之变化，便于识别。这一点相比于某些设备更加实用。

3.3.1 接口配置

在每台工业路由器上，首先需要手动创建一个 L2TP 接口，接口名称可以根据需要自定义，选择刚才配置的 L2TP 协议，并使用 /etc/ppp/chap-secrets 文件中预设的用户名和密码，这样路由器就能成功连接并获取到预设的 IP 地址。

另外，为了保证主服务宕机时能提供备份服务，路由器的 IMEI/MAC 地址需要绑定到塔石提供的云平台上。通过云平台，我们可以再拉起一个备用的 L2TP 接口，这个备用接口可以在主服务不可用时作为备用连接，确保网络连接的稳定性和高可用性。

关于路由器的 LAN 口设置，为了避免 IP 地址冲突，我按照规划将每台路由器的 LAN 口地址设置为 10.253.x.1/24，其中 x 是根据站点编号分配的。网关地址不需要填写，路由器与摄像头通过该 LAN 口连接，摄像头的 IP 地址则设置为 10.253.x.2/24，网关设置为 10.253.x.1，确保路由器和摄像头在同一网段内并能正常通信。

需要注意的是，虽然每个路由器的 VPN 账号和 LAN 口地址都有所不同，但它们遵循相同的规律，方便批量管理和后期运维。这样的配置可以有效避免在多台设备同时接入时出现 IP 地址冲突，确保网络的稳定性。

3.3.2 路由配置

为了避免网络串流并确保网络通畅，需要在路由器和服务器侧配置静态路由。以本案为例，在所有路由器中添加一条静态路由，目标为 10.10.10.0/24，网关为 10.10.10.1（即 L2TP 服务器的地址）。同时，注意到每个路由器的 LAN 口地址为 10.253.x.0/24，这个网络与服务器没有直接关系，因此在服务器中需要添加以下命令以实现网络互通（其中，x 为本项目站点编号，根据站点数量添加相应的条目）：

ip route add 10.253.x.0/24 via 10.10.10.x

其中，x 为本项目站点编号，根据站点数量添加相应的条目。

3.3.3 防火墙配置

在所有路由器和接口（包括塔石官方提供的 L2TP 接口）配置完成并上线后，接下来需要在防火墙中放行转发流量。我创建了一条名为 Any 的规则，选择了所有接口，并将目标和来源选项尽量填满，允许所有流量通过。虽然这种做法存在一定的安全风险，但考虑到这个网络主要用于调试，因此没有太大问题。

3.3.4 定时任务

在完成上述配置后，接下来需要添加两个自动重启规则，以确保路由器能定期检查服务连通性，并在连接丢失时自动重启以恢复连接。具体操作如下：

设备自检：我在“设备定时自检”中设置了每 4 小时检查一次 LAN 口的连通性，确保设备始终在线。
L2TP 服务器连通性检测：在“计划任务”中添加了如下规则，每 5 分钟 ping 一下自建的 L2TP 服务器，如果未能成功连接，则自动重启路由器以进行重连。任务使用的是 network_check_switch.sh 脚本，该脚本是塔石官方内置的，当然我们也可以根据需求修改或重新编写此脚本。

*/5 * * * * network_check_switch.sh 10.10.10.1

通过这些措施，可以确保路由器在网络不稳定的情况下自动恢复，并最大限度减少人工干预，保持系统的可靠性。

4. 写在最后

通过以上操作，我成功将电脑与野外的多台摄像头组建成了一个局域网，虽然我自掏腰包购买了设备和流量卡，但总体成本还是可控的。这移动的 10GB 流量卡每年只需 27 元，比起我每次费力跑到现场进行维护，实在省事得多。

不过，我得补充一点，摄像头厂家（天地伟业）提供的专用调试软件，真的是消耗资源非常大！我也不清楚他们是怎么优化的，但在我的笔记本上，CPU 稳定在 80%左右，电池也总是很快耗尽，根本无法长时间在户外使用。这也是我决定费尽心思搞远程调试的原因之一。

从现实层面来看，政府在这一块的投入力度其实不小，但就我在现场的直观感受而言，除了一些靠近城镇、人口相对集中的码头外，很多位置偏远、人员稀少的渡口，实际乘坐过河船的人并不多（当然，也可能与是否赶场天有关）。与此同时，过河船向老百姓收取的费用普遍很低，最低只有一到两元，这样的收费水平显然无法覆盖渡运本身，更不用说支撑其他辅助系统的建设和长期运行成本了。也正因为如此，我在施工过程中时常会产生一种感慨：在这些地方，保留并持续投入这样一套基础设施，只是为了方便极少数群众的出行需求，社会主义好啊！