NVR 摄像头在 VPN 上消失？先检查 PoE 子网重叠

从远端访问 NVR 时，实时画面可能打不开，而局域网页面仍然正常。隧道是通的，录像机也有应答，但回包走了一条没人画过的路径：录像机内部的摄像头端口。在 PoE 机型上，这第二个接上的网络属于地址规划的一部分，无论它是否出现在主局域网设置页上。

把故障从客户端一路追到录像机，再追回来。回程这一段，才是隐藏接口现形的地方。

从远端客户端复现，而不是在局域网里

用一个真正穿过 VPN 的客户端来测。同一局域网里的浏览器可以直连录像机，因此根本不会走到那条会出问题的路径。记录下客户端地址、录像机的局域网地址以及失败的具体服务。

多试几种服务。网页管理页面、实时流和回放请求可能使用不同的端口和不同的代理，一种能用而另一种失败是常见情况。这个对比能告诉你故障是否只与某一服务相关。它也能避免把单个端口失败误判成录像机已经死掉。

先看请求到底有没有到达录像机。根本没到达的连接，问题多半在入向的路由或防火墙上；到达之后又卡住的请求，问题在回程路径或服务本身。如果录像机提供连接日志或计数器，就用它。退而求其次，在站点边界抓包。

顺着回包离开录像机

设想一个两站点的示意布局。远端客户端是 10.60.0.25/24，录像机所在站点的局域网是 10.70.0.0/24，录像机的局域网地址是 10.70.0.50，它内部的 PoE 网络是 10.60.0.0/24。

Site A client:        10.60.0.25/24
Site B LAN:           10.70.0.0/24
NVR LAN address:      10.70.0.50
NVR internal PoE net: 10.60.0.0/24

来自站点 A 的流量经隧道到达 10.70.0.50。录像机随后在自己的表里查回程地址，发现有一个直连前缀覆盖了 10.60.0.25。这个前缀比默认路由更具体，于是回包奔向摄像头端口，而不是隧道。

隧道的协商状态、站点 B 路由器上正确的回程路由，都无法推翻这个本地选择。同样，向站点 B 另一台服务器发起的成功请求，也证明不了这台设备的第二个接口没有问题。

盘点隐藏的 PoE 网络

在录像机的网络设置里找内部网卡、PoE 区块或单独的摄像头子网。有些机型把它作为一个带独立地址的第二接口暴露出来；另一些则把它藏在摄像头配置页后面。

查该机型与固件的文档，不要假定出厂前缀。某条产品线上的常见默认值并不是每台录像机的事实，照抄一个数字可能掩盖真正的重叠，而不是揭示它。

把发现的网段与两个站点的局域网、VPN 客户端地址池以及录像机上其它已连接网络逐一对比。与远端客户端地址池重叠，正是会让回包改道的情况；与无关的本地网段重叠，则可能在不碰 VPN 的情况下打断本地摄像头访问。在选定新数字之前，把重叠画在一张纸上。两个重叠的网段在纸上一目了然，分开看两个设置页却完全看不见。

记录网段、接口名称以及其上的摄像头地址。这份清单正是改号计划必须保下来的东西。顺手把摄像头型号和固件版本也记上。

连摄像头一起改号，而不只是改 NVR

选一个既不与两个站点重叠、也不与 VPN 地址池或其它已连接网络重叠的摄像头网段。然后列出所有依赖旧网段的东西：动态租约、静态配置的摄像头地址、已保存的通道、录像计划，以及该机型会执行的任何自动配置。这份清单是迁移核对表，不是事后补充。

在授权的窗口内迁移内部网络，并保证录像机的备份与恢复通道可用。只改录像机的内部地址，可能会让仍持有旧网段的摄像头掉线，而录像机可能把它们报成离线，而不是配置错误。保留旧的配置导出，直到新流稳定运行满一天。

在测远端客户端之前，先验证本地摄像头画面与录像。建立在已经丢了摄像头的录像机上的远端修复，不算修复。

验证画面、录像与远端访问

在远端客户端上，分别测试实时画面、回放和管理页面。在受控的局域网与 VPN 边界上观察请求和响应，让回程路径看得见，而不是从一个能打开的页面去推断。

如果设计里包含摄像头访问代理或虚拟主机功能，把它的端口映射和权限当作另一条显式路径，单独评审。不要为了弥补重叠就开放所有摄像头端口，或放宽 VPN 选择器。

当改号不可行时，任何替代方案都需要有受支持的地址视图，并单独做策略评审。这个教训超出录像机本身：一台设备可能保留着远端站点已经使用过的摄像头、服务或管理网络。

把最终网段和已测试的服务记进站点规划。下一台录像机、下一次摄像头扩容或 VPN 地址池变更都会沿用这些数字，而一个曾经修好的重叠很容易被重新引入。