客户 QA 在家测试内网部署的系统，端口映射一开，公网扫描和 MySQL 爆破当晚就会出现；IPsec VPN 又卡在客户没有固定公网 IP、没有企业级 VPN 网关。这个问题用 NexTunnel 的思路完全不同：内网侧部署 Server，外网侧运行 Client，只放行授权端口，不需要公网 IP。
这里说的不是“能不能连通”，而是“连通之后怎么控制暴露面”。测试系统通常只监听内网 IP 和端口，开发公司交付后要开放给客户 QA，传统两类方案都容易踩坑。
方案 | 是否需要公网 IP | 授权粒度 | 访问审计 | 部署成本与风险 |
|---|---|---|---|---|
端口映射 | 需要，且家庭宽带很多没有公网 IP | 仅到 IP:端口，不分用户 | 基本只有路由器或防火墙日志 | 低，但暴露面大，适合临时演示不适合交付 |
IPsec VPN | 通常需要固定公网 IP 或 VPN 网关 | 网络层接入，细化到端口要另做 ACL | 需要额外日志系统 | 高，需要维护证书和客户端配置 |
NexTunnel | 不需要 | 设备授权 + 端口级白名单 | 后台连接审计 | 中等，Server 部署一次，Client 安装即可 |
端口映射在客户测试场景里的三个硬伤
端口映射不是不能跑，而是在“客户在家测试”这个前提下非常脆弱。客户家庭宽带如果没有公网 IP，端口映射根本做不成；即便有公网 IP，入口直接暴露在公网，MySQL 3306、Redis 6379、Jenkins 8080 这些端口一旦开放，扫描和爆破会立刻到访。
来源 IP 限制也很容易失效：客户用家庭宽带，出口 IP 会轮换，把防火墙规则写死就会频繁失联。而且映射规则通常只到端口，分不清是谁在访问，测试完成后回收权限很麻烦。所以端口映射只适合内部临时演示，不适合交付给客户在家做测试。
IPsec VPN 用在临时测试访问上为什么很别扭
IPsec VPN 本身没问题，但它的部署假设是“企业到企业”或“固定员工到公司”，不是“客户 QA 临时从家里访问测试系统”。典型限制有三个：客户没有固定公网 IP 时，需要额外做 DDNS 或改用 SSL VPN；要为每个测试人员维护证书、账号和客户端配置；接入后默认是网络层可达，如果测试服务器没有额外防火墙 ACL，VPN 会把内网暴露给远端设备。
对开发公司来说，如果每次交付一个内网测试项目都要协调客户 IT 改 VPN，项目周期和沟通成本都会上升。NexTunnel 这类方案把接入从网络层降到端口级，反而更适合交付场景。
NexTunnel 内网侧 Server + 外网侧 Client 的部署方案
拓扑不复杂：客户测试服务器所在的网段放一台主机安装 NexTunnel Server，Server 只需要能出站连接到协调服务，不需要在客户路由器上开任何入站端口；客户 QA 的笔记本安装 Client，出站连接后，在 Server 后台把该 Client 设备加入授权列表。这里的核心是“先授权设备，再放行端口”，顺序不能反。
安装 Server：在能访问测试服务器网段的主机上安装 NexTunnel Server，启动后先在后台确认它处于在线状态。
绑定 Server：在后台完成 Server 的绑定或初始化，这一步只在客户内网侧做一次，不要重复部署多台 Server 以免授权策略分散。
安装 Client：让客户 QA 在外网电脑上安装 NexTunnel Client，并确认 Client 能正常连接。此时还不要急于测试，因为尚未授权资源。
添加端口资源：在后台添加测试服务器的资源，只选择需要测试的 TCP 端口，例如 Web 8080；数据库端口如果没有必要，先不要放行。
授权 Client 设备：把客户 QA 的 Client 设备加入允许访问列表，并勾选刚才添加的端口资源。授权后，Client 侧不需要改路由表，直接访问被授权的内网地址和端口即可。
这里最容易做错的是第三步直接跳过，以为装好 Client 就能访问。正确习惯是：未在后台授权设备之前，不要指望任何端口能被访问。配置时确认后台的授权策略已经生效，再开始测试。
端口白名单和设备授权怎么配，测试权限才不放飞
很多开发公司在客户测试阶段图方便，直接把整个内网网段加进资源列表，这是最危险的操作。客户 QA 只需要访问一个 Web 测试系统，结果数据库、代码仓库、Jenkins 都可能暴露。正确做法是按“最小端口集”添加资源：先确认测试系统依赖哪些端口，例如 Web 8080、MySQL 3306、Redis 6379，然后逐个添加。
设备授权要和端口白名单配合，而不是二选一。比如客户 QA 有两台电脑，只授权其中一台；测试结束后，在后台停用或删除该设备授权，即使 Client 还装在电脑上，它也无法再访问测试端口。授权策略不要做成永久有效，可以按测试周期来管理。
NexTunnel 在这里的优势不是“把内网搬出去”，而是每次只放行一个小口子。客户家庭网络、手机热点、异地办公这些网络变化不会影响授权判断，因为设备标识和端口策略在后台维护，不依赖来源 IP。
客户测试完成后，怎么用访问审计做权限回收
交付测试最容易被忽略的是收尾。客户 QA 测完系统后，如果只是口头通知“不用了”，但端口映射还在、VPN 账号还没禁用，内网暴露会一直存在。对 NexTunnel 来说，这一步应该变成后台操作：查看每台设备的最近连接记录，确认最后一次访问时间，然后删除或禁用该设备的授权。
审计记录还能帮助定位问题：如果客户反馈连不上，可以先看后台有没有该设备的连接记录；如果完全没有，说明 Client 没有正常接入；如果有连接记录但访问失败，说明问题在 Server 到测试服务器这一段。不要把“连不上”和“没授权”混在一起，审计日志可以快速区分。
如果客户内网对合规有要求，访问审计还可以作为测试期间访问行为的留痕依据。重点是保留“谁在什么时间访问了哪个端口”这类记录，而不是只记录 VPN 登录登出。
连不上内网系统？从这几个地方排查
客户在家测试时，最常见的问题是 Client 显示在线，但访问内网系统失败。按下面顺序排查，通常能定位：
Client 是否被授权：后台确认该设备是否在授权列表里，并且是否勾选了目标端口资源。没授权时，连接可能正常，但访问会被拒绝。
端口资源是否添加准确：目标服务只监听 192.168.10.50:8080，就不要只添加 192.168.10.50 或只添加 8080，必须和监听地址、端口完全一致。
Server 到测试服务器是否通：从 Server 所在主机直接测试目标端口，确认内网本身没问题；如果 Server 和测试服务器之间有防火墙，需要放行 Server 主机的内网 IP，而不是公网 IP。
目标服务是否只监听 127.0.0.1：很多内部系统默认只监听 localhost，Client 通过隧道访问时会被拒绝。需要在测试服务器上把服务监听改为内网 IP 或 0.0.0.0，但不要改成公网 IP。
网络切换后没有自动恢复：如果客户从家庭宽带切到手机热点，先确认 Client